How to make your AI agent safer.

The seven practices

What the research actually recommends

These practices are derived from the frameworks and the incident data above. They are not comprehensive security engineering. They are the minimum a business should have in place before granting an agent autonomous action authority.

1. 1

   Narrow the scope.

   Agents should have access only to the tools, data, and permissions they need to complete their defined task. Scope creep — granting broader access “just in case” — is the single most common finding in post-incident analyses. The CSA / Zenity study (April 2026) found that only 8% of organizations have agents that never exceed their intended permissions. The other 92% are operating with agents that have more authority than they need.

   In practice: define a capability list before deployment, not after. List every tool the agent can invoke and every data store it can read or write. Require a written justification for each. Agents that can create and task other agents (25.5% of deployed agents, per VentureBeat 2026) require additional scope analysis because inherited permissions multiply across agent hops.

   The OWASP LLM Top 10 names Excessive Agency (LLM06) as one of ten ranked risks. The NIST AI RMF “Manage” function requires ongoing scope review. ISO 42001 requires impact assessments that include scope definition.

   Next step: Audit one agent you have in production. List every permission it holds. Remove any that are not required for its defined task. Document what was removed and why.

   Frameworks: OWASP LLM Top 10 — LLM06 Excessive Agency; OWASP Agentic AI — ASI03 Identity and Privilege Abuse; NIST AI RMF Map/Manage

2. 2

   Authenticate the agent and the human.

   45.6% of enterprises still use shared API keys for AI agents instead of individual identities (VentureBeat / Gravitee, 2026). A shared API key provides no audit trail, no revocation granularity, and no way to distinguish between legitimate agent activity and attacker use of the same credential.

   The minimum viable authentication architecture for a production agent: OAuth 2.1 with PKCE (not implicit grant, not static key), short-lived access tokens (15–60 minutes), rotating refresh tokens, and RFC 8693 Token Exchange for any operation the agent performs on behalf of a human. RFC 8693 allows audit logs to record “Procurement Agent acting for Jane Smith approved PO #44821” rather than “Jane Smith approved PO #44821” — a distinction that is material in any incident investigation.

   The MCP authorization specification requires OAuth 2.1 with PKCE for all remote MCP server connections. Resource Indicators (RFC 8707) are required to prevent token mis-redemption. Hardware-backed key storage (AWS Secrets Manager, HashiCorp Vault) is the current best practice for high-value agent identities.

   Next step: Identify every agent in production that uses a shared API key. Replace each with an OAuth 2.1 flow. This single change closes more exposure than anything else on the list.

   Frameworks: MCP Auth Spec (OAuth 2.1 + PKCE); IETF RFC 9635 GNAP; OWASP Agentic AI — ASI03; SOC 2 2026 AI requirements

3. 3

   Spending caps and second-pair-of-eyes thresholds.

   The manufacturing procurement fraud case involved $5 million in fraudulent orders placed over 10 transactions — each individually under a threshold the agent had been manipulated into believing was its autonomous authority. Stripe Issuing applies a default $500/day cap and an unconfigurable $10,000 per-authorization ceiling. Most enterprise agents have no equivalent.

   Every agent with spend authority should have: a per-transaction limit, a daily/weekly rolling budget, a merchant/vendor allowlist, and a human-in-the-loop confirmation requirement for transactions above a threshold. The threshold should be set before deployment, not after the first incident. FINRA’s 2026 Oversight Report explicitly names human-in-the-loop oversight as required for financial AI agents executing transactions. The EU AI Act’s human oversight obligations apply to high-risk systems from August 2026.

   For agents that do not handle financial transactions, the same logic applies to any irreversible action: email sends, database writes, external API calls, file deletions. Reversible actions require lower confirmation thresholds than irreversible ones. The MCP specification requires “explicit user consent UI for destructive or irreversible actions.”

   Next step: Define the transaction limit for every spend-capable agent. Write it down. If it is not written down, the agent’s effective limit is whatever an attacker can manipulate it into believing.

   Frameworks: EU AI Act Article 16 — Human Oversight; FINRA 2026 Oversight; Stripe Issuing Spending Controls

4. 4

   Treat every input as untrusted.

   OWASP has ranked prompt injection the number-one LLM application risk for three consecutive years. A joint study by researchers across OpenAI, Anthropic, and Google DeepMind found that under adaptive attack conditions, every published defense was bypassed with success rates above 90%. A single prompt injection attempt against a GUI-based agent without safeguards succeeds 17.8% of the time on the first attempt and 78.6% by the 200th attempt, per Anthropic’s system card for Claude Opus 4.6.

   The fundamental problem is structural: in LLM systems, control and data planes occupy the same prompt. NVIDIA’s Rich Harang identified this as the core issue — the solution is not better prompt instructions but architectural separation of trusted from untrusted inputs. Simon Willison’s “Lethal Trifecta” describes when exploitation becomes nearly certain: an agent with access to private data, ability to exfiltrate via network or email, and strong instruction-following.

   Two defenses with strong empirical backing: Microsoft Research’s Spotlighting reduces indirect injection success rates from above 50% to below 2% on summarization tasks by wrapping untrusted content in session-token-keyed delimiters. Google DeepMind’s CaMeL (March 2025) neutralized 67% of attacks on the AgentDojo benchmark — the highest published rate — by enforcing capability-based policies on data flows between a Privileged LLM and a Quarantined LLM. Prompt-level instructions (“never follow instructions from documents”) do not work at the margins against sophisticated attacks.

   Next step: Identify every external source of content your agent processes (emails, PDFs, web pages, RAG documents, API responses). For each, document whether untrusted content is architecturally separated from privileged tool-call authority. If it is not, that is a prompt injection exposure.

   Frameworks: OWASP LLM01 Prompt Injection; Google DeepMind CaMeL paper; NVIDIA AI Red Team guidance; TokenMix 2026 defense comparison

5. 5

   Sandbox actions before production.

   Agents that interact with production systems — placing orders, sending emails, modifying records — should run in an isolated sandbox environment before those actions are committed. A dry-run mode that simulates the full action chain and returns a diff for human review before execution is the minimum viable pattern.

   Container isolation per agent run (Docker or Firecracker VMs) with default-deny egress is the current production best practice. Block the cloud metadata endpoint at the network layer (not just in code). Read-only root filesystem except for the explicit working directory. Per-tenant isolation for multi-tenant deployments. Anthropic’s Claude Code sandboxing (October 2025) uses isolated containers with filesystem and network controls, automatically allowing safe operations and blocking dangerous ones.

   Open Policy Agent and Amazon’s Cedar enable declarative policy-as-code for agent action authorization. These evaluate proposed actions against pre-defined policies before execution. Rate limits and circuit breakers prevent runaway costs and attack-induced resource exhaustion.

   Next step: Implement a dry-run mode for the highest-consequence actions your agent can take. Require a human sign-off on the dry-run output before the action is committed. Start with financial transactions and external communications.

   Frameworks: OWASP LLM06 Excessive Agency; Anthropic Claude Code Sandboxing; EU AI Act — Testing Obligations

6. 6

   Log everything. Make logs auditable.

   Only 28% of organizations can trace agent actions to a specific human across all environments (CSA, 2026). SOC 2 auditors now require: who accessed the AI system, what inputs were provided, what outputs were generated, tool invocations with full parameters, data sources accessed, authentication and authorization events, and any errors or failures. The 2026 Trust Services Criteria require tamper-evident logging with real-time integrity verification. Cryptographically signed audit logs are the expected standard, not a nice-to-have.

   OpenTelemetry GenAI semantic conventions provide standardized attribute names for agent monitoring: agent.tool.name, agent.tool.arguments, agent.decision, gen_ai.usage.input_tokens. W3C Trace Context propagation maintains trace continuity across multi-agent workflows. Without this, a compromise that crosses two agents produces two separate, unlinked log trails, neither of which tells the full story.

   Canary tokens — unique strings planted in the agent’s context with no legitimate reason to appear in output — provide a reliable exfiltration detection mechanism. If a canary appears in an outbound call, exfiltration is proven even when the attack was novel.

   Next step: Verify that your agent’s logs include the full parameters of every tool call, not just the tool name. If you cannot reconstruct exactly what the agent did on any given day from your logs, your logging is not adequate for SOC 2 or EU AI Act requirements.

   Frameworks: SOC 2 2026 AI compliance; SOC 2 for AI agents (PolicyLayer); EU AI Act Article 16 — Logging Obligations

7. 7

   Publish what the agent can and can’t do.

   Very few businesses publish any disclosure about their deployed agents as of April 2026. Enterprise security questionnaires are changing that: RFPs now routinely require “documentation about how your AI system works and how you tested it.” (Promptfoo AI regulation analysis, 2025). FINRA requires member firms to apply the same compliance standards to AI as to any other technology. EU AI Act conformity assessment requirements apply from August 2026.

   The minimum viable disclosure for a B2B agent: agent identity and version, what tools it can invoke and what data it can access, the authorization model (OAuth scopes, token lifetime), spending limits if applicable, when human approval is required, and an incident disclosure channel. IBM’s Granite models publish machine-readable AI Bills of Materials (AIBOMs) covering models, datasets, code, hardware, data processing, and governance — the current state of the art in transparency.

   Transparency does not require disclosing how your defenses work (which would assist attackers). It requires disclosing that they exist, what they cover, and what the incident response channel is. Anthropic has published system prompts for all Claude.ai interfaces since August 2024. xAI published Grok’s system prompts on GitHub after a May 2025 incident. OpenAI, Google DeepMind, and Meta have not published equivalent disclosures as of April 2026.

   Next step: Write a one-page disclosure document for your most widely deployed agent. Include: agent name, version, what it can do, what it cannot do, what its authorization model is, and who to contact if something goes wrong. Publish it at a stable URL.

   Frameworks: NTIA AI System Disclosures; OWASP AIBOM Generator; IBM Granite AIBOM; EU AI Act Transparency Obligations