Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Agentic AI risk must be classified by autonomy and human oversight, not just by who owns the stack, because two agents on the same model can carry very different exposure, according to WitnessAI. That assumption collapse is now visible in production deployments where agents plan, call tools, and act on external systems without per-step human approval.
NHIMG editorial — based on content published by WitnessAI: the AWS Agentic AI Security Scoping Matrix and its implications for agent governance
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams inventory AI agents before granting production access?
A: Start by building a register that links each agent to its owner, the identities it uses, the systems it can reach, and the data it can touch.
Q: Why do AI agents need separate governance from ordinary automation?
A: AI agents need separate governance because they can make context-sensitive decisions and execute actions across multiple systems with delegated access.
Q: What are the signs that an AI agent has gone out of scope?
A: Common signs include attempts to use unapproved tools, unexpected access to production data, spawning additional agents without a clear mandate, and repeated requests that expand beyond the original task.
Practitioner guidance
- Inventory every agent and tool connection Track deployed agents, browser plugins, embedded assistants, MCP servers, and any external systems they can read or write to before assigning a scope.
- Assign scope based on agency and autonomy Classify each agent by what it can change and how much runs without a person, then document the evidence required before moving it to a higher scope.
- Move deterministic controls outside the model Use scoped credentials, tool allow lists, and infrastructure policy so the agent cannot override boundaries through prompt instructions or model reasoning.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- The full four-scope matrix with AWS-style examples of read-only, approved, supervised, and fully autonomous agency
- Step-by-step inventory guidance for agents, MCP servers, plugins, and delegated tool paths
- Runtime control examples covering audit trails, shutoff mechanisms, and deterministic enforcement outside the model
- Practical guidance for aligning scope decisions with EU AI Act and DORA obligations
👉 Read WitnessAI's analysis of the AWS agentic AI security scoping matrix →
Agentic AI scope matrices: are your controls keeping up?
Explore further
14/09/2026 10:10 am
Agentic AI governance fails when autonomy is treated as a side effect instead of a primary control variable. The article is right to separate who owns the stack from what the agent can actually do at runtime. Two agents can share the same model and infrastructure yet carry radically different risk because one recommends and the other executes. That is why identity governance for agentic systems has to classify authority, not just inventory assets. Practitioners should treat autonomy as a first-class governance boundary.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, which means visibility is already lagging deployment.
A question worth separating out:
Q: What should organisations do when an AI agent can initiate work on its own?
A: Treat the agent as a governed identity with runtime controls, not as a passive application feature. Require traceable ownership, scoped credentials, containment paths, and a clear escalation rule for high-consequence actions so self-initiated activity stays inside documented boundaries.
👉 Read our full editorial: AWS agentic AI scope matrix exposes the governance gap
