Cycles

Appearance

← Blog

· Cycles Team · 9 min read

securityzero-trustagentsMCPOWASPproductiontool-callinggovernance
Share Share

Zero Trust for AI Agents: Why Every Tool Call Needs a Policy Decision ​

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?"

The industry and the community arrived at the same answer simultaneously: every tool call an AI agent makes needs a policy decision 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 tool call is evaluated against policy before execution — not 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 the ten most critical risks in production agent systems. Nearly every one of them traces back to a tool call that should have been denied:

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 notes that most agent systems today are "fail-open" — the model proposes an action, the tool executes, logs are written, and monitoring happens after the fact. Zero trust flips this to fail-closed: nothing executes until policy says yes.

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 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 authorization is security authorization. An agent that burns $47K over a weekend because it misinterpreted an API error and ran 2.3 million calls is a security incident, not just a billing problem. Zero trust for agents must include spend limits as enforceable policy — per-agent, per-tenant, per-run.

3. Scoped, Hierarchical Permissions ​

Flat allow/deny lists don't scale. Production systems need hierarchical scopes: a tenant has a budget, each workspace within that tenant has a sub-budget, each workflow has a sub-sub-budget, and each agent within the workflow draws from its allocated share. When one agent exhausts its scope, others continue operating. When a sub-agent is spawned, it inherits constraints from its parent — it doesn't start with a blank check.

4. Concurrency-Safe Authorization ​

In any non-trivial deployment, multiple agents run simultaneously against shared budgets. Without atomic reservation, two agents can each check that $50 remains, both proceed, and spend $100. This is not a theoretical concern — it's the default behavior of every agent framework that checks budgets with a simple read-before-write pattern. Authorization decisions must be atomic.

5. Auditable Decision Trail ​

Zero trust without an audit trail is unverifiable trust. Every policy decision — allow, deny, escalate — must be recorded with the full context: which agent, which tool, which arguments, which scope, how much budget remained, and why the decision was made. This is what compliance teams need, and it's what OWASP's observability principle demands.

How Runtime Authority Implements Zero Trust ​

If you've read the Cycles documentation, these five requirements should sound familiar. Runtime authority is zero trust applied to AI agent actions.

Here's how the mapping works:

Zero Trust RequirementCycles Implementation
Pre-execution policy evaluationReserve-commit lifecycle — every action requires a reservation that passes policy 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 decisionsEvery reserve/commit/release is logged with full context, scope, and decision rationale

The architectural position matters: Cycles sits after the agent decides what to do but before it does it. The agent's orchestration framework (LangGraph, CrewAI, OpenAI Agents SDK) handles planning and tool selection. The observability layer (Langfuse, LangSmith) handles tracing and debugging. Cycles handles the authorization decision: should this action be allowed right now, given the current budget, permissions, and risk profile?

This is precisely the enforcement point that the Hacker News community identified as missing — a layer where "the agent cannot bypass" the policy, because the policy is evaluated external to the agent's reasoning context.

Adding Zero Trust to Existing Agents ​

For teams already using MCP-compatible tools (Claude Code, Cursor, Windsurf), zero trust enforcement is a single config change. The Cycles MCP server adds budget-aware tools (cycles_reserve, cycles_commit, cycles_decide) that wrap existing tool calls. No code changes to the agent.

For teams building with Python, TypeScript, or Spring Boot, the SDK wraps your existing LLM calls and tool invocations with reserve-commit checks. The integration pattern:

python
# Before: uncontrolled tool call
result = tool.execute(args)

# After: zero trust enforcement
reservation = cycles.reserve(scope, estimated_cost, action_metadata)
if reservation.decision == "ALLOW":
    result = tool.execute(args)
    cycles.commit(reservation.id, actual_cost)
elif reservation.decision == "ALLOW_WITH_CAPS":
    result = tool.execute(args, caps=reservation.caps)
    cycles.commit(reservation.id, actual_cost)
else:  # DENY
    handle_denial(reservation.reason)

Three outcomes — ALLOW, ALLOW_WITH_CAPS, DENY — give agents graceful degradation instead of binary pass/fail.

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 is not a new idea bolted onto an old framework. It's the inevitable conclusion of deploying autonomous systems in production: every action must prove it's authorized before it executes.

The infrastructure to enforce this exists today. The question is whether teams adopt it before or after the next incident.

Sources ​

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

Next Steps ​

Last updated:

Released under the Apache 2.0 License.

Copyright 2025-present RunCycles.io