How to Secure AI Agents in Production: A CISO Playbook

Answer box

To secure AI agents in production, you control four things: what the agent reads (prompts), what it executes (tool calls), what it passes to other agents (A2A handoffs), and what it remembers (memory). Everything else — model, framework, vendor — is downstream of those four surfaces. This AI agent security playbook walks the operational steps at the implementation level: which middleware to deploy, what latency budget to hold, which tokens to issue, what to log, how to drill. Not principles. The actual sequence of work a CISO does to take an agent into production without owning the next breach.

What "in production" actually means for agents

Confirm the agent is actually in production. The threshold is not "deployed to a cluster" or "passed staging." An agent is in production when at least one is true: it touches real customer data, it takes real actions (sending email, executing trades, modifying a CRM, calling an API that costs money), it runs on a billed account, or it feeds a downstream system that humans or other agents act on.

If any one is true, this playbook applies. If none are true — sandboxed, synthetic data, no external calls — you're in development. The repeated mistake is teams treating "internal pilot" as not-production while the pilot reads the production customer database. The moment real data flows in or real actions flow out, you are in production whether your change ticket says so or not.

The four control surfaces every production agent needs

The entire defensive posture for an agent reduces to four surfaces. Most security failures we see in 2026 incident reviews — including the patterns documented in the OWASP Top 10 for Agentic Applications — are failures at one of these four boundaries.

Prompt → response surface

Inline inspection runs on the hot path. Sidecar logging is not enough — by the time the sidecar sees a malicious prompt, the model has responded and the tool call has fired. Hold a p99 budget of 50ms. Above that, engineering routes around your control to hit SLA, and you find out from a postmortem.

Tool call surface

Allowlisting belongs in code, not a Confluence page. Capability-scoped tokens — one tool, one user, 60 seconds — are the only credential model that survives contact with a compromised agent. Long-lived service-account tokens shared across agents are the most common finding in production AI security reviews. See why "non-human identity" is the wrong frame.

A2A handoff surface

When agent A passes a task to agent B, the message is now an input to B and must be treated as untrusted. Signing solves "who sent this." Inspection solves "what's in it." Both at the bus, not endpoints — endpoints get bypassed. See the A2A trust model.

Memory surface

Memory is the slow-burn surface. A poisoned chunk written today becomes a malicious instruction retrieved six weeks from now, after every log has rolled off. Provenance signing on writes plus inspection on reads is non-negotiable. Off-boarding hygiene matters because retained memory of a former customer is both a privacy violation and an attack surface.

The 12-step deployment checklist

Work through these in order. Don't skip ahead. The numbering reflects dependency order — step 6 doesn't work without step 4, step 8 doesn't work without step 7.

1. Assign an agent owner. A named human, not a team or a Slack channel. When the agent does something wrong at 2 AM, paging "the platform team" is how incidents stretch from minutes to hours.
2. Build the AIBOM for this agent. Enumerate every tool, MCP server, prompt template, training dataset, and external dependency. Without an AIBOM you cannot answer "what changed" after an incident — see the MCP field guide for the inventory pattern.
3. Classify the risk tier. Use EU AI Act Annex III categories if you operate in the EU, or your organization's internal taxonomy. The classification determines how strict the rest of the steps need to be — a high-risk system per Article 9 needs documented risk management; an internal productivity agent does not.
4. Issue per-agent workload identity. Each agent gets its own identity, not a shared service account. SPIFFE/SPIRE works; cloud-native workload identity works; what doesn't work is "the prod-agents service account."
5. Scope tokens to single tool calls. The token issued to call send_email can call send_email and nothing else, and it expires in 60 seconds. No exceptions for "convenience during dev" — convenience tokens leak into prod.
6. Deploy inline inspection at the prompt boundary. Sub-50ms p99. Block-on-detect for high-confidence injections, log-and-allow for medium-confidence. Tune the thresholds during the 30-day burn-in, not before.
7. Allowlist tools at the runtime. The agent SDK enforces the allowlist; a policy document does not. If the runtime allows it, it will happen — assume the prompt will eventually instruct it.
8. Sign A2A messages at the bus. Every inter-agent message carries a signed claim of origin and is inspected by middleware on the bus before delivery to the receiving agent.
9. Implement a per-agent kill switch and drill it monthly. Not a config file flag — a runtime control that severs the agent's identity and its tool tokens in under one second. See the 9-second database delete incident for why this matters.
10. Configure provenance logging. The audit standard is single-search reconstruction: an investigator with one query should be able to pull every prompt, tool call, A2A handoff, and memory write for a given session within 90 seconds.
11. Tag agent traffic in the SIEM. Agent calls look like normal API traffic until they don't. Tag them at the gateway so your SOC can filter, baseline, and alert on agent-specific patterns.
12. Document the IR runbook for THIS agent specifically. Generic AI incident runbooks fail because they assume generic agents. Yours has specific tools, specific data, specific downstream consumers. Write those down. Test it with the tabletop kit before you need it.

What goes wrong in week 1 of production

Across the production rollouts we've observed, failures cluster into five patterns. The Unit 42 2026 IR report shows the same cluster from the IR side. None are exotic — all are consequences of shortcutting one of the 12 steps.

Inspection latency drift. Middleware starts at 30ms p99 in load test and climbs to 200ms p99 under real traffic with cache misses and larger prompts. Engineering routes around it to hit SLA. Fix: budget 50ms from day one, alarm at 60ms, treat inspection latency as P1, not an SRE concern.

Tool descriptor version mismatch. The agent's tool definitions in code don't match what the MCP server actually exposes. A new version adds a parameter, or changes the semantics of an existing one. The agent calls the new behavior thinking it's the old. This is the supply-chain pattern in tool poisoning. Pin versions, verify hashes, alert on drift.

Token scope creep. Tokens started narrow. A bug appeared where the agent needed two tool calls and the second token expired mid-flight. Someone widened the scope "temporarily." Six weeks later, tokens call eight tools for an hour. Fix the bug; don't widen the token.

Memory accumulation without provenance. The vector store grows. Nobody signs writes. Six weeks in, no one can answer "where did this chunk come from." When poisoning hits, you can't isolate blast radius. Slowest-burn failure, hardest to fix retroactively.

Kill switch that doesn't kill. The switch is a config flag. To activate, someone edits, commits, waits for the deploy pipeline. Mean time to kill: 14 minutes. The benchmark is under one second. Config-file kill switches don't work under speed. The switch must revoke workload identity and outstanding tokens at runtime, from a single API call, no deploy.

The 30/60/90 maturity ramp

Days 0–30: deploy, monitor, tune. Do not add features. Do not expand the tool set. Do not enable new memory backends. The only job for 30 days is confirming the 12 steps work in real traffic. Watch the five metrics below. Tune inspection thresholds based on false-positive and false-negative rates. Resist product's pressure to "just add one more thing" — every addition resets the burn-in clock.

Days 30–60: first incident drill. Run a tabletop with a realistic scenario: a prompt injection that escalates through tool calls, or a poisoned A2A handoff from a compromised upstream agent. Pull in SOC, the agent owner, legal, and one engineering lead. Find gaps — missing runbook section, alert that didn't fire, kill switch that took 4 seconds. Fix before day 60. This maps to NIST AI RMF MANAGE and ISO 42001 §A.8.24.

Days 60–90: external review. Bring in an auditor or red team that did not build the system. Internal reviewers can't see assumptions they baked in. External review produces findings — accept that and budget remediation time. By day 90 the agent has been observed, drilled, and externally reviewed. That's a defensible posture and what a board or regulator expects to see documented.

The five metrics worth tracking

• Mean time to kill (MTTK). Time from kill-switch trigger to the agent's last tool call being denied. Target: under 1 second. Anything slower means the kill switch is theoretical, not operational.
• Inline inspection p99 latency. Target: under 50ms. Tracks the cost of your control. When this drifts, engineering will route around the control before they tell you.
• Tool-call denials per day. Signals policy fidelity. Zero denials means your allowlist is too loose or your traffic is too low; sudden spikes mean either a compromised agent or a legitimate workflow change. Baseline it during burn-in.
• Provenance trail completeness. Percent of sessions for which every prompt, tool call, handoff, and memory write is reconstructable from logs alone. Target: 100%. Audit-ready means no gaps, not "mostly complete."
• Agent identity scope. Active tokens multiplied by their maximum scope time. The trend should be flat or declining. When it rises, token scope creep is happening; investigate which agent and why.

FAQ

How is this different from securing a regular microservice? A service has deterministic inputs and outputs. An agent has a prompt that rewrites its own behavior at runtime, tools it chooses via natural-language reasoning, and memory that accumulates. The four surfaces have no direct analogs in service security. You need new controls, not adapted ones.

Is this overkill for low-risk agents? No. Small agents get a small version — same surfaces, depth calibrated to risk tier. A summarization agent with read-only Confluence access still needs an owner, AIBOM, scoped tokens, and a kill switch. It does not need a 30/60/90 with external red team. Calibrate, don't skip.

How does this map to existing IR? Your existing IR handles detection, triage, containment, eradication, recovery. The agent-specific layer sits inside containment: how to kill an agent, isolate its memory, verify it stopped. Add a per-agent runbook called from the master IR process.

Can we use existing identity infrastructure? Partially. Your IAM handles human and workload identities. It almost certainly doesn't handle per-tool-call scoping with 60-second lifetimes at agent call volumes. You need either an IAM extension or a dedicated agent-identity layer issuing capability tokens on demand.

Do we need a new SOC capability? Yes. Your SOC needs an AI-specific playbook: recognizing prompt-injection patterns in logs, distinguishing a compromised agent from a buggy one, triaging an A2A cascade. Train two analysts initially. Generic SOC training does not transfer.

Most common reason agents fail security review in production? Token scope. Specifically, a long-lived service-account token shared across agents and tools. Easiest thing to ship with, hardest to take back once running. Fix one thing before going live: per-agent workload identity with capability-scoped tokens per call.