AI has become the place to find answers to nearly any question. I have used the public LLMs like ChatGPT, Anthropic, and Gemini to create trip itineraries, research topics for a book I am writing, and plan social gatherings. I continue to be amazed by the information these tools reveal and how easily I can obtain real guidance from LLMs. Now, organizations are creating their own AI tools that analyze internal content and company-specific information. These internal tools scan all of the content across the enterprise and use it to form answers specific to the business. These tools have the power to change the way knowledge and information management work. Business managers and leaders will soon be able to ask questions about sales activity, product development, and company policies and receive the same quality answers they get using public LLMs. This is an exciting, but risky proposition.

Organizations that want to succeed with their AI initiatives must ensure they are prepared for AI. This blog post is part of a series of posts we are publishing to help organizations prepare for AI. The earlier blog posts provided guidance on how to ensure your data and content are reliable, complete, and include the necessary context so that AI can return accurate results. Unified entitlements address an entirely different issue: how organizations should protect their most sensitive content.

Most organizations struggle to manage security around content (a.k.a. entitlements) across all of their content repositories. I was at a security conference last week and asked two Chief Information Security Officers (CISOs) about entitlements. Both of them offered nearly the same response to my question as to how they manage entitlements. They know it is a problem, but are unsure how to fix it, and it is just not a big enough problem at this time. The urgency surrounding the securing of knowledge assets is about to change due to AI.

Microsoft Copilot, for example, ingests all of an organization’s SharePoint content to provide answers to questions posed by users. If those documents have incorrect permissions, employees could learn about sensitive or privileged information, like a potential layoff or merger, before it is officially announced. Organizations are also utilizing AI tools to analyze data and provide insights into sales and client information. What if an AI Agent accidentally leaks essential details on a new product? These issues are likely to start happening soon. Forward-thinking organizations are addressing this issue now, before dangerous leaks occur.

This blog outlines five key activities that organizations can undertake to protect their most sensitive knowledge assets from AI leakage.

1. Identify and Rank the Knowledge Asset Repositories That Need Entitlements

Large organizations often have thousands of knowledge asset repositories that AI might use. This includes tools such as data lakes, SharePoint Online, document management systems, and product information management software. It is not possible to manage and control entitlements across every one of these repositories

We recommend that our clients create a list of their most critical and sensitive knowledge asset repositories. This repository listing should include the following information:

• Repository Name
• Purpose
• Location
• Owner
• Approximate Size (an estimated count of how many items require entitlements)
• Value Score (a score measuring the value of the content for LLMs)
• Risk Score (a score measuring the potential risk of security content)

The list does not have to include every single repository, but it should cover the largest and most important repositories. Once the list is compiled, the repositories should be prioritized for addressing based on their value score first and risk score second. This prioritized list is used to organize how entitlements are addressed during the next steps.

2. Identify the Security Policies That Need to Be Managed In Each Repository

Once the knowledge repositories are identified and prioritized, the security policies (rules) should be identified. These security policies outline the business rules for applying entitlements to content in each repository. While the business rules for entitlements often cross repositories, in our experience, the best way to identify and document these rules is to work through the prioritized list of knowledge asset repositories, defining rules for each repository. Each repository is likely to have many different entitlement rules that apply to it. This is because each repository can include content that serves different purposes and is owned/governed by different business units. As an example, SharePoint Online is one of the most common repositories, and its content frequently comes from nearly every business unit in the organization and supports many different projects or operational activities.

Defining the security policies can be a never-ending task. It is important to time-box this exercise, focusing on the most critical repositories first and content collections first. Work with business users to understand the sensitivity of information and document the rules (in business terms) regarding who can and cannot access information. Assuming reasonable access to business users, you should be able to complete the first round of policy definition in 2–4 weeks.

3. Design the Implementation of the Security Policies

Once the most important security policies are identified, the entitlements team needs to work with the business owners and the security team to define how the entitlements can best be managed. The solution to manage these policies can be handled through a combination of processes and governance, through technical automation, or both.

For example, a services firm we worked with needed to make sure that their client project team’s sites only included people who were working on the project. Project team sites were delegated to project managers who frequently forgot to remove people who had left the project. In addition, it was common for the project managers to add people to the site who needed guidance for a similar project. In both cases, this meant that consultants who did not work on the project had access to client information, which conflicted with their contractual requirements defined by their clients. 

We addressed this problem through a combination of policies and technology. First, the Project Management Office (PMO) centralized the process of adding people to projects. This group was the only one allowed to add people to projects, and they were responsible for removing people when they rolled off of projects. Formal processes were put in place to make requests of this group when people needed to be added, and notes were sent from billing when people rolled off of projects. These processes helped fix the immediate problem. The Unified Entitlements team then developed a synchronization routine that ensured only individuals with access to the project charge code could access the project team sites. All others were automatically removed as part of the routine. Together, these processes addressed the short and long-term needs for implementing entitlements.

The entitlements team needs to design solutions to as many of the rules as possible within a reasonable amount of time. Please note, the role of this step is to design solutions and not implement them. In our experience, many of these solutions require similar tasks or technology integrations. This problem can be addressed much more efficiently by identifying patterns that can be repeated across multiple repositories or asset collections.

4. Implement Process and Governance Changes

Once the designs from step three are created and repeated patterns are identified, the team can work with the business owners and security team to roll out the new processes. Historically, most security processes have been owned by either IT, a help desk, or the security team. Many of the unified entitlements processes need to be owned by business users who are familiar with the content and data that needs to be secured. As such, the entitlements team will need to work closely with the business owners of the content to agree on the processes to maintain proper entitlements.

When we have designed these processes in the past, we have focused on three aspects:

• Owners
• Triggers
• Validation

The owner, or owners, are the people who will be responsible for executing the entitlements processes. In some cases, it is a single identified person. In others, it is a role on a project. For example, a product company assigns different teams to develop new products or features. For competitive purposes, the content about these new features needs to be kept hidden from others in the organization. The product owner or product manager should be responsible for identifying who should have access to see content about the new product features. The product owner or manager would be the owner of the process. The activities that trigger changes to who can view this content include people joining or leaving the new product development team. The process should explain what happens when these events occur and provide a service level agreement outlining how quickly entitlements should be updated during each of these events. Since this is a manual process that may degrade over time, there needs to be a way to validate that the list of people who can access the information is current. Often, this is handled as a monthly or quarterly review of the people who have permission to see the information, validated against the list of people who should have access according to the policy. Validating these changes on a regular cadence will help ensure that processes continue working and do not degrade over time.

5. Implement a Unified Entitlements Technology Solution

The problem of entitlements is not something that can be addressed with process changes. The size and complexity of adding entitlements to content is too big to be handled without automation. Ultimately, an enterprise platform should be implemented. Read our blog post Inside the Unified Entitlements Architecture to learn more about what that platform looks like. Most organizations discover this problem and require time to implement an enterprise solution.

In the near term, scripts can be created to automate many of the entitlement requirements. The syncing example described in step three is an excellent example of this. IT can build a tool that scans the group defining access to each project team site and updates the group members based on who has access to the project. This script can be run nightly to ensure that only authorized personnel with billing privileges for the project have access to the team site that supports the project’s work.

These scripts are a good way to solve some near-term problems while putting in place a larger plan that will allow for a policy-based central control over content and data entitlements.

Conclusion

If you are about to undertake a significant AI initiative in your organization, you must consider security and information access as a key part of your AI readiness activities. Waiting to do this until later can stall a project or limit the value of the AI solution because of the limited content it can work with. 

For more information or assistance with implementing a Unified Entitlements plan, please email us at info@enterprise-knowledge.com.