Scoping Agent Access to Sensitive Data Resources

Agent access control needs two dials, not one: how autonomous the agent is, and how sensitive the data it can touch. Most companies still set access policy by asking only whether an identity can reach a resource, a standard that fit the human era but doesn't fit the agent era. Get either dial wrong and the agent either can't do its job or can quietly hand your HR database to a marketing intern's chatbot. This is the operational map for setting both dials correctly, at every level of an agent's life span.

The two variables that determine how much an agent can harm you

Traditional access control asks one question: what can this identity reach? Agent access control needs two: how autonomous is the agent, and how sensitive is the data it touches?

A read-only agent that runs constant, self-triggered queries across a huge slice of company data is not the same risk as a write-capable agent that waits for a human to click "approve" before it does anything. Treating those two as the same problem, just because both are called "agents," is where most governance plans fall apart before they start.

Ken Huang's Cloud Security Alliance write-up from December 16, 2025 names this gap directly. It points out that the AWS Agentic AI Security Scoping Matrix conflates two separate things: what operations an agent can perform (read vs. write) and how much oversight sits on top of it (human-checked vs. self-directed). Treating both together produces ambiguous risk scores. The fix is to score on the intersection of the two, not either one alone.

Four rough combinations fall out of that intersection. Low autonomy paired with low sensitivity is the easy case, standard role-based access and normal logs cover it. High autonomy with low sensitivity still needs behavioral monitoring, because a read-only agent querying constantly can piece together sensitive conclusions from non-sensitive fragments, a kind of exfiltration through aggregation rather than theft. Low autonomy with high sensitivity needs strict data classification and a human checking every action before it fires. High autonomy with high sensitivity is where you need the whole stack at once: scoped identity, live monitoring, a kill switch, and a full audit trail.

Huang's sharper point is that AWS's Scope 1, originally labeled "No Agency," undersells itself. He'd rename it "Read-Only Limited Agency," because even an agent that can't write anything still decides, on its own, which sources to query and how to phrase the request. That's agency. And it opens a data-exfiltration path even without a single write permission ever being granted.

The dollar figure attached to getting this wrong is not abstract. IBM's 2025 research put breaches involving unauthorized AI tools at an average cost of $4.63 million, about 16% above the $4.44 million global breach average. Among organizations that suffered an AI-related breach, 97% didn't have proper AI access controls in place. That's not a rounding error, that's nearly every incident sharing the same root cause.

How the AWS Agentic AI Security Scoping Matrix maps autonomy levels

AWS published the original framework on its Security Blog on November 21, 2025, credited to Aaron Brown and Matt Saner. It sorts agentic systems into four scopes based purely on how much agency and autonomy they carry.

Scope 1, No Agency (or Huang's proposed "Read-Only Limited Agency"), covers human-initiated, read-only work. Human oversight is baked into the design by default, but the aggregation risk described above doesn't go away just because nothing gets written.

Scope 2, Prescribed Agency, lets the agent draft and stage changes, but nothing executes without a person signing off first. Oversight here is a pre-execution gate on every single action.

Scope 3, Supervised Agency, is where things get looser. The agent runs multi-step workflows on its own, inside boundaries set at activation, and a human isn't approving each step anymore. Oversight shifts from per-action sign-off to continuous monitoring and the ability to shut the thing off if it drifts.

Scope 4, Full Agency, removes the human from activation entirely. The agent triggers itself off events, no approval needed to start or to act. At this level, human-in-the-loop stops being the control. Kill switches and automated shutdown mechanisms become mandatory, not nice-to-haves bolted on later.

Multiple security dimensions run across all four scopes, covering areas such as identity, data protection, audit and logging, model controls, and orchestration. None of these are checklist items you tick once. Each one demands more as the scope climbs, which makes the matrix a set of escalating obligations rather than a single pass-fail test.

The failure mode that shows up most often in classification exercises isn't a bad initial score, it's scope creep nobody re-checked. A Scope 1 assistant picks up a ticket-creation tool one sprint, a status-update tool the next, and before long it's functionally a Scope 3 system still wearing Scope 1 controls. Nobody re-classified it because nobody thought a small tool addition counted as a scope change.

Multi-agent systems make this worse, because the matrix, as written, scores one system at a time. A Scope 2 orchestrator that hands off tasks to a Scope 3 sub-agent is, in practice, a Scope 3 system with a Scope 2 label stuck on the front. The workable rule: score the whole deployment at the highest scope held by any single member of it.

Layering data sensitivity onto the autonomy axis to get the full picture

Autonomy scope tells you how much human oversight sits on top of the agent. Data sensitivity tells you what an unsupervised mistake actually costs you. Neither number means much without the other sitting next to it.

Huang's CSA framework turns this into a 3x3 grid: three tiers of data operation (read-only, write-only, read/write) crossed with three tiers of autonomy (low, medium, high). That produces nine distinct cells, each with its own risk profile and its own set of required controls, rather than four scopes trying to do double duty.

The sensitivity side of that grid breaks down fairly cleanly. Public or internal-use data sets a low classification floor, so the main job is stopping write-access sprawl and watching for unusual query volume. Confidential material, financial projections, strategic plans, anything PII-adjacent, needs enforced data classification and query boundaries even when the agent is read-only and sitting at medium or high autonomy. Regulated or highly sensitive data, PHI, PII, source code, legal records, executive email, needs the full set regardless of scope: semantic access controls, data-loss-prevention policies, encrypted state between operations, and per-action logging.

Security guidance consistently flags a particularly risky combination: an agent with access to sensitive data that also takes in untrusted external content and holds permission to communicate outside the organization. Any agent sitting at high autonomy and high sensitivity that meets all three conditions is grounds for an immediate architecture review.

Memory compounds the problem rather than sitting off to the side of it. An agent that remembers things across sessions, as either autonomy or sensitivity climbs, opens a surface where persistent state can be tampered with or misused across interactions. Encrypting state between operations and locking down persistent storage belongs in the data-sensitivity control layer, not filed separately under autonomy.

The tool list an agent has is, functionally, its permission list. An agent doing competitive research and an agent handling customer escalations can run under the exact same employee's login and still carry wildly different sensitivity profiles. Scope permissions to the data the specific task actually needs, not to the team the employee sits on.

What least-privilege access looks like in practice for agents, not humans

Least privilege for a person and least privilege for an agent are not the same discipline wearing different clothes. People have managers, onboarding paperwork, and an exit interview that (usually) triggers offboarding. Agents get spun up by a script and can keep running indefinitely, with standing permissions nobody circles back to review.

Three properties separate agent least-privilege from a static role-based model. Permissions should be task-based, tied to what the agent is doing right now rather than which team it's nominally assigned to. They should be time-bound, expiring when the task ends instead of surviving until the next quarterly access review rolls around. And they should be identity-driven, with each action traceable to a defined non-human identity that has a documented owner, not quietly inherited from whichever employee happened to provision it.

Microsoft's own framing of the risk is blunt: an agent running without a managed identity and least-privilege role-based access can access or modify sensitive data well beyond what was intended, if the controls around it weren't configured properly in the first place.

AWS's progressive autonomy guidance argues that autonomy should expand based on demonstrated performance, not get handed out by default on day one. For anything high-consequence, touching production data, moving money, sending sensitive information outside the company, a human makes the final call at launch. The agent recommends. A person approves. That relationship only loosens once the agent has earned it.

There's a trap on the other side of this, too. Force a human to approve every single agent action at scale, and you get reflexive clicking, not real oversight. Nobody reads the fortieth approval request of the day with the same attention as the first. The fix is to reserve human-in-the-loop for the genuinely high-consequence cases, the high-autonomy, high-sensitivity intersection, and let monitoring, not approval fatigue, cover everything else. The two-dimensional matrix doubles as a budget tool here: it tells you exactly where oversight spending earns its keep and where it's wasted.

Where the permission model breaks down at the integration layer: MCP and inherited access

Here's the part most governance plans miss entirely. In most enterprise setups, agents don't get their own permissions. They inherit whatever access belongs to the employee or service account that spun them up, which means an over-provisioned human account is already an agent-access problem before any agent exists.

Metomic has documented versions of this scenario: an employee retains stale access to sensitive resources from a previous project and creates an agent for an unrelated task. The agent, doing exactly what agents do, scans everything it can reach and surfaces confidential material in response to a completely routine question. No rule got broken. No alert fired. The permissions were technically valid the entire time, which is precisely the problem.

MCP, the Model Context Protocol, makes this worse by scale. It's the open standard that lets agents plug into outside tools, databases, and services through one consistent interface, and Recent research has found it present in a large majority of observed cloud environments. Authentication wasn't part of the original spec. OAuth support only arrived in March 2025, and it's optional, which means it's frequently skipped.

That gap has already been demonstrated. Invariant Labs confirmed in April 2025 that a poisoned math tool, one with malicious instructions buried in its description, could read SSH keys and exfiltrate them out of the session, with zero user interaction required. The model simply followed instructions it had been fed before the user ever typed anything, with no need to be tricked in the moment. It just followed instructions it was fed before the user ever typed anything.

Identity systems weren't built to catch this. They know who made a request. They don't know which MCP server that request passed through, what tools that server exposed, or whether the tool description the model read at the start of the session matches what got reviewed when the tool was first deployed.

Shadow agents pile on top of both problems. Employees and developers stand up local agents, assistants embedded in their code editor, and MCP servers with no review process attached. Security teams can't scope permissions or watch behavior for an agent they don't know is running. The Cloud Security Alliance found that 38% of employees share confidential data with AI platforms without any approval process at all.

The thread connecting all of this back to the two-dimensional matrix: inherited permissions and MCP's tool authority are exactly how an agent's real-world data exposure ends up bigger than the classification it was assigned on paper. The scope you assign at design time is a plan. What the agent can actually reach at runtime is a different, often larger, number.

What runtime monitoring must cover that access controls alone cannot

Access controls set the fence. Runtime monitoring is what tells you whether anything jumped it. A well-scoped agent that runs into a prompt injection mid-task can end up exceeding its own permissions without a single access-control rule getting broken, because the breach didn't happen at the boundary, it happened in how the agent interpreted an instruction.

Monitoring built for agents needs to check identity at the moment of action, confirming that the thing acting right now is the thing that was originally authorized. It needs behavioral anomaly detection: query patterns drifting outside the agent's assigned task, data-access volume spiking, or the agent touching systems it's never touched before. It needs logging at the level of individual tool calls and API requests, particularly for Scope 3 and Scope 4 agents where there's no human checking each step. And it needs to watch memory and state directly, since what an agent stores between sessions is itself a place an attack can live.

A supply-chain breach in 2025 shows what happens when that monitoring isn't there. Attackers hijacked a chat agent integration and used it to breach more than 700 organizations across Salesforce and Google Workspace, with Slack affected in some cases, and the credentials harvested carried downstream risk into Amazon S3 and Azure. Obsidian's researchers found the blast radius roughly ten times larger than earlier incidents where attackers went after Salesforce directly. The OAuth tokens involved, tied to the Salesloft-Drift integration, granted access into hundreds of downstream environments from a single point of failure.

A compromised agent doesn't stop at leaking a file. It can push through unauthorized transactions, alter infrastructure that matters, or keep operating quietly for a long stretch before anyone notices. The damage isn't set by the initial break-in, it's set by how long the detection gap runs.

Deloitte's survey found 74% of companies planning to expand agentic AI deployment moderately or more within two years. Only 21% of the leaders surveyed said they had a mature governance model for autonomous agents already in place. That gap, deployment racing ahead of governance, is exactly where runtime monitoring earns its cost.

Compliance frameworks are starting to catch up, though unevenly. frameworks including ISO 42001, NIST AI RMF, and GDPR all now touch on controls for autonomous systems, though the risk management framework is voluntary guidance rather than a mandate, and ISO 42001's controls apply on a risk basis rather than uniformly. Whatever the framework, one thing isn't optional at the high-autonomy, high-sensitivity end of the grid: a full audit log of every action the agent took. That log is the evidence trail regulators and auditors will eventually ask to see.

Putting the two dimensions together: practical access decisions at each intersection

The point of the matrix isn't to file an agent into a cell and call it done. The point is that the cell tells you exactly which access constraints and monitoring obligations apply, in specific terms, not general ones.

For an agent sitting at low autonomy with low-to-medium sensitivity, say a Scope 1 or Scope 2 system querying internal knowledge bases, the priority is enforcing data classification right at the query boundary. The agent should be structurally unable to formulate a query that reaches into a higher-sensitivity store than the one it's scoped for, and standard logging with periodic review is enough to catch drift.

Move up to medium autonomy or medium sensitivity, and query-boundary enforcement alone stops being sufficient. This is where per-task, time-bound permissions and behavioral monitoring for unusual access volume need to come online, even before the agent touches anything classified as regulated.

At the high-autonomy, high-sensitivity intersection, the constraint list gets long fast: scoped non-human identity issued per task, encrypted state between every operation, continuous behavioral monitoring, a working kill switch, and per-action audit logs that satisfy whatever compliance framework applies. Skipping any single one of those at this intersection produces the exact profile behind the AI-related breaches costing companies that $4.63 million average.

None of this works as a one-time classification exercise. Tools get added, orchestrators pick up new sub-agents, and an employee's inherited SharePoint access from a project two years dead is still sitting there quietly widening the blast radius. The matrix only earns its keep if someone re-runs it whenever the agent's tool list, autonomy, or data reach changes, which, per the scope-creep pattern, happens far more often than anyone expects it to.