Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do AI Agents End Up With Full Access to Sensitive Company Records?

By inheritance, not by decision: an agent takes over a signed-in user's session, reads whatever permissive sharing defaults have already exposed, and runs under a service identity granted more than its task needs, so full access is the default outcome. Check which of the three paths each agent in use arrived by, and who, if anyone, chose it.

Paths from several access doorways converge on a shared archive of sensitive company records.

By inheritance, not by decision: an agent takes over a signed-in user's session, reads whatever permissive sharing defaults have already exposed, and runs under a service identity granted more than its task needs, so full access is the default outcome. Check which of the three paths each agent in use arrived by, and who, if anyone, chose it. When a security team discovers that an agent can read every personnel file in the company, the first question is who authorized that. The usual answer is nobody. The agent was pointed at a document library using the login of the person who built it, the library's sharing settings had been set to the most permissive option when it was created, and the service account provisioned for the agent in production was copied from one that already had broad rights because that was quicker than working out what the agent needed. Three ordinary, well-intentioned steps, none of them a decision about data, and the result is an agent with full access to sensitive records. This page walks through what full access looks like on one record, then each of the three paths in turn, why no one decided, and what claims a buyer should refuse. It extends the question of how to secure AI agents that access customer data to the prior question of how the access got there.

Key findings

  • Microsoft's guidance for preparing SharePoint for Copilot and agents states that agents respect existing permissions and that, by default, SharePoint sets sharing settings to the most permissive option, so overshared content surfaces to the agent (Microsoft Learn, 2026).
  • Once an agent follows injected instructions inside a logged-in browser, the browser's own protections no longer help; Brave's analysis of an agentic browser found that same-origin policy and cross-origin resource sharing become effectively useless in that position (Brave, 2025).
  • OWASP's Top 10 for non-human identities lists overprivileged identities as a distinct risk and defines secret leakage as the exposure of API keys, tokens, encryption keys and certificates to unsanctioned data stores (OWASP, 2025).
  • Cloud providers' own best-practice guidance for service accounts and IAM warns against broad, long-lived machine identities and recommends least privilege, which is the opposite of how agent identities are usually provisioned (Google Cloud, 2026; AWS, 2026).
  • Excessive agency, in OWASP's definition, is a model granted more functionality, permission or autonomy than its task requires, and inherited access produces it without anyone intending to (OWASP, 2025).
  • An agent's reach can only be governed once it is recorded; the run-level record of what an agent read, did and who approved it is the instrument for finding inherited access after the fact (What Is an AI Control Record?).

What does full access look like on a single record?

Take a personnel record stored as a folder in a document library: an offer letter with salary, a copy of a government identity document, a performance review, a medical accommodation request, a termination memo. The library belongs to the people team. An agent built to answer employee questions about holiday entitlement is connected to the organization's document stores so that it can find the holiday policy.

Full access on this record means the agent can open the folder and read every file in it, not because anyone granted it access to personnel files, but because the identity it runs under can. Microsoft's own guidance for preparing SharePoint for Copilot and agents makes the mechanism plain: agents respect existing permissions, so what an agent can reach is exactly what its identity can reach, and by default SharePoint sets sharing settings to the most permissive option, so content that was overshared to begin with is now surfaced by the agent (Microsoft Learn, 2026). The agent did not break a rule. It applied the rules that were there.

The record's sensitivity does not enter the calculation anywhere. Nothing in the chain asked whether the holiday agent's task required the medical accommodation request; the question was only whether the identity could open the folder. That is the shape of the problem this page describes: access to records is granted by identity and sharing state, and neither of those was configured with an agent's task in mind. A per-task view of what the agent should be allowed to read is a different kind of decision, and it is one that nobody in the chain was asked to make.

How does an inherited user session give an agent everything the user has?

The fastest way to get an agent working is to run it inside a browser or session where a person is already signed in. The agent then holds every cookie, token and open tab that person holds, and every application trusts it as that person. For a builder testing an agent on their own account this is convenient. For an agent that reads content from the web or from documents, it is the configuration in which an injected instruction has the most to work with.

Brave's analysis of an agentic browser describes the consequence. Once an agent follows injected instructions while operating inside a logged-in browser, the protections the browser normally enforces between sites stop mattering; in Brave's words, same-origin policy and cross-origin resource sharing are all effectively useless, because the agent is a trusted party on every origin at once (Brave, 2025). The agent can read a personnel file in one tab and a bank page in another, and an instruction planted on a third page can direct it between them.

Microsoft's taxonomy of failure modes in agentic systems treats this class of failure, where the agent's position inside a trusted session lets a compromise reach everything the session reaches, as a failure of the system's design rather than of the model's judgment (Microsoft AI Red Team, 2025). The inherited session is the first path to full access, and it is the one most agents start on, because it is the one that works on the first afternoon.

How do permissive sharing defaults turn into agent reach?

The second path needs no agent to create it; the agent only reveals it. Document stores, drives and collaboration tools have for years been configured to share widely because sharing is what they are for, and a default of the most permissive option, as Microsoft describes for SharePoint, means that a library created without deliberate restriction is open to more people than its owner assumes (Microsoft Learn, 2026). Before agents, this oversharing was mostly latent. A person with technical access to a personnel folder would have had to know it existed and go looking.

An agent removes the friction. It searches across everything its identity can reach, and it returns what it finds. The holiday agent asked about a colleague's leave balance may surface the termination memo because the memo mentions accrued leave and the folder was shared to the whole organization in 2019. The agent did nothing a determined employee could not have done; it did it in two seconds, without intent, in response to an ordinary question.

Oversharing is therefore not an agent problem, but agents turn it from a theoretical exposure into a daily one. Microsoft's guidance for this situation is to find and restrict overshared content before enabling agents against it, which is correct and slow, because the inventory of what is overshared in a large tenant is itself a project. Agencies working under records statutes face the same problem with a longer memory, as the case of AI on Privacy Act records shows: the records were always there, and the sharing state was always wider than anyone would have chosen.

How do overprivileged service identities finish the job?

When an agent moves to production it is given its own identity: a service account, an API key, a role. This is the moment a deliberate scope could be set, and the moment most often skipped. The identity is cloned from one that already works, granted broad rights so the agent will not fail on an unexpected screen, or given a long-lived key because rotation is tedious. OWASP's Top 10 for non-human identities names the outcomes: overprivileged identities, and secret leakage of API keys, tokens, encryption keys and certificates to unsanctioned data stores (OWASP, 2025).

The cloud providers' guidance says not to do this. Google Cloud's best practices for service accounts recommend narrow, purpose-specific accounts (Google Cloud, 2026), and AWS's IAM best practices recommend least privilege and temporary credentials (AWS, 2026). The guidance exists because the default runs the other way.

Path to full access How it happens What would limit it
Inherited user session Agent runs inside a signed-in session and holds everything the person holds A session scoped to the task, with screens substituted before the model reads them
Permissive sharing defaults Stores shared to the most permissive option; the agent surfaces what was always reachable Sharing review before agents are enabled, plus per-task limits on what the agent reads
Overprivileged service identity Identity cloned or over-granted to avoid failures; long-lived keys Least privilege per the providers' guidance, plus a recorded scope for the agent

The three paths compound: an agent that started on an inherited session, was enabled against overshared stores and then received an over-granted identity has full access three times over, and closing one path leaves the other two.

Why did nobody decide this?

Because each step was someone else's job and none of them was about data. The builder chose the session because it worked. The library owner never chose the sharing setting; the platform did. The platform team provisioned the identity to match what was already running. Each decision was reasonable in its own frame, and the frames never met. OWASP's definition of excessive agency, a model granted more functionality, permission or autonomy than its task requires, describes the result exactly, and the definition's point is that excess is a property of the grant, not of the model's behavior (OWASP, 2025).

The governance literature anticipates this. Gartner's position is that uniform governance across all agents leads to failure, which cuts both ways: a single broad grant for every agent is uniform governance, and so is a single blanket prohibition (Gartner, 2026). The decision has to be per agent and per task, and that requires someone whose job is to make it. Zero trust architecture names the structure: a policy decision point that evaluates each request against policy, and an enforcement point that applies it, rather than access granted once by session or identity and assumed thereafter (NIST, 2020).

Finding inherited access after the fact requires a record of what each agent actually read. An audit of sensitive data access across applications that works from identity permissions alone will show what an agent could reach; a run-level record shows what it did reach, screen by screen, and the gap between the two is the measure of how much inherited access the agent is carrying.

What does a governed environment change?

A governed environment changes what an inherited session yields: the agent still runs under the user's permissions, but each record those permissions open reaches the model as tokens, so full access to the application no longer means full access to the data.

The mechanism is a class of control that sits between the rendered screen and the model. Sensitive values on the screen are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized for each workflow and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

The three inheritance paths on this page are left as they are and made survivable. SharePoint's permissive sharing defaults still surface overshared content to an agent that respects existing permissions (Microsoft Learn, 2026), but what surfaces to the model is a token. An overprivileged service identity still produces excessive agency in OWASP's sense (OWASP, 2025), but the actions that agency could take wait for a person. And the question this page says a buyer should ask, what the model receives from each record type as values or as tokens, becomes answerable for one agent and one task from the run record, because someone decided the tokenization and the record shows it.

The environment does not change the permissions, the sharing defaults or the identity model; the cleanup of inherited access remains the organization's work.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design addresses the three paths without changing any of them. A governed environment in the customer's cloud runs the agent with the user permissions the organization already grants, unchanged, so the identity and sharing questions remain the organization's to settle. What changes is what the model receives: substitution at the render layer before any model reads the screen, with consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, so a personnel file surfaced by an overshared library arrives at the model with its identifiers as tokens. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, which the company calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The environment is model agnostic and requires no per-application integration.

Deployments are in pilot. On the reader's own agent, a pilot would show the gap between what the identity could reach and what the model received, screen by screen, and who confirmed the scope. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Microsoft Learn's guidance for preparing SharePoint for Copilot and agents (updated July 2026; vendor documentation), Brave's security analysis of indirect prompt injection in an agentic browser (2025; vendor security research), Google Cloud's and AWS's published best practices for service accounts and IAM (2026; vendor documentation), Microsoft's taxonomy of failure modes in agentic systems (2025; vendor whitepaper), OWASP's Top 10 for non-human identities and LLM06:2025 entry (standards), NIST Special Publication 800-207 (2020; official guidance), Gartner's May 2026 press release on agent governance (industry analysis) and RedactSure research pages. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed. Vendor behavior is described from the pages reviewed, and "not described in the pages reviewed" means exactly that. The Brave analysis concerns one agentic browser at one date and is cited for the structural point it makes about logged-in sessions, not as a statement about that product today. Vendor features and defaults change, and the page carries its date. The cloud providers' best-practice pages are cited for their general recommendations on machine identities, not for any statement about agents specifically. Statements about RedactSure describe its current design, with deployments in pilot. The personnel record, document library and holiday agent used as a worked example describe a record type and a task, not any organization.

Whether a given agent's identity, session design and sharing state meet an organization's obligations is a determination for its counsel, its assessors and its own security and compliance officers. This page supports that review and does not replace it.

What the record shows

Agents end up with full access to sensitive records through three paths that nobody chose as a data decision: an inherited user session that makes the agent a trusted party on every origin the person is signed into, sharing defaults set to the most permissive option that the agent then surfaces, and a production identity granted more than the task needs because narrowing it was slower than copying it. Vendor documentation confirms each path in its own words, and the cloud providers' own guidance describes the opposite practice. The remedy has two parts: settle identity and sharing per the existing guidance, and separately decide, per agent and per task, what the model may receive from each screen, with RedactSure's design handling the second part at the render layer. The test is to name one agent and one task and ask which of the three paths it arrived by, and who decided.

Frequently asked questions

If the agent only has the permissions its user has, what is the problem?

That the user's permissions were set for a person in a role, accumulated over years, and shaped by sharing defaults nobody reviewed. A person exercises those permissions with judgment and effort; an agent exercises all of them at once, on request, in seconds. The permission set is the same. The reach is not, and the agent's task almost never requires the whole set. The question to ask is what the task needs, not what the user has.

Is an inherited session ever acceptable?

For a builder testing an agent on their own account with no sensitive records in reach, it is the natural starting point. For anything that reads untrusted content or touches sensitive records, it is the configuration in which an injected instruction has the most to work with, because the agent is trusted on every origin the person is signed into. Production agents should hold an identity and a session scoped to the task, not a person's.

How do we find overshared content before enabling agents?

Start with the stores that hold the most sensitive record types and review their sharing state against who actually needs them, rather than attempting the whole tenant at once. Microsoft's guidance for SharePoint describes tooling for this review. In parallel, decide per agent what it may read regardless of sharing state, so that an overshared folder found later does not become an exposure in the interval before it is fixed.

What does least privilege mean for an agent identity?

A purpose-specific identity granted only the applications and record types the task requires, with temporary credentials rather than long-lived keys, as the cloud providers' guidance describes for service accounts generally. For an agent it also means a recorded scope, signed by the owner of the records, stating which fields the model may receive as values. Cloning an identity from another agent produces that agent's privilege, not this agent's minimum.

Does tokenizing what the agent sees fix inherited access?

It fixes the consequence without fixing the cause. If every screen the model reads has its identifiers as tokens, then an agent that reaches an overshared personnel file receives a file whose identifying values are surrogates, and an injected instruction that directs it to exfiltrate gets tokens. The identity and sharing problems remain and should still be addressed through the providers' guidance. The two controls work at different layers and both are needed.

How would we know an agent already has full access?

Compare two lists. The first is what the agent's identity can reach, from the permission model. The second is what the agent actually read, from a run-level record of screens, actions and approvals. If there is no second list, the agent's reach is unknown and should be assumed to equal the first. If the second list exists and is much shorter than the first, the gap is inherited access the agent is carrying but not using, and it should be removed before it is used.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.