AI Agent Permissions, Memory Governance and Data Sovereignty (2026)

TL;DR

AI agent permissions decide what company information an agent may see and what it may do, and the safe default is simple: an agent should see only what the person it acts for could see in the source system, and nothing more. Most incidents come from agents that were given broad access or none of the company's rules. Governance has three layers. Guardrails limit what an agent can do (sandboxes, approved tools, watchdogs). Permissions limit what it can see. Policy tells it what it should do at this company today. Sentra is the managed organization memory that covers the second and third layers: every fact keeps the permissions of the tool it came from (Slack, Google Drive, Jira, Confluence, Microsoft Teams, GitHub and more), every answer cites its sources, agents act as the person who connected them, and can be deployed in your own cloud for data sovereignty. NVIDIA's Open Agent Safety Platform and similar tools cover the first.

Why agent permissions matter now

Agents are moving from answering questions to taking actions across company systems, and the access they inherit is often far broader than the task needs.

• In IBM's Cost of a Data Breach 2025 study of 600 breached organizations, one in five reported a breach involving shadow AI, which added $670,000 to the average breach cost, and 97% of organizations with breaches of AI models or applications lacked proper AI access controls.
• In KPMG and the University of Melbourne's 2025 survey of more than 48,000 people in 47 countries, almost half of employees admitted using AI in ways that contravene company policy, including uploading sensitive company information into public tools.
• OWASP lists Excessive Agency among the top risks for LLM applications: too much functionality, too many permissions or too much autonomy. Its recommended mitigation is to run agent actions in the context of the specific user, with the minimum privileges needed.

The three layers of agent governance

Guardrails are well served by security vendors. Permissions and policy are a memory problem: the rules live in a company's tools, meetings and decisions, and they change.

How to set permissions for AI agents

1. Act on behalf of a person, not as a super-user. Use delegated access so the agent's identity and the person it acts for are both recorded. The OAuth 2.0 Token Exchange standard (RFC 8693) distinguishes delegation from impersonation for exactly this.

2. Carry source permissions through. If a person cannot open a document or channel, an agent working for them must not see facts learned from it. This is the most common failure of AI knowledge tools, because composing an answer from several sources can leak what each source protected.

3. Scope tokens to one system. MCP's authorization specification binds access tokens to the specific server they were issued for and forbids passing tokens through to other services.

4. Grant the minimum, step up when needed. Start with narrow scopes and request more only when a task requires it.

5. Log premises, not just actions. Record what the agent did and which facts it based the action on, so a person can audit the decision later.

6. Keep enforcement outside the agent. An agent can try to game any rule it can read, so blocking should happen in a sandbox or watchdog the agent cannot reach.

How AI agents inherit the permissions of the person they act for

An agent that acts for a person should see exactly what that person could see in each source system, no more. In practice that means checking access per fact, not per tool, because a single answer often combines a Slack thread, a document and a meeting. Concrete cases:

• Private Slack channel. A fact learned in #deal-acme is visible to the channel's members and to agents acting for them. An agent acting for someone outside the channel gets nothing from it, not even a summary.
• A document shared with one team. If a pricing floor lives in a Google Drive file shared only with finance, a finance agent can use it and a sales agent asking about pricing gets only what sales can open.
• Email. A fact from an email thread is visible to the people on that thread, unless an admin grants a role wider access.
• Meetings. Facts from a meeting follow who attended, and a meeting marked private stays private.
• Tickets and wikis. Jira and Confluence project permissions carry through, so a restricted project stays restricted inside answers.

There are two ways to enforce this. A system can check access against the source's API at the moment someone asks, or it can sync each source's permission lists continuously and read them at query time. Sentra uses both: it checks Slack, GitHub, Linear, HubSpot, Asana and ClickUp access when a question is asked, syncs Jira, Confluence, Microsoft Teams and Google Drive permissions in the background, and treats any check that fails as no access. Direct messages are not used to answer questions.

AI agent identity: who an agent acts for

Agent identity answers two questions: which agent is this, and on whose behalf is it acting. Delegation (the agent acts for a person, and both identities are recorded) is safer than impersonation (the agent simply becomes the person) and far safer than a shared service account with broad access, which is the setup that turns one leaked token into a company-wide exposure. Oso's guide to delegated access for AI agents makes the same point, and names long-lived standing access as the biggest failure mode.

In Sentra, an agent connected over MCP or the API acts as the person who connected it and inherits that person's access. Keys issued to third-party AI clients such as ChatGPT, Claude or Cursor can read memory but cannot use Sentra's write endpoints outside MCP.

Agentic AI governance checklist

For a company deploying many agents, these are the controls to have in place before agents touch production data:

• Inventory. Every agent has a named owner and a named person or team it acts for.
• Delegated identity. No shared super-user service accounts; each request carries the person's identity.
• Per-fact permissions. Source permissions apply to every fact an agent sees, including facts from private channels, restricted documents and email.
• Scoped, short-lived tokens. Tokens are bound to one server and one purpose, and expire.
• Human approval for consequential actions. Sending, paying, deleting and posting externally wait for a person's yes.
• One source of policy. Company rules live in one shared memory agents read, not copied into each agent's prompt.
• Memory hygiene. Outdated facts are retired, agent-reported facts stay claims until confirmed, and no agent can plant instructions other agents will follow.
• Audit trail. Each action is logged with the facts it relied on and where those facts came from.
• Data location. You know where memory is stored, which model providers process it and how long it is kept.
• Revocation. One switch disconnects an agent and its tokens.

Buyer checklist: permission-aware company memory

Questions to ask any company memory or AI knowledge vendor before agents use it:

• Which connectors enforce source permissions, and how: checked at query time, synced permission lists, or neither?
• What happens when a permission check fails or a source is unreachable: is that treated as no access?
• Are private channels and direct messages ingested, and who can see what came from them?
• Can admins control who sees email, meetings and files beyond the source defaults?
• Does every answer cite the sources it used, so a reviewer can trace what an agent relied on?
• How are outdated facts handled when a decision changes?
• How do agents authenticate, and do they act as a specific person?
• Where is the data stored and processed, and can you delete a person's or a source's data?

Memory governance: what agents may remember

Agent memory adds a governance question that search never had: what is retained, for how long, and who can see it.

• Some things should never surface. Customers asked us for exactly this, in their words: "topics never to bring up, people never to discuss, visibility that runs one way and not the other."
• Old facts must be retired, not left to compete. A policy that changed last week should not be served next to its replacement.
• Agent-reported facts are claims. What an agent says it did should stay a claim until a person or a system of record confirms it.
• Memory must resist poisoning. OWASP's Top 10 for Agentic Applications lists memory and context poisoning as a top risk: no agent, or attacker, should be able to plant a fact that changes what other agents do.

Data sovereignty for AI agents

Data sovereignty means keeping control over where company data is stored and processed and which laws apply to it. For agents it usually comes down to three questions: where the memory lives, which providers process it, and whether data leaves a jurisdiction.

• Personal data transfers: under GDPR, personal data may only be transferred outside the European Economic Area under the conditions of Chapter V, such as adequacy decisions or standard contractual clauses.
• The EU AI Act: in force since 1 August 2024 and generally applicable from 2 August 2026, with high-risk obligations phased to 2027 and 2028, per the European Commission.
• Deployment options: the strongest control is running the memory layer in your own cloud account and region, so the company's institutional knowledge never sits in a vendor's shared environment.

AI agent governance tools compared

Identity providers and a shared memory layer solve different problems. An identity provider answers who the agent is and which systems it may sign in to. An authorization engine answers whether one request is allowed inside an application you built. Neither knows what was decided in last Tuesday's meeting, or which facts from a private channel ended up inside a combined answer. A permission-aware memory layer applies access at the level of each fact after facts from many sources have been combined, which is where most leaks happen.

The same rules apply to personal agents. Sentra Agent, for example, reads only the sources a person connects, waits for approval before it sends, books or posts, and follows guardrails the company sets, such as a spend limit or systems it may never touch.

Frequently Asked Questions