AI agent security needs layers, not a single lock

Secure AI agents in layers. Input validation, model constraints, and deterministic enforcement at the system level, all running together. No single control stops a determined attacker. Stack three or four and most attacks fail somewhere along the chain.

Two references matter more than the rest. The OASB-1 specification sets out 46 controls across 10 domains, at three maturity levels. The OWASP AI Agent Security Cheat Sheet turns those into practical steps. Start there.

Before anything else, do three things:

• Scope every tool tightly. Give an agent the narrowest permissions that still let it do the job.
• Run risky work in a sandbox. Treat any tool call touching files, money or external systems as dangerous until proven otherwise.
• Check every expansion. If an agent asks for more access than it started with, a person or a policy engine reviews it. Every time.

Get those three right and you have the skeleton. The rest of this fills in the muscle.

Key risks and attack patterns: what to test first

Think of an AI agent as a new hire with a company laptop and nobody looking over their shoulder. The risk sits in what they can do, not what they say. Here is where attackers go first.

1. Prompt injection. Direct injection is someone typing a malicious instruction into the chat. Indirect is worse: the instruction hides inside a webpage, a PDF or an email the agent reads later. The agent then follows orders from content it should never have trusted. That is the root of most confused-deputy cases, where an agent uses its own legitimate permissions to do something it was tricked into.

2. Tool abuse and privilege escalation. An agent handed "full database access" instead of "read customer name and email" is a loaded gun. Attackers do not need to break the model. They need the one tool call nobody locked down.

3. Memory poisoning. Agents with long-term memory can be fed false facts across sessions. Bad data sits quietly, then shapes a harmful decision weeks later. Stale memory is just as dangerous. An old permission or an expired instruction lingers long past its use.

4. Data exfiltration, supply chain and Denial of Wallet. A poisoned plugin or connector leaks data straight out. Separately, an agent stuck in a loop calling an expensive API racks up a huge bill with no attacker involved at all. That is Denial of Wallet. Nothing stolen, just money burned.

5. Multi-agent cascades. When agents delegate to other agents, one bad decision ripples through the chain, and working out which agent caused it gets genuinely hard. Perplexity and Purdue's NIST response on agent security puts it plainly: confidentiality, integrity and availability violations can arise even with no malicious adversary present. Architecture and operational drift are enough.

The AI agent security stack: input, model and system layers

Defence in depth means three checkpoints, like airport security. Bag scan, body scan, boarding pass. Miss one and the next still catches you.

Layer one: input level

Treat every piece of external content as untrusted. Web pages, uploaded files, emails, API responses, anything your own team did not write. Devwiz covers the groundwork for this in AI data security basics.

• Sanitise content before the agent sees it.
• Strip or flag instructions embedded in retrieved documents.
• Validate structure and length before ingestion, not after.

Layer two: model level

Stop trusting free-flowing natural language for anything risky. Make the agent state its intent in a structured, checkable form before it acts.

• Require structured outputs, JSON schemas rather than prose, for any action with real-world consequences.
• Make the agent produce a formal intent statement, what it wants to do and why, before the tool call fires.
• Use constrained schemas so the agent cannot produce a request outside the shape you expect.
• Build an instruction hierarchy so system rules always outrank anything found in a document or a user message.

The principle underneath all four: the model proposes, and something else decides. A plan the agent describes in prose cannot be checked. A plan expressed as a constrained schema can.

Layer three: deterministic system level

This is the last line, and the one that holds when the first two fail.

• Tool allowlists. The agent can only call tools on an explicit list. Nothing else exists as far as it is concerned.
• Per-call policy checks. Every tool call gets checked, not just the first in a session.
• Tighten-only permissions. Policy can narrow an agent's access automatically at any time. Widening always needs a human sign-off. It is the least-privilege principle from OASB-1 turned into a one-way ratchet.

A workable expansion flow looks like this. The agent requests a new permission. The system logs the request with context. A named approver reviews it against written policy. The approval carries an expiry date. The change is logged with a timestamp and the approver's ID. No permission ever grows silently.

Pro Tip: Do not bolt deterministic checks on at the end. Write the allowlist before you write the first prompt. Shrinking an agent's powers later is far harder than granting them properly on day one.

Sandboxing, isolation runtimes and warm pools

Think of the sandbox as a hotel kitchen for a guest chef you have never met. Let them cook. Lock the walk-in freezer. Do not hand over a key to the front door.

Split the control plane from the compute. The runner that holds your secrets, approval state and decision logic should never sit inside the same box as the sandbox running the agent's code. If the sandbox is compromised, the attacker gets nothing worth having.

Pick your isolation level deliberately. Google's zero-trust stack recommends gVisor for kernel-level isolation with mediated system calls, cryptographic signatures on any state change, and deterministic gateways checking every input and tool output. Kata Containers or full virtual machines isolate harder and cost more latency. Choose on how much you trust the workload, not on habit.

Use warm pools for interactive agents. Cold-starting a sandbox per session adds delay and invites Denial of Wallet when agents retry. Pre-warmed pools provision an isolated environment in under one second, which matters when a human is sitting there waiting.

Sandbox the whole agent loop, not just the model call. NVIDIA's guidance is blunt about it. Helper scripts and hooks running outside the sandbox are part of the threat surface too. Deny writes outside the workspace, inject secrets at runtime instead of holding them in memory, and clean up sensitive artefacts rather than leaving them lying around.

Record signed provenance for high-risk actions. Every irreversible or sensitive action should leave a tamper-evident trail: what happened, when, and under whose authority. That is your evidence when something goes wrong.

Operational controls: human checks without the fatigue

A human approving every action is a manager signing off every email their team sends. Nobody reads carefully after the tenth one. They just click yes.

Default to deterministic enforcement. Save human approval for what genuinely deserves a person: permission expansions, irreversible actions, anything touching money or customer data.

• Bind every approval to explicit parameters, an expiry time and a named approver, so nobody replays an old approval against a riskier action.
• Run sampled manual audits instead of checking everything. NVIDIA's guidance makes the same point: sampling avoids habituation while still catching drift.
• Alert on abnormal approval rates. A spike in requests for the same permission usually means something is wrong upstream, not that the agent got busier.
• Keep rollback and forensic hooks switched on. Logs remember. People do not.

Getting the balance right is its own design problem, and we cover where approval steps actually earn their place in human-in-the-loop AI.

Adversarial testing and assurance checklist

Testing an agent once before launch is tasting a soup once, then letting it simmer for six months. Things change. Test again.

1. Prompt override attempts. Can external content hijack the agent's instructions?
2. Tool misuse. Does the agent call tools outside its purpose?
3. Privilege escalation. Can it talk its way into more access?
4. Memory poisoning. Does false information injected over time change behaviour?
5. Recursive tool abuse. Does a loop drain the budget?
6. Approval bypass. Can a request be reworded to dodge the policy check?

Run automated suites, including OASB checks and fuzzers built for your own tools. Then run periodic human red teams. Automated tools catch the obvious. People catch the clever.

Metric	What it tells you
Attack success rate	How often a test attack achieves its goal against your controls.
Benign-task degradation	How much your security layer slows down or breaks normal work.
Test frequency	How often you rerun the full suite after any change to prompts, tools or connectors.
Escalation false positives	How often the system flags a normal expansion request as suspicious.

Watch those first two together. Any control can drive attack success to zero by making the agent useless. The operating point you want is fewer successful attacks with benign work still running clean. That usually means keeping execution decisions separate from any reasoning about risk.

Retest after any change to the prompt, the tools, the model provider, memory or connectors. Not just at launch. Every time.

Mapping OASB, NIST and OWASP to daily practice

Governance sounds dull until an auditor asks for evidence you do not have.

• Use OASB-1's 10 domains as your control checklist and map each to a NIST CSF function: identify, protect, detect, respond, recover. Auditors already recognise that structure.
• Make tighten-only permissions written policy, with every widening request documented and reviewed.
• Log what actually proves compliance: policy version history, approval records with named approvers, signed provenance bundles, full audit trails. Not summaries.
• Write agent-specific playbooks into your incident response plan. A compromised agent behaves nothing like a compromised server, and your responders need to know that beforehand, not during.

Most businesses have a bigger problem than agent policy, and it is that staff are already running AI tools nobody approved. Njin's piece on shadow AI covers what that looks like from the inside.

How we put these controls into practice

Most of this is not theory. It is what shows up once you build agent systems for real businesses.

We run one method: Explore, Map, Transform. Explore finds where the founder's judgment sits. Map turns it into a written architecture: roles, decision rules, handoffs, and the authority each AI employee gets. Transform builds it with Claude Code into an AI Operating System that runs real work.

Security lives in the Map step, which is the part most teams skip. Every AI employee gets its tool list written down before a single prompt exists, along with what it may do alone and what it must escalate. That is the allowlist and the approval gate, decided as architecture rather than patched in after an incident. Building it with Claude Code is what makes that reachable for a founder with no security team.

Two things worth reading before you build anything. Start with do you actually need an AI agent. The safest agent is the one you never deployed. Then read what a real account compromise looks like. The lesson there was never about the model.

Want a gap list for your own agent fleet? Take the assessment and see where your controls stand.

James Killick's take: stop chasing features, start chasing failure modes

Most agent security advice reads like a vendor brochure. New model, new guardrail feature, new dashboard. None of it matters if your tool bindings are wide open.

Deterministic enforcement first. Everything else second. Permissions never creep upward without someone signing off. That one habit stops more incidents than any amount of prompt engineering.

The conventional advice says make the model smarter about security. Wrong priority. Models will keep getting fooled by clever text. Your job is not to make the model unfoolable. It is to make sure fooling the model does not matter, because the sandbox, the allowlist and the approval gate catch it anyway.

If you are building agent systems for a real business, do not bolt security on at the end. Put the runner boundary, the sandbox and the testing cadence into the architecture from day one. That is the difference between a system that survives contact with the real world and one that gets a very public write-up.

James Killick

Key Takeaways

Effective AI agent security combines deterministic enforcement, sandboxed execution and disciplined testing, with human approval reserved for genuine expansions or irreversible actions.

Point	Details
Defence-in-depth wins	Layer input validation, model constraints and deterministic checks so no single failure is fatal.
Deterministic enforcement is the backstop	Tool allowlists and tighten-only permissions stop silent privilege escalation even when the model gets fooled.
Sandbox the whole loop	Isolate compute from the control plane and protect helper scripts, not just the main model call.
Test after every change	Rerun adversarial tests whenever prompts, tools, model providers or connectors change.
Avoid approval fatigue	Bind approvals to explicit parameters and expiry, and rely on sampled audits, not blanket sign off.

Sources

• OASB-1 specification | Open Agent Security Benchmark
• AI Agent Security Cheat Sheet, OWASP
• Security considerations for AI agents (Perplexity and Purdue, NIST response)
• Build zero-trust AI agents with Google's agent development kit
• Practical security guidance for sandboxing agentic workflows | NVIDIA
• Agent Sandbox on GKE (Google Cloud docs)