AWS Agentic AI Security Scoping Matrix: Classifying Agents

The support triage agent is on your inventory as Scope 2. It reads tickets, drafts replies, and a human approves every send. Three sprints later it has a write connector to the ticketing system, replies above a confidence threshold go out without approval, and a webhook starts it on every new ticket. The inventory still says Scope 2. The agent’s behavior now sits higher up the matrix, and nobody built a new image to get it there.

Scope is something you observe, and it drifts. What follows is how to classify an agent you did not build, the three ways an agent drifts up a scope, why under-scoping costs more than over-scoping, how to classify twice (declared and observed), and where the matrix stops.

What the Agentic AI Security Scoping Matrix is

The Agentic AI Security Scoping Matrix is an AWS framework that sorts agentic AI systems into four scopes and maps how security requirements escalate across six dimensions as those systems gain agency and autonomy. AWS introduced it in November 2025 in an AWS Security Blog post, building on its earlier Generative AI Security Scoping Matrix.

The matrix places a system by two properties. Agency is the range of actions a system is permitted and enabled to take, meaning which systems it can reach and what it can modify. Autonomy is how far the system decides and acts without a human stepping in. The two AWS pages label the axes slightly differently: the matrix page sorts the scopes by agency and human oversight, and the blog post sets human oversight against autonomy on one axis, with agency on the other.

Across those scopes, the matrix maps security requirements in six dimensions: identity context; data, memory, and state protection; audit and logging; agent and model controls (agent and LLM controls on the matrix page, agent and FM controls in the blog post); agency perimeters and policies; and orchestration. Requirements in every dimension intensify from Scope 1 to Scope 4.

The matrix comes with a deployment model too. AWS recommends progressive autonomy: start agents at Scope 1 or 2, advance them through the scopes as confidence and security capabilities mature, and put governance around each step up. That model treats a change in scope as a decision a team makes.

The four scopes, in the terms AWS uses

AWS defines four scopes, and they differ on three questions: who starts the agent, whether it can change anything outside itself, and whether a human approves each change before it happens.

Scope	AWS name	Who starts a run	Can it change the environment?	Human approval before a change
1	No agency	A human	No, it is read-only	Not applicable
2	Prescribed agency	A human	Yes	Required for every action of consequence
3	Supervised agency	A human, or an upstream workflow a human manages	Yes	Not required once the run starts; human guidance is optional
4	Full agency	The agent, from environmental triggers, learned patterns, or predefined conditions	Yes, across multiple systems	Not required; humans keep strategic oversight

AWS runs one example through all four scopes: a calendaring agent. At Scope 1 it finds open slots, and a person books the meeting. At Scope 2 it proposes a slot and asks permission to send the invite. At Scope 3 it books the best slot on its own once a person asks. At Scope 4 it reads action items from a meeting summarizer agent and books a follow-up that no one requested.

How to classify an agent you did not build

Classifying an agent you did not build starts with its deployment manifest, because the manifest points to the tools, the tools lead to the approval path, and the approval path leads to the trigger.

1. Read the manifest. On Kubernetes, the Deployment names the service account, the mounted secrets, and the config that points the agent at its tools. On EKS, the service account usually maps to an IAM role through IRSA or EKS Pod Identity, and that role sets the AWS services the agent can reach. The same read applies to any agent on EKS.
2. List the tools. From that config, list every tool, MCP server, and API the agent can call, and mark each one read or write. A read-only connection keeps an agent at Scope 1. AWS’s own Scope 1 example reaches the calendar through an MCP server and still books nothing. The first write tool is what moves an agent past Scope 1.
3. Trace the approval path. For every write tool, find what sits between the agent’s decision and the change: a human approval, an approval with an automatic bypass, or nothing. Any write that reaches the environment without a human approving it places the agent at Scope 3 or above.
4. Find the trigger. Identify what starts a run: a person, an upstream workflow a person manages, or a schedule, queue, or event the agent listens for on its own. A run that begins from a condition the agent watches for is the Scope 4 marker.
5. Place the agent. Assign the highest scope any answer points to, since the controls have to cover the agent’s widest behavior.

Every one of those answers comes from configuration as it stood on the day of the review. Teams run this review once at design time for good reason: the architecture is documented and the owners are in the room. The placement it produces goes into the inventory as the agent’s declared scope, and the configuration keeps changing after that day.

Three ways an agent drifts up a scope

An agent moves up the matrix through three changes: a tool added, an approval removed, and a trigger added. None of them requires a new container image, and each can ship without a design review, because all three live in configuration that changes on a different schedule from the agent’s code.

A tool added

A tool added usually arrives as a config change. A platform team adds an MCP server so the agent can file tickets, or grants the agent’s service account write access to a bucket it only read before. The Deployment rolls, the image digest stays the same, and a read-only Scope 1 agent can now change the environment. If no approval gates the new write, the agent skips Scope 2 and lands at Scope 3.

A remote MCP server can add write tools on its own side, so the agent’s reachable actions grow while its config stays unchanged.

An approval removed

An approval removed often keeps its name. The approval step gets a threshold, so refunds under a set amount or replies above a confidence score go out on their own. It gets a bulk-approve button that clears a queue in one click. Teams justify each change as throughput, and each one makes a Scope 2 agent a Scope 3 agent for every action that clears the threshold.

A trigger added

A trigger added changes who starts the agent. Wiring the agent to a queue, a webhook, a CronJob, or another agent’s output means runs begin without a person asking for them. AWS allows a Scope 3 run to start from an upstream workflow a human manages, so a trigger fed by a person’s action, such as a customer opening a ticket, sits between Scope 3 and Scope 4. A trigger fed by a condition the agent watches for, such as a metric, a meeting summary, or a schedule, meets AWS’s own definition of Scope 4.

All three changes ship as a config update, a feature flag, or a new permission binding, and a review process keyed to new images or new services sees none of them. Each one is a specific kind of behavioral drift: the agent’s behavior changes in a direction the matrix scores as more agency or more autonomy.

Why under-scoping costs more than over-scoping

Both wrong placements cost something, and only one of the costs gets reported.

An over-scoped agent carries controls sized for more agency than it has: extra approval gates, tighter isolation, heavier logging. Those controls slow the agent down, and the team that owns it notices the slowdown and reports it quickly.

An under-scoped agent carries controls sized for a smaller agent. The matrix scales all six dimensions by scope, so a Scope 2 placement sizes identity context, data and memory protection, logging, model controls, perimeters, and orchestration for an agent that waits for approval. If the agent stopped waiting three sprints ago, all six are undersized at once. That gap slows nothing down, so nobody reports it. It surfaces when the agent does something its controls were never sized to record or contain.

So the error worth hunting is the low placement. All three drift changes move an agent up, so each one turns a correct placement into a low one.

Classify twice: declared and observed

Classifying twice means holding two scope readings for every agent and comparing them. The declared scope is the placement on record, produced by the configuration review on the day it ran. The observed scope comes from what the agent did across a window of real traffic: which tools it called, which calls changed state in another system, whether a human approval preceded each change, and what started each run.

The two readings answer different questions. Declared scope says what the team decided the agent is. Observed scope says what the agent does now.

The gap between the two readings has two sources. Configuration that changed after the review is the first, and a more frequent review catches it. The second is change that never appears in the files a review reads: a remote MCP server that adds write tools on its own side, an IAM role or RBAC binding broad enough that nobody traced every write it allows, and an approval bypass implemented in application code instead of config. Runtime records of what the agent called and changed show all three.

A disagreement between the two readings is the finding, and each direction means something different:

• Observed above declared. The agent operates at a scope nobody signed off on, usually through one of the three drift changes. Re-classify it, then size its controls to the observed scope.
• Observed below declared. The agent holds permissions it has not used in the window. The placement stays, because the permissions still exist, and the unused write access is a candidate for removal.

Agreement is a result too. It is dated evidence that the placement held for the window observed.

Observed scope depends on runtime evidence for each individual agent. AWS lists behavioral baselines for normal agent operations among its Scope 3 considerations, and the same baseline answers the classification question.

Runtime behavioral security for AI workloads on Kubernetes produces that evidence from the running workload. ARMO discovers the agents, inference servers, and frameworks in a cluster, builds a runtime bill of materials of the models, retrieval sources, and libraries each agent uses, and maps the path from agent to tool to API to data.

Each agent’s normal behavior becomes its Application Profile DNA (APD™), a behavioral baseline recorded per agent at the Deployment level. A tool the agent never called before, or a write to a system it previously only read, falls outside that baseline. That deviation is evidence for two questions a team has to answer: whether something suspicious happened, and whether the agent’s scope moved.

ARMO learns the baseline in an audit phase, before any policy is enforced. The observed scope therefore exists before anyone has to decide which controls the agent needs.

Where the matrix stops

The matrix sets how strong controls should be at each scope and leaves the question of whether an agent still belongs in that scope to the team running it. AWS covers the ground around that question. Its blog post recommends continuous validation loops that check agent behavior against expected patterns, graceful degradation that tightens restrictions when an agent acts beyond its intended bounds, and governance processes for moving between scopes. The matrix does not specify when the classification itself should be run again.

Re-classify on change events, with a calendar backstop. The change events map one-to-one onto the three drift paths:

• Any change to the agent’s tool configuration or service account bindings, which covers a tool added.
• Any change to an approval step, its thresholds, or its bypass rules, which covers an approval removed.
• Any new trigger, queue subscription, schedule, or event source, which covers a trigger added.

Each of those is a configuration or policy change that a deployment pipeline can flag. The calendar backstop catches what those events miss, such as the remote MCP server that gained write tools with no change on your side. Re-run the observed reading quarterly for Scope 1 and 2 agents and monthly for Scope 3 and 4 agents, where an undetected move costs more.

A current scope makes the controls question concrete. On EKS, that means knowing each AWS control an agent sits behind and where its coverage ends. Keeping the re-classification record next to documented enforcement gives an auditor the placement, the evidence behind it, and the date it was last confirmed.

A scope is a claim about behavior, and claims expire

A filled-in matrix records a decision made on one day about one configuration. The agent keeps running after that day, and the three changes that move it up a scope all happen in configuration that the original review never sees again. A placement is only as current as the last time someone compared it with what the agent did.

Start with the agents whose placement costs the most if it is wrong: the ones with write access to customer data or production infrastructure. For each one, write the declared scope from its manifest, tool list, approval path, and trigger. Then pull a window of runtime records and write the observed scope beside it. Where the two disagree, the placement changes and the controls get re-sized.

The observed reading is the half most teams have no source for, because it takes per-agent runtime evidence from the cluster the agent already runs on. That is what ARMO builds for AI workloads on Kubernetes: discovery of every agent, a runtime bill of materials, and a behavioral baseline per agent that shows a new tool or a new write the day it happens. Run the two readings on five agents this week, and you will know whether your matrix still describes your agents.

FAQ

How do I place an agent that sits between two scopes? Place it in the higher of the two. The matrix sizes controls to what an agent can do, so a placement that fits most runs leaves the rest uncovered. The most common in-between case is the trigger: an agent started by a webhook when a customer opens a ticket is human-initiated upstream, yet no one asks it to run. Treat it as Scope 4 until observed runs show every start traces back to a person’s action through a workflow your team manages.

Does moving from Scope 2 to Scope 3 require a new security review? Yes. The move removes the human approval that Scope 2 controls rely on, so all six dimensions need re-sizing. AWS recommends governance processes for moving between scopes, and a planned move should go through that process. An unplanned move needs the same review, which is why a changed approval threshold should open one automatically.

What evidence shows an agent’s observed scope? Four records settle it: the tools and APIs the agent called during the observation window, which of those calls changed state in another system, whether a human approval preceded each change, and what started each run. Configuration and IAM policy show what is possible, and runtime records show what happened. On Kubernetes, that evidence comes from observing the agent’s own workload, tied to its Deployment. Keep the window long enough to cover the agent’s full cycle, including monthly or end-of-quarter jobs.

Does the matrix apply outside AWS? Yes. AWS defines the four scopes by agency and autonomy, and neither property depends on where the agent runs. An agent on a self-managed Kubernetes cluster, another cloud, or on-premises infrastructure classifies the same way. The scope definitions carry over unchanged, and the services that implement each of the six dimensions depend on your platform.

How often should scope be re-checked? Re-check on every change event, with a calendar backstop. Change events are edits to tool configuration or service account bindings, changes to approval steps or thresholds, and new triggers, queue subscriptions, or schedules. The backstop covers changes outside your own configuration, such as a remote MCP server adding tools. Quarterly suits Scope 1 and 2 agents, and monthly suits Scope 3 and 4 agents, where an undetected move costs more.