Cycles

Appearance

← Blog

· Cycles Team · 9 min read

securityzero-trustagentsMCPOWASPproductiontool-callinggovernance
Share Share

Zero Trust for AI Agents at the Tool Boundary ​

Part of: AI Agent Risk & Blast Radius Reference — the full pillar covering action authority, risk scoring, blast-radius containment, and degradation paths.

In a single week in March 2026, Microsoft announced Zero Trust for AI, Cisco unveiled Zero Trust Access for AI Agents at RSAC 2026, and the Cloud Security Alliance published its Agentic Trust Framework. Meanwhile, on Hacker News, developers kept asking the same question: "How are you enforcing permissions for AI agent tool calls in production?"

A practical conclusion is emerging: every consequential tool call should cross a mandatory authorization boundary before it executes.

This isn't a theoretical shift. It's a response to what's happening in production right now. The Gravitee State of AI Agent Security 2026 Report — surveying 900 executives and practitioners — found that 88% of organizations reported confirmed or suspected AI agent security incidents in the past year. Only 14.4% of agents went to production with full security or IT approval. And yet 80.9% of technical teams have already pushed past planning into active testing or production.

The gap between deployment velocity and security governance is the defining risk of 2026. Zero trust is the architectural pattern that closes it.

What Zero Trust Means for AI Agents ​

In traditional infrastructure, zero trust replaced perimeter security with continuous verification: never trust, always verify, enforce least privilege. NIST 800-207 codified it. Every network request proves its identity and authorization before proceeding.

For AI agents, the same principle applies — but at the tool call layer. An agent doesn't make network requests the way a microservice does. It makes decisions that become actions: API calls, database writes, email sends, code execution, sub-agent delegation. Each action is an authorization event.

Zero trust for agents means:

  1. Every protected tool call is evaluated against application policy before execution — not merely logged after.
  2. Agent identity is explicit — each agent has its own credentials, not inherited user tokens.
  3. Permissions are scoped to the current task — least privilege, not broad access.
  4. Budget is part of the policy — cost authorization is security authorization.
  5. Trust doesn't transfer between agents — sub-agents earn their own permissions.

Microsoft's new Zero Trust for AI (ZT4AI) framework makes this explicit: it extends zero trust to the full AI lifecycle, evaluating how organizations secure agent identities, protect data used by AI, monitor agent behavior, and govern AI in alignment with risk objectives.

Cisco's approach at RSAC 2026 targets the same gap: new Duo IAM capabilities will let organizations register agents, map them to accountable human owners, and enforce fine-grained, task-specific permissions — with all agent tool traffic routed through an MCP gateway.

Why This Matters Now: The OWASP Top 10 for Agentic Applications ​

The OWASP Top 10 for Agentic Applications 2026 — developed by 100+ experts and peer-reviewed — identified critical risks in production agent systems. Several involve actions that a stronger execution boundary could reject or constrain:

OWASP RiskWhat HappensZero Trust Mitigation
ASI01: Agent Goal HijackAttacker redirects agent objectives via manipulated inputsPolicy engine validates actions against declared intent
ASI02: Tool MisuseAgent misuses legitimate tools through injection or misalignmentPer-tool permission checks with argument validation
ASI03: Identity & Privilege AbuseInherited credentials enable unauthorized operationsDedicated agent identity with scoped, short-lived tokens
ASI04: Supply Chain VulnerabilitiesMalicious tools or descriptors compromise executionTool invocation gated by allow-list and risk scoring
ASI08: Cascading FailuresSingle-point faults propagate across multi-agent workflowsPer-agent budget caps and scope isolation
ASI10: Rogue AgentsCompromised agents diverge from intended behaviorRuntime enforcement detects and blocks out-of-policy actions

OWASP's framework foregrounds a principle they call least agency: only grant agents the minimum autonomy required to perform safe, bounded tasks. This is zero trust applied to autonomy itself — not just access control, but action control.

What Developers Are Actually Building ​

The Hacker News thread "How are you enforcing permissions for AI agent tool calls in production?" reveals the state of practice. The most upvoted answer identifies the core architectural requirement:

"Policy evaluation has to happen outside the agent's context. If the agent can reason about or around the policy, it's not really enforcement."

This is the critical insight. A prompt-level guardrail is not zero trust — it's a suggestion the agent can reason around. Real enforcement requires a policy decision point (PDP) that sits between the agent's proposed action and execution, using deterministic rules, not probabilistic inference.

A Show HN post on runtime authorization for AI agents describes the pattern succinctly:

LLM → Proposed Action → Policy Engine → Allow / Deny / Escalate → Execution

The post describes a common fail-open pattern: the model proposes an action, the tool executes, logs are written, and monitoring happens after the fact. A fail-closed boundary instead ensures that protected actions do not execute until the required controls succeed.

On DEV Community, a widely-discussed post on structural failures in AI agents highlights a related gap: cost opacity. "Power users burn $30 to $800/month in API calls with minimal visibility." A commenter raised a fourth structural failure: "no audit layer verifying whether agent actions matched declarations." When agents malfunction, logs show what happened but not whether it was authorized.

The Five Requirements for Zero Trust Agent Enforcement ​

Synthesizing the Microsoft, Cisco, CSA, and OWASP frameworks with what developers are building in practice, five requirements emerge:

1. Pre-Execution Policy Evaluation ​

Every tool call placed in scope passes through a policy decision before execution. The policy engine is external to the agent — deterministic, testable, and not influenced by the agent's reasoning.

This is the difference between a guardrail and an enforcement layer. A guardrail inspects the agent's output. An enforcement layer controls whether the action happens.

2. Budget as a First-Class Policy Dimension ​

Cost exposure belongs in the security model. A retry or tool loop can consume substantial resources while each individual call is technically authorized. Zero-trust agent designs should include enforceable spend boundaries at the application scopes they actually use.

3. Scoped, Hierarchical Permissions ​

Flat allow/deny lists do not express cumulative exposure. Cycles can use explicit ledgers at tenant, workspace, workflow, agent, and toolset scopes. A protected call consumes every matching provisioned ledger atomically. Missing child ledgers are skipped, so the orchestrator must provision intended ceilings and separately restrict a sub-agent's tools, data, credentials, and delegation depth.

4. Concurrency-Safe Authorization ​

In many deployments, multiple agents run simultaneously against shared budgets. Without atomic reservation, two agents can each check that $50 remains, both proceed, and spend $100. Any framework integration that uses a simple read-before-write budget check has this race. Budget authorization decisions must be atomic.

5. Auditable Decision Trail ​

Zero trust without an audit trail is difficult to verify. The application should log the authorization decision, agent, tool, relevant arguments, and policy rationale for each protected action. Cycles separately records budget lifecycle data such as subject scope, amount, unit, reservation status, and settlement evidence. The current server does not inspect tool arguments or generate the application's authorization rationale.

How Runtime Authority Implements Zero Trust ​

If you've read the Cycles documentation, parts of these requirements should sound familiar. Runtime authority can supply the budget decision and settlement layer; identity, application authorization, argument validation, and complete tool-call logging remain separate controls.

Here's how the mapping works:

Zero Trust RequirementCycles Implementation
Pre-execution budget evaluationReserve-commit lifecycle — protected actions require a successful reservation before execution
Budget as policyHard spend limits — per-run, per-agent, per-tenant budgets enforced atomically
Hierarchical scopingScope derivation — tenant → workspace → app → workflow → agent → toolset
Concurrency safetyAtomic reservations — no double-spend across concurrent agents
Auditable decisionsReserve/commit/release lifecycle records capture budget scope, amounts, status, and optional evidence; application logs capture tool arguments and authorization rationale

The architectural position matters: a mandatory Cycles integration sits after the agent decides what to do but before it does it. The orchestration framework handles planning and tool selection, while the observability layer handles tracing and debugging. Cycles atomically answers whether the configured budget can cover the proposed estimate.

Application authorization, argument validation, identity policy, and tool allowlists remain separate controls. RISK_POINTS can budget application-assigned action exposure, but the current server does not infer risk, inspect arguments, or maintain the action registry described by the not-yet-implemented governance extension.

Adding Zero Trust to Existing Agents ​

For teams already using MCP-compatible tools, a config change exposes cycles_reserve, cycles_commit, cycles_decide, and the other Cycles tools. It does not wrap existing tool calls automatically. Hard enforcement requires Cycles Budget Guard for Claude Code or a mandatory check in the tool handler, gateway, harness, or service boundary.

For teams building with Python, TypeScript, or Spring Boot, the SDK exposes reserve and settlement operations that your application places around LLM calls and tool invocations. The outcome-aware pattern is:

text
reservation = create_live_reservation(stable_reserve_key, scope, estimate)
if reservation is rejected or malformed:
    stop before dispatch

attempt = dispatch_with_explicit_outcome(args)
if attempt is skipped before execution or demonstrably used zero:
    release(reservation, stable_release_key)
else if attempt started:
    commit(reservation, best_known_actual_usage, stable_commit_key)
else:
    retain the hold and reconcile; never release an ambiguous attempt

verify RELEASED, COMMITTED, or an idempotent APPLIED usage event
before deleting the durable settlement record

decide and dry-run flows use the three-way ALLOW, ALLOW_WITH_CAPS, and DENY model for graceful degradation. A live reservation succeeds with ALLOW or ALLOW_WITH_CAPS, or rejects insufficient budget.

The Convergence Is Not a Coincidence ​

When Microsoft, Cisco, OWASP, the Cloud Security Alliance, and Hacker News commenters all arrive at the same architecture in the same month, it's because production reality forced the conclusion. The pattern is:

  1. Agents deployed fast, with broad permissions.
  2. Incidents happened — runaway costs, unauthorized actions, cascading failures.
  3. Teams added observability — and watched the next incident happen in real time.
  4. The realization: you can't observe your way to safety. You need enforcement.

Zero trust for AI agents extends an established security model to a new execution boundary: consequential actions should prove identity, authorization, and applicable budget before they execute.

The component patterns exist today. Their effectiveness depends on placing them in every execution path being protected and combining budget controls with identity, authorization, validation, sandboxing, and monitoring.

Sources ​

The research for this post draws from discussions and reports published between February and March 2026:

Next Steps ​

Last updated: