Zero Trust for AI Agents
Anthropic wrote the framework. emisar enforces it.
The lab behind Claude published Zero Trust for AI Agents — a security framework for giving autonomous agents access to real systems. Its core controls are least agency, deny-by-default tools, a human in the loop for high-risk actions, and durable audit evidence. emisar maps those controls to the boundary between an LLM and your infrastructure. Core action controls ship on Free; SIEM export is available on Team and Enterprise.
emisar is not affiliated with, endorsed by, or sponsored by Anthropic. “Zero Trust for AI Agents” is Anthropic's publication; we cite it because emisar is built to the control set it describes.
The design test
Impossible, not tedious.
“Does this make the attack impossible, or just tedious? … Prefer a control that removes a capability over a control that throttles it.”
emisar is built to pass that test the hard way. An action that isn't declared in a trusted pack doesn't exist for the agent to call — there is no rate limit to grind through, no unusual port to find, no prompt to talk past. A compromised agent can't escalate to a command the runner was never taught, because the runner refuses anything outside the contract.
Control by control
The framework, mapped to the product.
Anthropic groups controls into three tiers — Foundation, Enterprise, Advanced. Here is where emisar lands on the ones it owns: the boundary between the agent and your hosts. The engineering detail behind each row is in the security model.
| Control in the framework | Tier | How emisar enforces it |
|---|---|---|
| Deny-by-default tool allow-listing | Foundation | The trusted pack catalog is the allowlist. The runner refuses any action it doesn't declare — the model can't even see an undeclared command, let alone run it. |
| Least agency — typed, scoped capability | Foundation | Every action is a typed contract with per-argument bounds. Per-user and per-group runner scopes limit which hosts an agent can reach at all. |
| Short-lived, IdP-issued credentials — no static keys | Foundation | OAuth 2.1 for remote MCP clients; short-lived, revocable keys for everything else — each inherits the runner access of the operator who created it. No long-lived shell key sitting on the host. |
| Parameter validation, tool-side | Foundation | The runner re-validates every argument against the action schema and clamps options to their min/max before exec. |
| Version-controlled, integrity-checked configuration | Enterprise | Packs are versioned, content-addressed YAML. A hash the published catalog carries is trusted on sight; an unrecognized or changed one blocks dispatch until an admin reviews it, and the runner recomputes the hash and refuses a mismatch. |
| Tamper-evident, hash-chained host journal | Enterprise | Every action is recorded to the searchable off-host portal audit and to a hash-chained JSONL journal retained on the runner. emisar audit verify reports breaks in that retained chain. |
| Human-in-the-loop approval for high-risk actions | Advanced | Risk-tiered policy holds destructive actions for a person. The approver sees the actor, the args, the target host, and the rule that fired — one click to allow or deny. |
| Just-in-time / just-enough access | Advanced | One-use approvals and scoped standing grants. The agent gets the capability for the task, not standing access that outlives it. |
| Continuous audit ingest by your SIEM | Advanced | Your SIEM reads the cloud audit through a dedicated read-only credential. |
| Cryptographic non-origination — the platform can't act for you | Advanced | A customer-authorized bridge signs each request with a key the control plane never holds. A compromised control plane can relay that signed request — it can't forge, alter, replay, or originate one. The capability to act on your behalf is removed from the platform. Opt-in per runner. |
Where emisar stops
One pillar, not the whole framework.
The framework is broader than any one product, and we'd rather be precise than oversell. emisar owns the tool-access pillar — what an agent can do to your infrastructure, and the record of it. It does not do these, and doesn't claim to:
- Model supply chain — poisoned weights, fine-tuning backdoors, AI-BOM
- Memory & context poisoning across an agent's sessions
- Prompt-injection classifiers, spotlighting, input sanitization
- Behavioral anomaly detection and ML baselining
Here's the reframe that makes the scope a feature. emisar doesn't try to keep the agent pure — it assumes the agent may already be jailbroken or prompt-injected, and makes sure a compromised agent still can't exceed declared, gated, audited actions. That is the framework's first principle — assume breach — applied to the one place an AI agent can do real damage: the keyboard in front of your servers.
Operations
Automate the bookkeeping, not the decisions.
“Models should take notes, capture artifacts, pursue parallel investigation tracks, and draft the postmortem. Humans should make the containment calls.”
That is exactly the emisar loop. The agent investigates through read actions, correlates, and drafts the fix; the one destructive step stops for a person and lands on the record. We have a real incident written up end to end — a CSI driver that reformatted a live volume and wiped 33 hours of metrics, contained on a single approval.
Put the framework between your agent and production.
Install a runner, connect your agent, and every call crosses the boundary this page mapped — least agency, an approval where it counts, and an audit trail you can hand an auditor.
Three runners. Seven-day audit. No credit card.