Every team deploying AI agents hits the same question: how do I secure this thing? The honest answer is it depends on what you let it do — and that's exactly the gap AWS's new Agentic AI Security Scoping Matrix fills. It's the structured way to right-size security to autonomy, instead of guessing.
Here's the matrix, plus the part AWS won't tell you: in a regulated environment, most teams are running high-autonomy agents on low-autonomy security.
Practitioner guidance, not legal or audit advice.
The core idea: autonomy drives risk
The more an agent can do without a human in the loop, the bigger the blast radius when it's manipulated — and agents will be manipulated, because indirect prompt injection turns retrieved content into instructions the model can't reliably distinguish from yours.
So you do two things: classify the agent by how much agency it has, then apply controls that match that level. A read-only assistant and a self-initiating workflow agent are not the same security problem.
The four scopes (autonomy levels)
| Scope | Name | What it can do | Example |
|---|---|---|---|
| 1 | No Agency | Read-only; recommends only — a human executes everything | Reads your calendar, can't book |
| 2 | Prescribed Agency | Proposes changes, but every action needs human approval | Suggests a meeting time; you approve |
| 3 | Supervised Agency | Acts autonomously inside set boundaries — no per-action approval | Books the optimal slot within your rules |
| 4 | Full Agency | Self-initiating, runs continuously with minimal oversight | Watches meeting notes and schedules follow-ups itself |
Scope climbs, risk climbs, and the control bar climbs with it. A Scope-4 agent needs containment and behavioural monitoring a Scope-1 assistant never will.
The six security dimensions
These apply at every scope — the depth increases as you go up:
- Identity Context — authenticate the user, the service, and the agent. Stop the agent from escalating beyond the person it's acting for. This is where AgentCore Identity and least-privilege IAM live.
- Data, Memory & State Protection — an agent's persistent memory is an attack surface. Guard it against poisoning (a planted "memory" that steers future actions).
- Audit & Logging — capture the agent's reasoning chains and tool calls, not just the API calls. You need to reconstruct why it did something, not just what.
- Agent & LLM Controls — guardrails, sandboxing, output filtering, containment. Bedrock Guardrails sit here.
- Agency Perimeters & Policies — the hard boundaries on what the agent is allowed to do, enforced outside the prompt (where they can be trusted).
- Orchestration — securing agent-to-tool and agent-to-agent interactions, and the execution flow between them.
How you actually use it
- Classify each agent — be honest about its scope. "It only books meetings within rules" is Scope 3, not Scope 1.
- Apply the control set for that scope across all six dimensions.
- Re-classify when you expand it — adding a tool or removing an approval step can bump an agent from Scope 2 to Scope 3, which changes the control requirements.
The opinionated part: scope creep is the real risk
Here's what I see: teams prototype a Scope-1 assistant, then quietly add tools and remove the approval step until it's a Scope-3 or Scope-4 agent running on Scope-1 security. Nobody re-ran the matrix. The agent can now take real actions, and the only thing standing between a poisoned document and a production change is a prompt the model can be talked out of.
The discipline the matrix forces: the security level follows the autonomy level, automatically. If you can't articulate which scope an agent is in, you don't know what it can do — which is itself the finding.
The CPS 234 / APRA lens nobody else applies
For an APRA-regulated entity, the matrix maps straight onto obligations you already have. A Scope-3 or Scope-4 agent is, in control terms, a non-human identity with standing permission to act — which is the same risk as a human with standing admin, a finding under CPS 234's implementation-of-controls and Essential Eight "restrict admin privileges". The difference is the agent takes instructions from untrusted text.
Translated to CPS 234, the six dimensions become evidence you'll need to produce:
| Matrix dimension | CPS 234 evidence |
|---|---|
| Identity Context | IAM/AgentCore scoping; the agent can't exceed its caller |
| Memory & State | Where memory lives, how it's protected, who can write to it |
| Audit & Logging | CloudTrail + reasoning-chain logs — "what did the agent do, for whom" |
| Agent & LLM Controls | Guardrail config + containment boundaries |
| Agency Perimeters | The IAM/policy boundary, enforced outside the prompt |
| Orchestration | The tool-authorization model |
If you're putting an agent anywhere near regulated data, classify it on the matrix first, and keep the classification as evidence.
Get the reference
The full scopes × dimensions matrix as a one-page reference is on the resources page — print it, classify your agents, and keep it with your control evidence. The control patterns behind the Identity and Agent-Controls dimensions are in least-privilege for AI agents and securing a Bedrock app end-to-end.
Deploying agents in an APRA-regulated environment and want the control set mapped to your obligations? That's part of a CPS 234 on AWS readiness assessment.
Primary sources: AWS Agentic AI Security Scoping Matrix · Four security principles for agentic AI systems · Amazon Bedrock AgentCore Identity