A layer-by-layer control map for agentic systems — what actually goes wrong at each layer, how to prevent and detect it, which tools do the work, and where the real trade-off between innovation and control sits.
With a chatbot, the risk was confidentiality. With an agent holding tool access, the risk is authorisation and blast radius.
That sentence is the whole argument, and it is worth being precise about why. A model that answers questions has one failure mode that matters: it says something it should not have said. You control that at the output. An agent that plans over a long horizon, invokes tools, writes to systems and spawns sub-agents has a different failure mode — it does something nobody authorised, assembled from a chain of individually permitted steps.
The CISA and ASD ACSC guidance on careful adoption of agentic AI services frames the system in four layers. The frame is useful because each layer fails differently and is defended differently.
What follows takes each layer in turn: the risks that actually materialise, each mapped to OWASP’s LLM Top 10, the relevant MITRE ATLAS technique and a NIST AI RMF subcategory — then the preventive control, the detective control, the configuration that makes both real, and the category of tooling that implements it.
One framing note before the tables. Prevention and detection are not alternatives. Every row below has both, deliberately, because a preventive control you cannot verify is an assertion, and a detective control with nothing preventing the event is an incident-report generator. The configuration column is where the two meet — it is the setting that turns an intention into a control.
The guide names five agentic AI risk categories. They are the organising frame for everything below.
Over-broad permissions, scope creep, identity spoofing, and the confused-deputy pattern.
Unvetted third-party components, stale start-up authorisation, poor segmentation between agents.
Goal misalignment and specification gaming, deception under evaluation, prompt injection and jailbreaks.
Cascading failure across coupled agents, tool squatting, rogue agents, insecure agent-to-agent traffic.
Opaque decision chains, sub-agent delegation, hallucination, logs that outpace human review.
Six control categories cover most of them that cover most of them. The practical question is never “what is the best tool” — it is “what do I already own that does this”.
The practical question is never “what is the best tool” — it is “what do I already own that does this”. Six control categories cover most of the four risks above, and most organisations can cover the first two and the last one with services already inside their cloud subscription.
Model layer — the controls below are the same whichever you run:Claude Anthropic API · Bedrock · VertexOpenAI OpenAI API · Azure OpenAIOpen weights Llama · Mistral, self-hosted
| Control — what it does | If you run AWS | If you run Azure / Microsoft | Open source / stack-neutral |
|---|---|---|---|
| 1 Agent identity and secretscovers Privilege · Accountability | IAM Roles Anywhere · Secrets Manager | Entra Workload ID · Key Vault | SPIFFE / SPIRE · HashiCorp Vault |
| 2 Policy at the tool boundarycovers Privilege · Design & config | Cedar · Verified Permissions | Entra Conditional Access · OPA on AKS | Open Policy Agent |
| 3 Guardrails on input and outputcovers Behaviour | Bedrock Guardrails | Azure AI Content Safety · Purview DLP | Lakera · NeMo Guardrails · Presidio |
| 4 Sandboxed tool executioncovers Structural · Design & config | Fargate · Lambda (Firecracker) | Container Apps · Container Instances | gVisor · Firecracker · E2B |
| 5 Evals as the release gatecovers Behaviour · Accountability | Bedrock Evaluations | Azure AI Foundry evaluations | Promptfoo · DeepEval · Ragas |
| 6 Trace and immutable audit logcovers Accountability · Structural | CloudTrail → Security Lake | Azure Monitor → Sentinel | Langfuse · OpenTelemetry → Splunk |
User prompt · operating context · config · audio/video · documents · vector & RAG data · triggers
The ingestion boundary is the cheapest place to stop an attack — and the one most often left open because the content is ‘internal’.
| # · Cyber risk · OWASP / MITRE ATLAS / NIST AI RMF | Prevention · Detection · Configuration · Example tools |
|---|---|
1 Direct prompt injection overriding operator instructions OWASP LLM01 · AML.T0051.000 Direct Prompt Injection NIST MEASURE 2.7 | Prevent · Instruction / data separation at the boundary Detect · Injection classifier on the prompt stream Configure · Untrusted content in a channel separate from the system prompt Example tools · Azure AI Prompt Shields · Bedrock Guardrails · Lakera Guard |
2 Indirect injection embedded in documents or RAG content OWASP LLM01, LLM08 · AML.T0051.001 Indirect Prompt Injection NIST MEASURE 2.7 | Prevent · Strip embedded instructions before indexing Detect · Provenance diff on every corpus change Configure · Source allow-list with a trust tier per source Example tools · Microsoft Purview · MS Presidio · Apache Tika |
3 Poisoned or tampered retrieval corpus OWASP LLM04, LLM08 · AML.T0070 RAG Poisoning NIST MAP 4.1 | Prevent · Signed, versioned corpora; write access restricted Detect · Index integrity hashing against a baseline Configure · Immutable snapshots; rollback point per re-index Example tools · Sigstore / cosign · LakeFS · DVC |
4 Regulated data ingress — CUI, PHI, PII, privileged OWASP LLM02 · AML.T0057 LLM Data Leakage NIST MEASURE 2.10 | Prevent · Redaction and minimisation at the boundary Detect · DLP alerting on prompt content Configure · Classification labels enforced pre-processing Example tools · Microsoft Purview · Google Cloud DLP · Nightfall |
5 Malicious uploads and parser exploits OWASP LLM03 · AML.T0011.000 Unsafe ML Artifacts NIST MEASURE 2.7 | Prevent · Sandbox detonation before the parser sees the file Detect · AV / EDR plus parser crash telemetry Configure · File-type allow-list; size and token ceilings Example tools · ClamAV · VirusTotal · Palo Alto WildFire |
6 Forged or unauthenticated triggers OWASP LLM10 · AML.T0034 Cost Harvesting NIST MEASURE 2.7 | Prevent · Signed webhooks and mTLS on every trigger path Detect · Alert on any trigger from an unknown identity Configure · Auto-trigger off by default; per-source rate limits Example tools · Entra ID / Okta · Kong / Apigee · Istio mTLS |
Training data · algorithms · pre-trained LLM · fine-tuning data
Most organisations buy this layer rather than build it — which makes vendor terms, version pinning and an AIBOM the real controls.
| # · Cyber risk · OWASP / MITRE ATLAS / NIST AI RMF | Prevention · Detection · Configuration · Example tools |
|---|---|
1 Training-data poisoning and implanted backdoors OWASP LLM04 · AML.T0020 Poison Training Data NIST MEASURE 2.6 | Prevent · Curated sources with provenance review before use Detect · Backdoor and canary probes on held-out evals Configure · Dataset version pinning with attestation Example tools · Cleanlab · Great Expectations · TF Data Validation |
2 Model supply-chain compromise — weights, adapters, registries OWASP LLM03 · AML.T0010.003 ML Supply Chain: Model NIST GOVERN 6.1 | Prevent · Trusted registries only; verify signatures Detect · Hash mismatch alert on every artifact pull Configure · Pinned model versions; auto-upgrade blocked Example tools · Sigstore / cosign · Protect AI ModelScan · HF scanning |
3 Fine-tuning leakage of regulated or privileged data OWASP LLM02 · AML.T0057 LLM Data Leakage NIST MEASURE 2.10 | Prevent · Minimisation and redaction ahead of any tune Detect · Memorisation and extraction probes post-tune Configure · Isolated tuning environment; production data excluded Example tools · MS Presidio · Gretel · Opacus |
4 Unverified provenance and licence contamination OWASP LLM03 · AML.T0010.002 ML Supply Chain: Data NIST MAP 4.1 | Prevent · Licence review gate before dataset ingestion Detect · Periodic dataset and licence audit Configure · AIBOM entry mandatory per dataset and adapter Example tools · CycloneDX AI-BOM · SPDX · FOSSA |
5 Model or embedding theft by extraction OWASP LLM10 · AML.T0024.002 Extract ML Model NIST MEASURE 2.7 | Prevent · Export restriction; keys held in a broker Detect · Rate and volume anomaly on the inference API Configure · Per-key quotas and an egress allow-list Example tools · AWS WAF · Cloudflare · HashiCorp Vault |
6 Silent vendor model update invalidating validation OWASP LLM03 · AML.T0010.001 ML Supply Chain: Software NIST MANAGE 4.1 | Prevent · Contractual notice of material model change Detect · Eval regression run on every version change Configure · Version pin plus a staged promotion gate Example tools · MLflow Registry · Weights & Biases · Bedrock / Azure OpenAI pinning |
LLM core · planning · memory · tools & data · action and execution privileges
With a chatbot the risk was confidentiality. With an agent holding tool access the risk is authorisation and blast radius.
| # · Cyber risk · OWASP / MITRE ATLAS / NIST AI RMF | Prevention · Detection · Configuration · Example tools |
|---|---|
1 Excessive agency — escalation by chaining legitimate tools OWASP LLM06 · AML.T0053 LLM Plugin Compromise NIST GOVERN 3.2 | Prevent · Tool allow-list with an explicit policy per tool Detect · Alert on an unexpected tool-call sequence Configure · Scoped, short-lived credentials; no ambient auth Example tools · Open Policy Agent · AWS Cedar · scoped MCP servers |
2 Goal drift and unbounded autonomous re-planning OWASP LLM06, LLM10 · AML.T0034 Cost Harvesting NIST MANAGE 4.1 | Prevent · Human approval gate on consequential actions Detect · Plan-depth and cycle-count monitoring Configure · Hard caps on steps, depth, time and spend Example tools · LangGraph recursion limits · LangSmith · Langfuse |
3 Memory poisoning persisting across sessions OWASP LLM08 · AML.T0070 RAG Poisoning NIST MEASURE 2.7 | Prevent · No memory writes originating from untrusted content Detect · Provenance-tag audit on every memory read Configure · TTL on long-term memory; signed writes only Example tools · Qdrant / Pinecone namespaces & ACLs · Redis ACL · Sigstore |
4 Uncontrolled sub-agent spawning OWASP LLM06, LLM10 · AML.T0029 Denial of ML Service NIST MANAGE 2.4 | Prevent · Spawning requires an explicit grant Detect · Live inventory of active agent identities Configure · Max concurrent sub-agents; one identity per agent Example tools · SPIFFE / SPIRE · Entra Workload ID · IAM Roles Anywhere |
5 Tool and API abuse — SSRF, code execution, egress OWASP LLM05 · AML.T0055 Unsecured Credentials NIST MEASURE 2.7 | Prevent · Sandboxed executor with a read-only filesystem Detect · Egress and syscall monitoring on the executor Configure · Network egress allow-list scoped per tool Example tools · gVisor · Firecracker · E2B |
6 Non-determinism defeating repeatable assurance OWASP LLM09 · AML.T0031 Erode ML Model Integrity NIST MEASURE 2.3 | Prevent · Schema-constrained outputs at the tool boundary Detect · Continuous eval harness with pass thresholds Configure · Signed action log attributing each step to a plan Example tools · Promptfoo · DeepEval · Ragas |
Responses · actions · tool results · human-in-loop · re-plan signal
The governance question is no longer whether a human was in the loop — it is whether anyone can demonstrate judgment was exercised.
| # · Cyber risk · OWASP / MITRE ATLAS / NIST AI RMF | Prevention · Detection · Configuration · Example tools |
|---|---|
1 Fabricated content reaching a customer, court or regulator OWASP LLM09 · AML.T0062 Discover LLM Hallucinations NIST MEASURE 2.3 | Prevent · Mandatory human review before external release Detect · Citation and fact verification step, logged Configure · Release gate keyed to a named reviewer Example tools · Ragas · TruLens · Galileo |
2 Sensitive data exfiltration through the response channel OWASP LLM02 · AML.T0057 LLM Data Leakage NIST MEASURE 2.10 | Prevent · Output redaction before the response leaves Detect · Egress DLP on the response channel Configure · Classification-driven egress rules Example tools · Purview DLP · Nightfall · MS Presidio |
3 Unauthorised or irreversible actions — writes, deletions, payments OWASP LLM06 · AML.T0053 LLM Plugin Compromise NIST MANAGE 2.4 | Prevent · Explicit approval required for irreversible operations Detect · Alert on any out-of-policy write attempt Configure · Dry-run by default; idempotency keys on writes Example tools · OPA / Cedar · ServiceNow approvals · Temporal compensations |
4 Insecure generated code promoted to production OWASP LLM05 · AML.T0011 User Execution NIST MEASURE 2.7 | Prevent · Peer review, the same as any other code Detect · SAST and SCA in the delivery pipeline Configure · Secure SDLC gate regardless of code origin Example tools · Semgrep · Snyk · GitHub CodeQL |
5 Feedback loop amplifying an error with no checkpoint OWASP LLM10 · AML.T0034 Cost Harvesting NIST MANAGE 4.1 | Prevent · Human checkpoint before the loop repeats Detect · Cycle-count and repeat-failure alerting Configure · Hard cap on autonomous cycles per task Example tools · LangGraph max iterations · Langfuse · AgentOps |
6 Attribution gap — no evidence that judgment was exercised OWASP LLM09 · no direct ATLAS technique — assurance gap NIST MEASURE 2.8 | Prevent · Reviewer identity captured against each artifact Detect · Periodic audit sampling of AI-assisted work Configure · Immutable per-transaction audit trail Example tools · Splunk · Microsoft Sentinel · CloudTrail Lake |
The trade-off is real. It is just not the one most organisations argue about.
The argument is usually framed as speed versus safety: engineering wants to ship, security wants to gate, and the outcome is a committee. That framing loses every time, because it makes security a tax on velocity rather than a precondition for it.
The real distinction is between controls you can evidence and controls you merely assert. An asserted control — a policy, a review board, a signed attestation — costs almost nothing to create and buys nothing durable, because every new use case reopens the same conversation. An evidenced control — a scoped credential, an action log, an eval that passes in CI — costs something once, then makes the second and third use case cheap.
Six practical positions that follow from that.
A read-only research agent and one that can move money are not the same risk. Gate on what the agent can do to the world, not on which vendor supplies the weights.
A non-deterministic system cannot be assured by a review board and a screenshot. Pass thresholds in CI let you ship weekly; a monthly committee does not.
Least privilege per tool, short-lived, one identity per agent. Draw the box tightly and the agent can explore freely inside it — that is where the speed comes from.
Dry-run, idempotency keys, compensating transactions. Reversibility is what buys autonomy: an action you can undo does not need a human standing over it.
An action log attributing each step to a plan and an identity is the artifact that lets you say yes to the next use case. Without it every expansion restarts the argument.
A 90-day bounded pilot with a kill switch and a named owner beats an 18-month governance programme that ships nothing and learns nothing.
The one to act on first: point 3. Scoping the credential rather than policing the conversation is what gives engineering room to move while keeping blast radius bounded. Every other control on this page gets easier once each agent and sub-agent holds its own short-lived, tightly scoped identity.
Start with the layer that carries your blast radius. For most organisations that is Layer 3 — action and execution privileges — not Layer 1, even though Layer 1 is where the attack enters. The reason is asymmetry: a prompt injection reaching an agent with read-only scope is an annoyance; the same injection reaching an agent with write access to a production system is an incident. Bound the privilege first, then work outward to the ingestion boundary and the output gate.
Two artifacts are worth building before anything else, because everything else depends on them. An inventory of what agents exist, what tools each can invoke and what data each can reach — you cannot assess a population you have not defined. And an action log attributing each step to a plan and an identity — without it you cannot scope an incident after the fact, and you cannot answer the question a client or regulator will eventually ask: how was AI used here, who reviewed it, and when?
Careful Adoption of Agentic AI Services — ASD’s ACSC, CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, 30 April 2026. The first coordinated Five Eyes guidance on agentic AI; source of the five risk categories and the system diagram. cisa.gov · full PDF
Cloud Security Alliance, AI Safety Initiative — research notes on the joint guidance and the 2026 agentic identity survey: 82% of organisations have found unknown AI agents in their environment, 65% had an agent security incident in the past twelve months, and 21% have a formal agent decommissioning process. labs.cloudsecurityalliance.org
OWASP Top 10 for LLM Applications — source of the OWASP identifiers on every risk row. The guidance also cites OWASP Top 10 for Agentic Applications (2026), worth reviewing alongside it.
MITRE ATLAS™ — Adversarial Threat Landscape for AI Systems; source of the AML.T identifiers, and named in the guidance as a recommended threat-modelling taxonomy.
NIST AI Risk Management Framework — source of the GOVERN / MAP / MEASURE / MANAGE subcategory references. Those mappings are our derivation, not an official crosswalk.
NIST SP 800-207 Zero Trust Architecture · CISA 2025 Minimum Elements for a Software Bill of Materials · CISA AI Cybersecurity Collaboration Playbook · NCSC-UK Guidelines for Secure AI System Development · MIT STAMP / STPA-Sec materials
Diagram redrawn from Figure 1 of the joint guidance. © Commonwealth of Australia 2026, licensed CC BY 4.0.