Zero-Trust Agent Deployment

This skill gives you Anthropic's zero-trust operating procedure for deploying autonomous agents in an enterprise, distilled from the official eBook (May 2026). It covers the threat model specific to agents (prompt injection, tool poisoning, identity/privilege abuse, memory poisoning, supply chain), a three-tier control framework (Foundation / Enterprise / Advanced), an eight-phase implementation workflow, and rules for running security operations at the speed of AI-accelerated attackers. Core premise: trust nothing, verify everything, assume breach has already occurred — and remember that attackers running agents bring effectively unlimited patience at near-zero cost per attempt, so friction-only controls no longer count as security.

When to use

Use this skill when you are:

• Designing or deploying an agent that has tool access (APIs, databases, filesystems, MCP servers), memory persistence, or multi-agent delegation.
• Reviewing or auditing an existing agent deployment, its permissions, credentials, or MCP configuration.
• Writing IAM policy, sandbox config, tool allowlists, or escalation/approval rules for agents.
• Building agent-adjacent security operations: alert triage, SOAR playbooks, incident response for agent compromise.
• Answering compliance questions for agents in regulated sectors (HIPAA, FINRA, GDPR, FedRAMP, EU AI Act all impose aligned requirements; US federal agencies must adopt Zero Trust by 2027).

Do NOT use for: general web-app security unrelated to agents, model training safety, or as legal/compliance assurance — the source explicitly offers a framework for evaluation, not certification of any particular environment.

Rules

1. Apply the design test to every control: "does this make the attack impossible, or just tedious?" (eBook, Anthropic). Friction-only mitigations — extra pivot hops, rate limits, non-standard ports, SMS-based MFA — degrade against adversaries that grind through tedious steps at scale. Prefer controls that remove a capability over controls that throttle it: hardware-bound credentials, expiring tokens, cryptographic identity, network paths that do not exist.
2. Pick a tier and build up, never sideways. Foundation = minimum viable, adequate mainly for small businesses and teams; its floor has been raised — friction-only controls no longer qualify at any tier. Enterprise = target for any organization at significant scale. Advanced = baseline for regulated industries, national security, or severe-consequence deployments. Each tier strengthens (not replaces) the one below; expect today's Advanced to become tomorrow's Enterprise.
3. Give every agent instance a unique, cryptographically rooted identity. Labels are not identity. Foundation: persistent crypto-backed agent IDs in all logs and access requests, tracked creation-to-retirement. Enterprise: X.509 certificates per agent with rotation and revocation. Advanced: credentials in HSMs/TPMs, remote attestation before access, confidential-computing enclaves. Without distinct identity you cannot attribute actions, enforce least agency, or investigate incidents.
4. Never use static API keys or shared service-account passwords — they are not legitimate even at Foundation. They are the first thing model-assisted code analysis finds; treat any embedded credential as already compromised. Baseline: short-lived tokens from an identity provider (OAuth 2.0 or similar), expiration measured in minutes, automatic refresh, never embedded in code or config. Enterprise: mutual TLS with certificate pinning. Advanced: hardware-bound credentials with attested issuance, including service-to-service calls. For human auth in the loop, default to phishing-resistant FIDO2/passkeys; SMS codes do not meet the Foundation bar.
5. Enforce least agency (OWASP's extension of least privilege): restrict what each agent tool can do, how often, and where. Give a database tool read-only queries, deny an email-summarizing agent any send or delete rights, and grant an API integration only the minimal CRUD operations it needs. Foundation: RBAC with deny-by-default. Enterprise: ABAC using time, location, data sensitivity, and risk score (e.g., restrict an agent to operating hours). Advanced: continuous authorization re-evaluated at each action, revoking access the moment risk indicators change.
6. Scope privileges in time, not just in breadth. Static permissions granted at deployment create persistent exposure. Progress from static least-privilege roles → dynamic elevation only for the task, returning to baseline after → Just-In-Time/Just-Enough-Administration with automatic expiration, so an attacker who lands on agent infrastructure finds no cached credentials to steal. Token lifetimes in minutes, not hours or days.
7. Isolate by identity first; use network segmentation only as a backstop. Enforce at the receiving end: every workload carries its own cryptographic identity and each service accepts connections only from explicitly named callers. Sandboxed execution (containers with restricted capabilities, syscall filtering via runtimes like gVisor, limited mounts and network) is table stakes — mandatory, not aspirational — for any agent processing web content, documents, or other untrusted input. Advanced: hardware isolation (AMD SEV, Intel TDX), microVMs, attested execution environments.
8. Treat every natural-language input as untrusted; layer injection defenses. Direct injection uses instruction overrides, Base64/hex encoding, and adversarial suffixes — algorithmic attacks reach 100% success and transfer across model families. Indirect injection hides payloads in web pages and emails the user never sees; per Microsoft Research, LLMs cannot reliably distinguish informational context from actionable instructions, so filtering must be external to the model. Foundation: schema validation and length limits. Enterprise: pattern matching for known injection techniques and encoded payloads. Advanced: spotlighting (delimiting untrusted content — cuts indirect injection success from over 50% to under 2%) plus constitutional classifiers (blocked 95% of jailbreaks in Anthropic testing with minimal over-refusal). Also shrink the attack surface: limit who and what can reach the agent at all.
9. Allow-list tools; deny-by-default everything else; validate parameters on both the agent side and the tool side. Tool poisoning corrupts MCP tool descriptors, schemas, or metadata so agents act on falsified capabilities; rug pulls swap a legitimate tool for a malicious version (the first malicious MCP server documented in the wild posed as an email service while quietly duplicating every sent email). Require authentication for tools themselves — certificate-based or short-lived tokens bound to the calling agent's identity. Run/host MCP servers yourself on an immutable platform after verifying the code, sign them yourself, and repeat for every update. Watch for tool chaining: legitimate tools combined into harmful sequences (internal CRM + external email = exfiltration) execute through trusted binaries under valid credentials, so host-centric monitoring sees nothing.
10. Give each agent its own credentials — compartmentalization fails if split agents share a secret. Splitting one agent into several limits blast radius only when each has a unique ID and its own access credentials. Inject credentials at runtime from a secrets manager that logs access and supports emergency revocation (a CA issuing short-lived certs with CRL/OCSP; or managed identity / HashiCorp Vault if you lack PKI expertise).
11. Put explicit trust boundaries between agents. Verify the identity and authorization of other agents before accepting delegated tasks; check authorization at each step of a multi-agent workflow rather than trusting the initiator. This blocks unscoped privilege inheritance (a manager agent passing its full access context to a worker) and the confused deputy (a compromised low-privilege agent relaying valid-looking instructions to a high-privilege one). Log inter-agent communications and flag unusual delegation patterns.
12. Protect memory as an attack surface: isolate, verify, expire. Memory poisoning persists across sessions and serves attacker goals long after injection; variants include RAG poisoning of vector databases, shared-context poisoning in multi-tenant systems, and long-term memory drift too gradual for any single change to look malicious. Enforce session/user isolation. Validate integrity at every retrieval, not just at storage: hash content, tag each memory element with source and conditions of addition, keep hashes in tamper-resistant logs separate from the memory store, and on validation failure reject the context and alert — never proceed. Apply TTLs that auto-expire unverified memory, with shorter retention for high-risk context (external inputs, unverified tool outputs). Keep versioned memory stores for rollback and quarantine procedures for forensics.
13. Log everything with identity; trace actions to triggers. Foundation: log all tool invocations, data access, and external communications with agent identity and request context; propagate a request ID from triggering event through every resulting action. Enterprise: append-only, cryptographically verified, replicated logs; distributed tracing (OpenTelemetry) across multi-agent workflows. Advanced: full provenance chains — retrieved context, tool outputs, reasoning steps — replayable for audit and regulatory explainability.
14. Instrument dwell time and coverage before any other detection investment. Dwell time = anomaly occurrence to human awareness; coverage = fraction of alerts actually investigated. These are the two metrics AI automation moves most. Establish behavioral baselines (manual definitions → automated statistical learning → continuous refinement with drift detection, which also catches slow poisoning), then anomaly detection on API call rates, data-access volumes, and error frequencies. Target detection within an hour for critical systems. Standing test: would you know within an hour if an agent went rogue?
15. Automate the bookkeeping, not the decisions. Models take notes, capture artifacts, run parallel investigation tracks, draft the postmortem; humans make containment, disclosure, and customer-comms calls. Put a triage agent with read-only SIEM access at the front of the alert queue producing a structured disposition (query, think, report) before a human sees each alert. Practical start: pick one noisy high-false-positive rule, wire a model to its alert stream read-only, measure agreement against a human reviewer for two weeks, expand only if agreement is tolerable. High-impact automated responses require human approval even when recommended; defensive agents get the same zero-trust treatment (verified integrity, least privilege, clear escalation paths) — a compromised defensive agent is a powerful weapon.
16. Manage the AI supply chain like code, then go further. Just 250 malicious documents can backdoor LLMs from 600 million to 13 billion parameters, and the backdoors persist through supervised fine-tuning and RLHF. Roughly 100 malicious AI models have been found on major platforms, including reverse-shell payloads on load; the PyTorch dependency-confusion attack exfiltrated SSH keys during installation. Maintain an AI-BOM (OWASP's extension of CycloneDX ML-BOM) covering model provenance, training-data lineage, and fine-tuning parameters. Run OpenSSF Scorecard in CI (branch protection, fuzzing coverage, signed releases, maintainer activity). Audit the dependency tree for redundant libraries (a one-hour lockfile review with a frontier model); for small, unmaintained, poorly scoring dependencies, having a frontier model reimplement the subset you use is a standard response, not an exotic one. Sign models and software at every stage and verify at runtime, not just deployment. Ask vendors how they prepare for AI-accelerated exploit timelines.
17. Keep configurations trustworthy and recovery fast. Version-control agent configurations with mandatory review → cryptographically sign and verify before deployment → immutable images replaced (never modified) at runtime. Enable auto-updates wherever an update-caused outage is acceptable — manual approval delay is now the primary risk; signed updates flow automatically, unsigned changes are rejected outright. Document and periodically test rollback → automate rollback on failed health checks → self-healing with circuit breakers. Rehearse scale: run tabletops for five simultaneous critical incidents in one week, not one; pre-authorize emergency change paths (who can take a service offline, rotate a credential, block a network path, how fast, on what evidence).

Checklist

Before an agent reaches production, verify each item:

• Every agent instance has a unique, cryptographically rooted ID present in all logs and access requests
• No static API keys, shared service accounts, or credentials in code/config — short-lived IdP-issued tokens (minutes) with auto-refresh, injected at runtime from a secrets manager with logged access and emergency revocation
• RBAC deny-by-default at minimum; documented approved AND prohibited actions, enforced by permissions, not instructions
• Least agency per tool: read-only unless write is required; send/delete/schema-change rights separated and separately authorized
• Tool allow-list with deny-by-default; tools themselves require authentication bound to the calling agent's identity
• Parameter validation on both agent side and tool side
• MCP servers: code reviewed, self-hosted on an immutable platform, self-signed, re-verified on every update
• Sandboxed execution (restricted capabilities, syscall filtering, limited mounts/network) for any agent touching untrusted input
• Identity-based isolation: services accept only explicitly named callers; network segmentation as backstop only
• Input validation external to the model: schemas, length limits, known-pattern filtering; spotlighting/classifiers at higher tiers
• Output filtering for PII, credentials, and sensitive-data patterns; human-in-the-loop approval for high-risk actions with clear action descriptions and logged decisions
• Escalation triggers defined (high-value transactions, sensitive data categories, external communications)
• Multi-agent: per-agent credentials, authorization checked at every delegation step, inter-agent traffic logged
• Memory: session/user isolation; integrity hashes verified at every retrieval, stored separately; TTL on unverified memory; versioned store with tested rollback and quarantine
• Request IDs propagate from trigger through every action; logs are comprehensive at Foundation, immutable at Enterprise, streamed to SIEM at Advanced
• Behavioral baseline documented/learned; alerts on thresholds; every alert gets an automated first-pass triage before a human
• Dwell time and coverage instrumented; detection target under one hour for critical systems
• Agent configs version-controlled/signed; rollback documented and tested; blast radius assessed with the impossible-vs-tedious test — if containment relies on friction, assume it fails and restrict further
• AI-BOM maintained; OpenSSF Scorecard in CI; models and software signed end-to-end with runtime verification
• Governance: acceptable-use and incident-response policies covering agent compromise; deployment approval owner named; Shadow AI addressed

Anti-patterns

The source explicitly warns against:

• Counting friction as defense. Rate limits, extra pivot hops, non-standard ports, SMS MFA — all fail the impossible-vs-tedious test against attackers with near-zero per-attempt cost. Rate limits buy time; they do not stop a determined agentic attacker.
• Static API keys with rotation policies treated as acceptable. Rotating a key that model-assisted code analysis can lift straight out of a lockfile barely raises attacker cost. Known gap, not a legitimate Foundation posture.
• Trusting the model to police its own inputs. LLMs cannot reliably distinguish context from instructions; injection defense must live outside the model.
• Splitting an agent into several that share one credential. You have failed to compartmentalize the risk.
• Vague charters like "help with customer service." Undefined boundaries cannot be enforced; write approved/prohibited actions down and enforce them at the permission layer.
• Trusting delegation implicitly. Passing full access context to worker agents and executing relayed instructions without verifying original user intent enables privilege inheritance and confused-deputy attacks.
• Validating memory only at storage time. Poisoned content passes once and serves the attacker indefinitely; validate at every retrieval.
• Network segmentation as the primary boundary. An attacker who reaches a segment pivots through it if services accept any caller from that network.
• Automating containment/disclosure decisions. Automate evidence collection and write-ups; keep humans on the calls that matter.
• Blindly trusting defensive automation. Agentic SOAR has significant blast radius; apply the same zero-trust controls to it.
• Manual approval delay on signed updates. When exploits appear within hours of a patch, a two-week change-approval cycle is itself a security risk.
• Untested rollback procedures. They fail when you need them most; no amount of automation compensates for being unable to restore a known-good state.

Source

• Zero Trust for AI Agents (eBook, 36 pp., linked from the blog post of the same name) — https://claude.com/blog/zero-trust-for-ai-agents — 2026-05-27

Distilled from the official document(s) above on 2026-08-12. If this skill and the source disagree, trust the source.