AI agents are moving from pilots into production, and the security question is shifting with them. Once an agent can plan tasks, call tools, and act on external systems without a human at each step, scoping AI risk by who owns the stack no longer covers the full picture.
You need a way to reason about how much authority you’ve handed the agent, and what happens when that authority is misused.
The AWS Agentic AI Security Scoping Matrix provides a practical framework for addressing this problem. It classifies agents by two of the primary factors that drive operational risk: how much autonomy the agent has, and how much human oversight sits between it and the systems it can touch.
For CISOs, CIOs, and risk leaders being asked to greenlight agent deployments this quarter, the framework turns a fuzzy conversation into a decision you can document, defend, and revisit as autonomy expands.
Below, you’ll see what the matrix is, why agent autonomy needs its own risk classification, how to apply it across your inventory, and where scoping ends and runtime enforcement begins.
Key takeaways
- The matrix progresses from read-only advice in Scope 1 to independently initiated work in Scope 4, so safeguards should match each agent’s authority.
- Tool access, autonomous actions, distinct identities, and interconnected dependencies create risks beyond AI stack ownership, which is why agentic risk needs its own classification.
- Inventory agents and connections, begin with limited agency, keep deterministic controls outside the model, and require evidence before increasing permissions.
- Continuous monitoring, traceable audit trails, shutoff mechanisms, and inline defenses help contain autonomous workflows at runtime, supporting governance as well as EU AI Act and Digital Operational Resilience Act (DORA) obligations.
What is the AWS Agentic AI Security Scoping Matrix?
The AWS Agentic AI Security Scoping Matrix is a classification framework that helps organizations assess and govern AI agent risk based on two axes: the amount of human oversight in place and the range of actions an agent can take.
AWS built the agentic matrix on top of its earlier Generative AI Security Scoping Matrix. Each one measures something different. The generative matrix classifies workloads by who owns and builds the AI stack, while the agentic matrix classifies them by how much authority an agent has been granted to act on external systems.
AWS illustrates the agentic matrix’s four scopes with a calendar assistant:
- Scope 1 (No Agency). Systems are read-only and advisory. They can recommend meeting times but can’t book them.
- Scope 2 (Prescribed Agency). The agent prepares changes that a human approves before execution. It drafts the invite and fills in the details, but nothing lands on anyone’s calendar until a person confirms it.
- Scope 3 (Supervised Agency). A human initiates the task and the agent books meetings autonomously within bounded parameters, with no per-action review.
- Scope 4 (Full Agency). The agent can initiate work and continue operating with little direct oversight, responding to conditions, patterns, or predefined triggers. A calendar assistant here might notice a recurring conflict and rebook the whole series without being asked. This scope carries the greatest operational risk and benefits from runtime monitoring, deterministic policy enforcement, anomaly detection, and automated containment.
The matrix maps controls to six security dimensions: identity context; data, memory, and state protection; audit and logging; agent and foundation model (FM) controls; agency perimeters and policies; and agent orchestration. Control rigor increases as scope increases.
Why agent autonomy needs its own risk classification
Agent autonomy needs its own risk classification because autonomy sets the ceiling on what an agent can do to your systems when its judgment fails, and nothing else about the stack tells you where that ceiling sits. Two teams can run the same model on the same infrastructure and carry very different exposure, because one agent recommends and the other executes.
Agents have their own identities, operate at greater scale and speed than human actors, and rely on an expanded supply chain of foundation models, plugins, tool servers, and retrieval sources with nondeterministic tool access. A secure design assumes an agent may use its granted entitlements and places appropriate controls around them.
For agents that hold entitlements and invoke tools, the OWASP Top 10 for Agentic Applications 2026 names agent goal hijack, tool misuse, insecure inter-agent communication, memory and context poisoning, cascading failures, and rogue agents among the most critical risks.
Only 17% of organizations have deployed AI agents, and more than 60% expect to within two years. More than 40% of agentic AI projects are forecast for cancellation by the end of 2027. Projects become easier to defend when risk committees can see what an agent may do, who approved it, and who remains accountable.
As organizations move from experimentation toward production deployment, governance and runtime controls become increasingly important as agents gain access to enterprise systems.
You Can’t Secure What You Can’t See
WitnessAI gives you network-level visibility into every AI interaction across employees, models, apps, and agents. One platform. No blind spots.
Explore the PlatformHow to apply the Agentic AI security scoping matrix step by step
Apply the matrix as an AI governance exercise before treating it as a technical one. It brings CISOs, CIOs, risk and compliance leaders, and business owners into the same conversation to determine what the agent can do, who approved its access, and who owns it.
The five steps below move from inventory and classification to control placement, oversight calibration, and runtime monitoring.
1. Inventory agents and MCP connections before classifying anything
Incomplete inventories undermine classification. Centralized agent registries should track deployed agents’ capabilities, permissions, and interdependencies. Unified visibility helps prevent unauthorized deployments such as Shadow AI.
Count browser plugins with tool access, assistants embedded in integrated development environments, software-as-a-service features labeled “AI automation,” and local agent frameworks. Include each agent’s Model Context Protocol servers, or MCP servers, and their connections. Document what each one can read and which external systems it can write to.
2. Classify each system by agency and autonomy
Two questions place a system on the matrix, and the order matters because agency sets the ceiling on what autonomy can do.
- Agency: what is the system permitted to change? Establish whether it only reads, retrieves, and recommends, or whether it can write to external systems and set off downstream effects. This is a question about permissions and reach, not about how capable the underlying model is.
- Autonomy: how much runs without a person? Establish whether every consequential action waits for approval, whether the agent finishes a task on its own once a human starts it, or whether it starts work itself in response to a trigger. This is a question about independence during execution.
Together the answers point to a scope. Read-only means Scope 1, approval on every consequential action means Scope 2, autonomous execution after a human trigger means Scope 3, and self-initiated work means Scope 4.
The two don’t always move together. An agent with broad write access that pauses for approval on every action has high agency and low autonomy, which calls for tighter permission boundaries rather than heavier behavioral monitoring.
A conservative implementation starts at Scope 2 and expands based on evidence. This resembles the incremental approach used when granting a new application additional permissions. Move a workload to Scope 3 after audit trails show that the agent behaves within bounds.
3. Place deterministic controls outside the agent
Security enforcement belongs outside the agent’s reasoning loop, in deterministic infrastructure-level controls rather than in prompts or the model’s own judgment. AWS calls this its most important architectural principle for agentic security, on the reasoning that a language model can be told to respect a boundary but has no reliable way to enforce one. Those controls define which tools and operations the agent can use, while separate data policies determine what it can reach. Model manipulation is less likely to bypass controls the model doesn’t touch.
In practice, assign agent-specific identities and temporary, scoped credentials. Avoid copied human credentials and persistent access, and review tool permissions with the same discipline applied to service accounts.
4. Calibrate human oversight to consequence, not volume
Oversight design determines whether Scope 2 provides meaningful protection. Routing every action through review can produce rubber-stamp approval loops, while routing none creates unbounded autonomy. Reserve mandatory approval for high-consequence operations: financial commitments and access to regulated data sources should receive the same review as destructive changes.
This choice also affects regulatory compliance. The EU AI Act‘s Article 14 requires high-risk systems to be designed for effective human oversight during use.
5. Monitor behavior and trace agent actions to human owners
At Scopes 3 and 4, the matrix shifts emphasis to continuous monitoring practices, behavioral validation, and shutoff mechanisms for autonomous operations. Detailed audit trails should connect actions through the delegation chain to the person who initiated them. Delegation-chain traceability gives boards and regulators evidence they can review.
Can You Prove How Your Organization Governs AI?
WitnessAI generates granular audit trails, enforces policies across every role and region, and redacts sensitive data before it ever leaves your network. Compliance-ready from day one.
See How Control WorksWhere scoping frameworks end and runtime enforcement begins
A scoping exercise covers classification, ownership, and the controls each scope calls for, up to the point where a person signs off on what an agent may do. Runtime enforcement takes over from there, observing, gating, and containing agent behavior in production.
Prompt injection is what makes that handoff necessary. A scope assignment records what an agent is permitted to do, and it stays accurate even while an attacker is using those exact permissions through instructions buried in the content the agent reads. Prompt injection attacks can’t be reliably shut out at the model layer, so the practical design goal is to assume some will land and bound the blast radius when they do.
Memory injection has reached over 95% injection success rates against agents under idealized test conditions, using nothing but ordinary user queries.
When assigned responsibility diverges from live enforcement, AI risk management becomes a broader problem than governance or compliance documentation can solve alone. WitnessAI, The Confidence Layer for Enterprise AI, provides unified AI security and governance for Global 2000 organizations across human employees and AI agents.
WitnessAI connects scope-based decisions to three runtime capabilities:
- Observe: For AI traffic routed through the platform, network-level discovery surfaces Shadow Agents and agentic plugins in Claude Desktop, VSCode, and ChatGPT, along with local frameworks such as LangChain and CrewAI. The platform also discovers the MCP servers those agents reach.
- Control: Intent-based classification reads conversational context in AI interactions captured through the platform, rather than keywords or regex patterns. It then applies allow, warn, block, and intelligent routing while audit trails attribute agent actions to the human identity that initiated them.
- Protect: For agent workflows integrated with bidirectional runtime defense (Witness Protect), the platform scans prompts before an agent processes them and responses before they reach users or trigger downstream actions. These guardrails deliver pre-execution and response protection for autonomous workflows.
Classification determines the appropriate governance posture. Runtime controls enforce that posture once agents begin interacting with enterprise systems.
Used together, these capabilities translate assigned scopes into network-level visibility, intent-based control, and inline runtime enforcement.
From scoping decisions to runtime confidence
Before deployment, assign a business owner and record each system’s scope within the AWS Agentic AI Security Scoping Matrix.
Document what it can read and write, then define the evidence required for any move to greater autonomy. Validate agent-specific identities, scoped credentials, approval paths, monitoring, shutoff mechanisms, and delegation-chain audit trails against that scope.
WitnessAI combines intent-based intelligent policies with runtime guardrails across human employees and AI agents. To see how WitnessAI lets you adopt AI confidently while supporting your scoping decisions, schedule a demo.