Zero Trust for AI Agents
Never Trust, Always Verify — for AI agents too. Every agent, every tool call, every agent-to-agent message must be explicitly authenticated, authorized and logged. No implicit trust.
What is Zero Trust? Simply Explained
Zero Trust means: trust no one, verify everyone. For AI agents, this is especially important because they act autonomously and communicate with each other. Every agent must identify itself on every request — like security personnel checking every visitor, no matter how many times they've been there before.
↓ Jump to ZT principles, capability token example, and FAQ
5 Zero Trust Principles for AI Agents
Every AI agent call is authenticated — no implicit trust based on network location or agent name. Each agent presents a signed identity token on every request.
Implementation: mTLS client certificates for agent identity. JWT capability tokens signed with agent private key. No anonymous agent-to-agent calls.
Agents receive only the minimum capabilities required for their specific task. Tool access, data scope, and action permissions are explicitly granted per operation.
Implementation: Capability tokens scoped to declared operation. Per-tool allowlists per agent. Time-limited tokens (TTL 5min default). No wildcard permissions.
Design the system assuming any agent can be compromised at any time. Blast radius must be limited to the agent's declared scope — compromise of one agent must not compromise the system.
Implementation: Network micro-segmentation between agents. Memory namespace isolation. No agent can read another agent's memory or credentials. Kill-switch per agent.
Trust is not established once at connection time — it is continuously re-evaluated. Long-running agent sessions require periodic re-authentication and scope re-validation.
Implementation: Token refresh every N minutes. Behavioral anomaly detection on agent action patterns. Risk score recalculation on every tool call. Auto-suspend on anomaly.
All agent actions, all inter-agent communication, all tool calls are logged with cryptographic integrity. No agent has unobserved execution paths.
Implementation: Tamper-evident structured logs with hash chain. All inter-agent messages logged before delivery. Tool call input/output hashed. Full trace per user request.
Capability Token Example
# Moltbot orchestrator issues capability tokens per operation:
token = moltbot.issue_token(
agent_id="analyst-7",
operation_id="report-2026-q1",
scope=[
"read:data.sales_q1_2026", # Only Q1 2026 sales data
"write:report.draft.2026q1", # Only this specific report
],
tools=["pandas", "matplotlib"], # Only these tools
forbidden_tools=["bash", "http"], # Explicitly deny
ttl_seconds=300, # 5-minute expiry
max_tokens=50000, # LLM token budget
)
# Every downstream service verifies the token:
# Database: checks scope includes read:data.sales_q1_2026
# LLM Gateway: checks tool allowlist
# Output storage: checks write scope matches report path
# ALL checks cryptographic — no agent can forge a tokenFrequently Asked Questions
Why does Zero Trust matter specifically for AI agents?
Traditional Zero Trust was designed for human users accessing resources. AI agents introduce new trust challenges: 1) Agents are non-human — they can't use MFA or recognize social engineering. 2) Agents act autonomously at machine speed — a compromised agent can cause damage orders of magnitude faster than a compromised user. 3) Agents communicate with each other — creating lateral movement paths invisible in human-traffic Zero Trust. 4) Prompt injection can hijack agent identity — an agent following injected instructions is effectively impersonating an attacker. Standard ZTNA tools don't address these AI-specific vectors.
How do capability tokens implement least privilege for AI agents?
A capability token is a short-lived, cryptographically signed JWT that declares exactly what an agent is permitted to do for a specific operation. Example: {agent_id: 'analyst-7', scope: ['read:data.sales_q1', 'write:report.draft'], tools: ['pandas', 'matplotlib'], ttl: 300, issued_by: 'orchestrator', nonce: 'abc123'}. The token is signed by the orchestrator's private key and verified by every service the agent calls. The agent cannot exceed the declared scope — even if prompt-injected to try. Tokens expire after TTL — preventing replay attacks from stale tokens.
What is micro-segmentation for AI agents?
Micro-segmentation places each AI agent in its own network segment with explicit allow-rules for which services it can reach. A summarizer agent might only be allowed to reach: the LLM endpoint and the output storage. It cannot reach the database, secret store, or other agents directly. If the summarizer agent is compromised, the attacker is trapped in that micro-segment — they cannot reach sensitive systems. Implemented with: Kubernetes NetworkPolicy, Linux iptables per-container, or a service mesh (Istio/Linkerd) with per-agent mTLS and authorization policies.
How does Moltbot implement continuous verification for long-running agents?
Moltbot's continuous verification system: 1) Token refresh — capability tokens expire every N minutes; agents must re-request tokens from orchestrator, which re-evaluates current risk context. 2) Behavioral baseline — Moltbot builds a behavioral model of each agent (typical tools used, typical data access patterns, typical response times). Deviation from baseline triggers risk score increase. 3) Risk-threshold actions — at 70/100 risk score, agent is paused and flagged for human review. At 90/100, agent is automatically suspended and all pending actions cancelled.