AI Agent Security: Nobody Authorized That Action, and That’s the Problem
The last two posts in this series ended in the same place from different directions. The one on AI-executable workflows argued that when the convertible tasks leave, what remains valuable is specification, oversight, evidence, boundary judgment, and the signature. The one on Bay Area startups argued that enterprise buyers now ask for those things before they sign.
Agents are where both arguments stop being abstract. A chatbot that gives a bad answer produces a bad answer. An agent that gets manipulated moves money, deletes records, emails your customer list, or opens a pull request. The failure mode changes from wrong output to unauthorized action — and unauthorized action is a category that security, compliance, and legal all have opinions about.
So the organizing question for this post is not “how do I make my agent safe.” It’s the one I keep landing on: when this agent takes an action, can you say who authorized it, what it was allowed to do, and prove it? Everything below is in service of being able to answer that.
Two sources worth reading in full alongside this: the OWASP AI Agent Security Cheat Sheet (CC BY-SA 4.0), which is the best free control catalogue for this problem, and Tigera’s AI Agent Security guide, which is stronger on the infrastructure and identity side. I’m synthesising both here with the governance layer they mostly leave implicit.
Why agents break the model you already have
Three structural shifts, and each one invalidates a control you probably rely on.
Data became instructions. Your input validation assumes data is inert (harmless). For an LLM it isn’t — a retrieved document, an email body, a webpage, a tool response, a Jira comment can all carry instructions the agent will follow. This is indirect prompt injection, and it means every data source your agent touches is now part of its instruction surface. Traditional sanitisation doesn’t help because there’s no syntax to strip; the payload is just words.
The actor is nondeterministic. Access control assumes a caller who does the same thing given the same permissions. An agent’s next action is a probabilistic function of its context, and its context is partly attacker-controllable. You cannot reason about what it will do; you can only bound what it can do.
Identity got separated from a human. Agents authenticate as service accounts, often with credentials broader than any human user, and frequently act on behalf of a user without carrying that user’s authorisation scope. That gap is the confused deputy problem: the agent has authority the requester doesn’t, and the requester can steer the agent. Tigera’s framing is the right one — treat each agent as a first-class managed identity with its own credentials, lifecycle, and decommissioning, rather than a process borrowing someone else’s.
A threat model you can hold in your head
OWASP enumerates thirteen risks and Tigera seven. Overlapping them, I find five clusters more useful for actually designing controls, plus one meta-risk:
| Cluster | What it covers | The control that matters most |
|---|---|---|
| Instruction integrity | Direct and indirect prompt injection, goal hijacking, malicious configuration fed through developer consoles | Trust boundaries between instructions and data; never let retrieved content carry authority (untrusted data) |
| Privilege and identity | Over-permissioning, tool abuse, privilege escalation through agent chains, credential theft, confused deputy | Default-deny tool scoping; per-agent cryptographic identity; short-lived scoped tokens |
| Memory and context | Memory poisoning that persists across sessions or users, sensitive data accumulating in context | Per-user memory isolation, TTL and size limits, integrity checks, redaction before persistence |
| Egress and exfiltration | Data leaked through tool calls and API requests, denial of wallet from unbounded loops | Egress allowlists, payload inspection, hard limits on tokens, cost, retries, and chain depth |
| Multi-agent propagation | One compromised agent escalating through others, cascading failure | Signed inter-agent messages with replay protection, trust levels, circuit breakers |
| Shadow agents (meta) | Agents nobody registered, running with unknown permissions | Discovery and a registry — you cannot control what isn’t inventoried |
Note how many of these are authorisation problems wearing AI clothing. That’s deliberate. The genuinely novel risks are instruction integrity and memory poisoning; the rest are old problems whose blast radius grew because the caller is now unpredictable and fast.
The control set, in priority order
1. Default-deny tool scoping
The single highest-leverage control. An agent with a general execute_command tool and wildcard permissions has, in effect, your entire environment as its attack surface. The alternative is narrow, purpose-built tools: read-only where possible, scoped to specific paths or resources, with explicit deny patterns for credential-shaped things (.env, .pem, anything matching secret patterns) and separate tool sets per trust level so a user-facing agent and an internal one never share a registry.
Practical test: for every tool your agent can call, can you state the worst thing that tool can do if the agent is fully adversarial? If the answer requires thinking, the tool is too broad.
2. Separate the decision from the execution
This is the best idea in the OWASP sheet and the one most implementations skip. An approval prompt in the agent’s own loop is not a control — the loop is the thing under attack.
The pattern: the agent proposes an action; an independent policy service validates scope, privilege, and approval state before anything executes. And critically, the approval is bound to the exact action — actor, tool name, target resource, normalised parameters, timestamp, expiry. An approval that says “yes, send the email” and not “yes, send this email to this recipient with this body” can be redirected between approval and execution.
Four details that make the difference between a real gate and a decorative one:
- Short-lived authorisation artifacts with replay protection for anything irreversible.
- Step-up authentication for critical actions — payment initiation, privilege changes, bulk deletion, production deployment, account recovery.
- Idempotency where possible; explicit duplicate confirmation where it isn’t.
- Fail closed. If risk classification, policy lookup, approval validation, or audit logging fails, the action does not proceed. A system that executes when logging is down produces exactly the actions you can’t account for.
Risk-tier your actions explicitly — reads and safe queries at the bottom, writes and API calls in the middle, external communication and code execution above that, irreversible and financial operations at the top — and set the auto-approval ceiling per tier rather than per agent. Anything not in the mapping should default to the highest tier, not the lowest.
3. Agents as first-class identities
Unique credentials per agent, issued through your existing IdP or SPIFFE/SPIRE rather than shared secrets. Long-lived API keys replaced by short-lived, tightly scoped, auto-rotated tokens — and in multi-agent flows, a fresh token minted per hop so authority doesn’t accumulate down the chain. Real lifecycle management: created, updated, and decommissioned deliberately, with dormant identities disabled automatically.
The governance payoff is attribution. When actions carry a verifiable agent identity, “who did this” has an answer, and that answer survives an auditor asking it six months later.
4. Memory and context hygiene
Validate before you persist, not after. Scope memory per user and per session so one tenant’s poisoned entry can’t surface in another’s context. Set TTLs and size caps. Redact credential and PII patterns before writing to memory rather than filtering on read. Add integrity checks so tampered entries fail verification instead of quietly steering a future session.
Memory poisoning is the risk most teams haven’t modelled, because it’s the only one where the attack lands in one session and detonates in another. That delay also makes it the hardest to attribute after the fact.
5. Egress control and cost bounds
Agents talk to external services, and that channel is the exfiltration path. Allowlist outbound endpoints, broker calls through a gateway you control so policy is enforced before the request leaves, inspect payloads for sensitive data, and rate-limit. Watch for the exfiltration signatures: unusual encoding in URLs, oversized payloads to webhook or HTTP tools, repeated calls to unfamiliar endpoints.
And set hard ceilings on tokens, cost, retries, and tool-chain depth. Denial of wallet is a real availability-and-budget risk, and unbounded recursion is how a bug becomes an incident with an invoice attached.
6. Adversarial testing as a release gate
Agents should be tested before production and re-tested after any material change — prompts, tools, memory, retrieval, policies, or model provider. Keep a repeatable abuse-case matrix: prompt override, tool misuse, privilege escalation, memory poisoning, data exfiltration, recursive tool abuse, approval bypass, multi-agent chaining. Each with a specific expected denial, version-controlled, running in CI.
One warning from the OWASP sheet deserves repeating verbatim in your review process, because it’s the kind of thing that only occurs to someone who has seen it: review test changes carefully, because an attacker may try to weaken or remove security tests in the same pull request that changes agent behaviour.
The part that turns controls into evidence
Everything above is security engineering. Here’s where it becomes governance — and where, in my experience, the gap between “we have controls” and “we can demonstrate control” gets exposed.
For every high-risk agent action, log structured decision metadata: action classification, risk score where applicable, authorisation outcome, approval identifier, execution result, and policy version. That last field is the one people forget, and it’s the one that lets you answer “what rules were inforce when this happened?” — which is the question that actually gets asked during an incident review.
Then monitor for drift in the oversight layer itself: repeated approval bypass attempts, elevated privilege usage, abnormal tool invocation frequency, sudden increases in high-risk actions, and changes in approval behaviour over time. An oversight mechanism degrades quietly — approvers start rubber-stamping, thresholds get relaxed for a deadline — and nothing alerts you unless you instrument for it.
For production agents, retain validation evidence: the tested agent version, model provider, tool policy and retrieval configuration; the abuse cases executed and their expected results; the approval, denial, timeout, and circuit-breaker behaviour observed; and any accepted residual risk with its compensating control. That last item is what separates a mature program from a hopeful one — mature programs have documented accepted risks, not zero risks.
Where this maps:
| Framework | Anchor |
|---|---|
| ISO/IEC 42001 | A.6 (AI system lifecycle), A.9.2 (responsible use), A.10.3 (supplier and value-chain responsibilities), Clause 9.2 (internal audit evidence) |
| NIST AI RMF 1.0 | MAP for context and tool inventory; MEASURE for adversarial testing; MANAGE for monitoring, response, and residual risk |
| EU AI Act | Art. 14 human oversight as demonstrated capability to intervene, interrupt, and disregard; Art. 26 deployer duties including staff competence, monitoring, incident notification, and log retention of at least six months |
| ISO/IEC 27001 | A.5.15 / A.8.2 for agent authorisation; A.8.16 monitoring; A.5.7 threat intelligence feeding the abuse-case matrix |
The overlap is the point. An agent action log built to answer who authorised this, what context did the system have, what did it decide, was that consistent with policy simultaneously serves your incident response, your ISO 42001 internal audit, and an Article 26 request. Build it once.
From the practitioner’s chair
DISC InfoSec audited a client’s MCP Governance Standard and produced a v1.1 redline with 27 changes. Worth being specific about what those changes were, because the distribution is instructive.
They covered OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections. But the pattern across most of them was the same single idea: authority must be bound to a specific action, not held ambiently by a component. A token that isn’t audience-validated is authority without a destination. A tool manifest without integrity checking is authority without a definition. A confused-deputy gap is authority without a requester. Almost every finding was a variation on authority floating free of the thing it was supposed to authorise.
If you take one design principle from this post, take that one. It generalises further than any specific control in the list above.
The other thing I’d say from the audit chair: the controls are rarely the hard part. When we led VDR through ISO 42001 Stage 2 certification, the difference between passing and a nonconformity was almost never whether a control existed — it was whether we could produce the artifact proving it operated. Agents make that harder, because the volume of actions is high and the actions are taken by something that can’t be interviewed. Design the evidence trail at the same time as the control, or you’ll be reconstructing it under deadline.
Worth a sober note on where the industry actually is: across recent 2026 surveys, roughly a fifth of organisations can automatically terminate a misbehaving agent’s access, and a substantial share of deployed agents run with no security oversight or logging at all. If your kill switch has never been tested end to end, you don’t have one — you have a plan to find out during an incident.
#AIagentsecurity #MCPsecurity #promptinjection #agentleastprivilege #ISO42001agents #EUAIActArticle14 #humanintheloop
Why AI Agents Need Persistent Browser Identities
Five sentences worth putting in a policy
- No agent gets a tool whose worst-case use we haven’t written down.
- Irreversible actions are validated and authorised by a service the agent does not control, against an approval bound to the exact action.
- Every agent has its own identity, its own short-lived credentials, and a decommissioning date.
- If classification, policy lookup, approval validation, or audit logging fails, the action does not execute.
- Any change to prompts, tools, memory, retrieval, policy, or model provider re-runs the adversarial test suite before release.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations deploy AI agents that survive both an attacker and an auditor: agent and tool inventories, MCP and tool-permission review, prompt injection and agent security assessment, human oversight design, and the evidence architecture that maps to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.
I led VDR through ISO 42001 Stage 2 certification on the first attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard. If you have agents in production and no clear answer to who authorised that action, that’s the assessment to run now.
DISC InfoSec — | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com
Sources and further reading
- OWASP AI Agent Security Cheat Sheet — licensed CC BY-SA 4.0; also the MCP Security, RAG Security, and LLM Prompt Injection Prevention cheat sheets
- OWASP Top 10 for Large Language Model Applications
- Tigera, AI Agent Security: Top 7 Risks and 4 Types of Security Solutions
- NIST AI Risk Management Framework 1.0 (NIST AI 100-1)
- ISO/IEC 42001:2023; ISO/IEC 27001:2022 Annex A
- Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
- Google Secure AI Framework (SAIF)
