In Sysdig's report, Zero Trust blocked 42% of harmless actions in a test of 50 AI agent workflows. The policy was technically sound, yet useful work became harder to complete. That is the uncomfortable failure mode of AI agents under Zero Trust.
The block rate points to coarse authorization; it is not proof that Zero Trust fails. Security must move beyond broad standing permissions. Task-scoped authorization at runtime can automate routine work and escalate consequential actions.
The 42% Block Rate Was a Usability Failure

The Sysdig test covered 50 workflows for AI agents. It measured something block counts often miss: whether approved work finishes. A control can protect the system while breaking the business process.
What the 50-workflow test actually says
The finding does not establish a system-wide failure. It does not show that Zero Trust missed harmful behavior, or that every deployment will have the same block rate. It also does not justify removing controls.
AI agents generate constant motion and noise. When policy evaluates isolated signals, legitimate activity can resemble risky behavior. What missing context turned a legitimate action into a denial?
Reframe the security scorecard
Block volume still belongs in diagnostics. It cannot be the top-line measure.
Evaluation must look beyond raw block counts. Teams need to know whether tasks finish and whether denials are justified. They must also confirm that high-impact actions are denied or escalated while harmless actions proceed.
A block-heavy policy can look excellent on a dashboard because every request stops. Yet the workflow may never reach its outcome. Prevented requests and completed business outcomes measure different things.
These false positives consume model context, trigger retries, and divert human attention. Their cost appears as stalled workflows and engineering support tickets.
The 42% is therefore a design warning about coarse authorization, not an argument against Zero Trust. If the block rate is the symptom, what policy decision is producing so many false positives?
Why Deny-by-Default and Human Prompts Break Down
Static permissions force a bad choice. Broad access exposes tools and data the task doesn't need. Narrow access blocks routine steps inside an otherwise approved workflow.
Deny-by-default is the right fallback. The problem is treating that fallback as the only possible outcome.
Modern cloud security solutions need more than network location or workload identity. Zero Trust for AI agents must check identity, permissions, tools, data access, connections, and actions in context.
Which decisions belong at runtime rather than standing access?
Authentication is not authorization
A valid workload identity proves who requests an action. It does not prove whether that action fits the current task, target, and data.
Authentication says “known agent.” Authorization must still say “right action, here, now.”
The agent may be known and still lack the right to act. What context settles that difference?
Approval fatigue changes the threat model
Prompting a human for every search or document read trains people to approve reflexively. Skip prompts, and the uncontrolled action chain returns. Neither path improves control.
Evaluating each machine-speed action in isolation misses chained risk. A read may look harmless until a later export changes the consequence. Trusting only the agent's broad role lets consequential steps inherit excessive trust.
That is why AI governance must express allowed behavior at the action and context level. Registration-time certification cannot describe what the agent is doing now.
Static certification cannot follow a changing task. Where should that context live?
Diagnose the coarse decision
Group blocked actions by type and workflow stage. Record the initiating identity, requested tool, and any missing context. These diagnostics show where authorization breaks down.
The pattern tells you whether policy is too broad, too narrow, or missing context. It also exposes the stage where human prompts pile up.
The wider audit gap appears when agent reach exceeds existing compliance scopes. Identity alone will not close that gap.
The fix is not to approve everything. It is to change the unit of authorization.
Changing the unit forces a sharper question: should access follow the agent, or the action?
Authorize the Action, Not the Agent
Change the unit of authorization from the agent to the action. Every meaningful request should become a current decision built from context. Identity remains essential, but it is an input, not a permanent grant.
A complete runtime decision uses context from the task, identity, target, and request. It checks the task initiator, agent or workload identity, and target. It also weighs the requested action, data sensitivity, and task state.
This is how Zero Trust for AI agents becomes operational. It also gives AI governance a reviewable unit: one request, one context, one decision.
Consider a support agent reading a customer ticket during task A. The same read should fail during an unrelated task or after task A closes.
The same agent can need opposite decisions across tasks. What outcomes let policy express that difference?
Five outcomes beat two
Binary allow-or-deny discards useful context. Govern the workflow with five outcomes. The allow outcome executes the request within its stated scope, while limit restricts its fields, records, or arguments.
The redact outcome removes sensitive content before release, and require approval sends a bounded request to a reviewer. If no valid path exists, the deny outcome rejects the request and returns a structured reason.
Each outcome tells the agent how to proceed or recover. This model helps only if routine work stays fast. Which actions can bypass a human prompt?
Automate reads. Escalate consequences.
Permit routine searches and document reads when the target and data are within scope. Reserve intervention for high-impact actions to protect the system.
High-impact actions include code execution, configuration changes, and access grants. Operators must also intervene for outbound communications, deletions, and financial commitments.
Continuous enforcement does not mean human approval for every read. It means no request inherits trust from an earlier login.
Bind permissions to the task and time window. Temporary access expires with the task instead of becoming another standing exception.
Properly designed controls preserve useful workflows while limiting unnecessary risk around sensitive targets. Too-coarse policy is wrong because it protects an abstraction while breaking the actual task.
The action-level model lets useful work proceed automatically and puts human judgment where consequences live. A precise decision model works only if every consequential request reaches an enforcement point. Where should that point sit?
Build an Inline Policy Path Without Free-Roaming Agents

Put enforcement between the agent and every protected target. Route every request for APIs, MCP servers, SaaS applications, internal tools, and sensitive data through one policy path.
Block direct bypass paths. Otherwise, agents will take them.
Inline mediation lets cloud security solutions inspect agent traffic, enforce flow control, route requests, and inject ephemeral credentials. It prevents AI agents from opening direct connections to sensitive assets.
The path should issue ephemeral, task-scoped credentials only after an executable decision. The agent then holds access for the task, not standing privilege.
Every request now has a route. Which checks must happen along that route?
Turn policy into a deterministic sequence
Evaluate every request in a fixed sequence. First, classify the action and check the task and data context. Next, select one of the five outcomes and attach the policy version and reason.
Last, issue a scoped, short-lived credential if the outcome permits execution. An illustrative vendor-neutral policy can look like this:
1{2 "api_version": "agent-policy/v1",3 "kind": "AuthorizationPolicy",4 "metadata": {5 "name": "support-workflow",6 "version": "1"7 },8 "spec": {9 "default_decision": "deny",10 "rules": [11 {12 "id": "read-ticket",13 "match": {14 "action": "document.read",15 "resource": {16 "system": "crm",17 "classification": "internal"18 }19 },20 "conditions": {21 "initiator": {22 "role": "support-agent"23 },24 "workload": {25 "id": "support-agent-prod"26 },27 "task": {28 "id": "task-4821",29 "state": "active"30 },31 "target": {32 "account": "customer-42"33 }34 },35 "decision": "allow",36 "reason": "task_scoped_read",37 "credential_scope": [38 "crm:tickets:read"39 ],40 "ttl": "15m"41 },42 {43 "id": "execute-code",44 "match": {45 "action": "code.execute",46 "resource": {47 "system": "sandbox",48 "classification": "internal"49 }50 },51 "conditions": {52 "task": {53 "id": "task-4821",54 "state": "active"55 }56 },57 "decision": "require_approval",58 "reason": "consequential_action",59 "credential_scope": [],60 "ttl": "5m"61 }62 ]63 }64}
The first rule allows a scoped ticket read during an active task. The second sends code execution to a reviewer, even when the task is active.
Both decisions are clear in the policy. What should a denial tell the agent when context is missing?
Make denials recoverable
Return structured reasons instead of a generic rejection. Each reason should name the exact cause, such as a missing scope, required approval, or redacted data. Other valid codes cover out-of-task access and explicit policy denial.
These codes let the agent adjust its plan rather than enter a blind retry loop.
Log every meaningful decision to maintain a complete audit trail. Capture the request context, including the initiator, agent identity, target, and action. Record the risk context, such as data classification and task state.
Also log the final decision, including the outcome, reason code, policy version, and approver where applicable. Record the downstream result beside it.
Without the downstream result, tool-call audit trails can end before the decision's impact.
Think of the gateway as an enforcement point, not the whole design. Decision granularity, explainability, and recovery from harmless denials matter more.
A denial can now explain itself, but policy still needs evidence from live workflows. How should teams test it without disrupting work?
Pilot Against Real Traffic, Then Tune by Action Class
Before enforcing candidate policies, build an authority map. A flat list of agents and roles hides where access actually changes.
List each agent, task initiator, and permitted tool in the authority map. Also record the target data, action type, and business owner. The map should show where access changes across workflows.
Give every row an owner. Without ownership, exceptions become permanent and unreviewable.
Use AI governance to assign business ownership and cloud security solutions to enforce the resulting technical path.
With ownership assigned, how can teams test those decisions before enforcement changes behavior?
Test decisions before changing behavior
Run candidate policies in observation or shadow mode against representative workflows. Compare each decision with known harmless and high-risk sequences.
The goal is to expose mismatches, not manufacture another headline benchmark.
Tune by action class and workflow stage, not individual request. One-off rules make behavior harder to explain and maintain.
Track harmless-block rate, workflow completion rate, and approval latency. Also monitor retry rate and the share of consequential actions denied or escalated.
Promote enforcement in stages to maintain control throughout the transition. The first stage observes candidate decisions before taking action. The second stage automates low-impact reads.
The third stage requires approval for high-impact actions. The fourth strictly denies clearly out-of-scope requests.
Record exceptions as time-bound grants with an owner, reason, scope, and expiry date. Review governance rules whenever tools, data classifications, or business workflows change.
Once the policy is calibrated, Zero Trust becomes an operating discipline rather than a blunt denial layer. How can teams prove that the calibration holds against real workflows?
What Changes When Security Preserves Useful Autonomy
Score utility and control together. A security dashboard that counts blocks but ignores failed workflows gives leaders false comfort.
Report harmless actions blocked, workflow completion rate, and approval latency. Also track retry volume and consequential actions denied or escalated.
The operational payoff is direct. Agents complete routine work without constant prompts. Code changes, access grants, outbound communications, deletions, and financial actions remain deliberately constrained.
Structured decisions and reason codes serve two audiences. Security teams get an audit trail. Agent platforms get recovery instructions.
This architecture supports scalable AI agents, explicit AI governance, and runtime controls delivered through cloud security solutions. It also gives each agent clear permissions and keeps governance active during execution.
The 42% result is not evidence that Zero Trust and autonomous agents are incompatible. It is evidence that coarse policy cannot support useful autonomy. The answer is not fewer controls; it is more precise decisions.
The practical test is simple: can Zero Trust preserve useful autonomy?
Frequently Asked Questions
Does Zero Trust make AI agents less useful?
It can when policies evaluate broad identities or interrupt every routine action. Context-aware Zero Trust lets required searches, reads, and other low-risk operations proceed automatically. It reserves intervention for consequential actions.
Which routine action class will you automate first?
About the author
Mayank Singh is a software developer at Levitation Infotech, where he builds web and AI-powered applications across the company’s fintech, healthcare, and enterprise projects.
