The Ultimate 'Distrust': Zero Trust Permissions Model for Agents

What

For an Agent system, Zero Trust is not a networking buzzword; it is the "Permission Model for the Tool Execution Chain." It means defaulting to absolute distrust of any tool call, treating every side effect as an independent authorization decision, and strictly enforcing that decision at the execution point (PEP).

This article maps Zero Trust to implementable structures within an Agent runtime:

1. PDP/PEP: Where exactly the Policy Decision Point and Policy Enforcement Point reside.
2. ABAC (Attribute-Based Access Control): Authorization evaluates not just identity, but also task context and resource targets.
3. Failure and Degradation: What happens when policy queries timeout or approval chains fail? (Timeouts, Degradation).
4. Audit Evidence Chains: Every Permit/Deny decision must be fundamentally traceable (Auditing, Observability).

NIST SP 800-207 defines the logical components of a Zero Trust Architecture (PDP, PEP, etc.) and core principles, serving as the standard anchor for this engineering approach.

References:

1. https://csrc.nist.gov/pubs/sp/800/207/final
2. https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf

Problem

As an Agent gains access to an increasing number of tools, the traditional "issue a single API key" approach introduces massive structural risk:

1. Over-Privilege: A single key grants access to all tools. A single prompt injection can trigger a massive privilege escalation (Permissions).
2. Context-Blind Permissions: An Agent tasked with fixing CSS can suddenly delete a database, because authorization only checks identity, not intent.
3. Retry Magnification: Timeouts triggering retries result in duplicate executions of irreversible actions (Idempotency, Retries).
4. Untraceability: Post-incident, it is impossible to answer "Who permitted this call, why was it permitted, and what resources were affected?" (Auditing, Observability).

The goal of Zero Trust is not to "make the system harder to use," but to funnel the side-effect channel into a strictly governed protocol.

Principle

PDP and PEP: Policies Must Take Effect at the Point of Execution

The most critical boundary in Zero Trust is the separation of "Decision" and "Execution":

1. PDP (Policy Decision Point): Computes a Permit/Deny verdict based on input attributes.
2. PEP (Policy Enforcement Point): Forcibly enacts the PDP's result immediately before the actual tool execution, possessing the absolute authority to block, rate-limit, or terminate the session.

For Agents, the position of the PEP is highly specific: It sits exactly one layer in front of the tool registry / tool executor. Model outputs must never directly trigger side effects.

ABAC: Authorization Must Bind Task to Resource

The core premise of Attribute-Based Access Control (ABAC) is: Authorization is determined collectively by multiple attributes, not simply by "who you are." For an Agent, the most critical attributes typically include:

1. task_id / task_type: What is the current task?
2. tool_name / tool_risk_level: What tool is being invoked, and what is its inherent risk tier?
3. resource_targets: The target resource set (paths, domains, table names, project IDs).
4. actor: Agent ID / User ID / Environment.
5. history: Has a rejection been triggered recently? Is a retry storm occurring?

Usage

1) Tier Your Tools First (Risk Tiers)

Minimum recommended tiering:

1. read_only: Read-only queries, generates zero side effects.
2. write_low: Writable but rollback-capable (e.g., generating a patch file, but not directly committing).
3. write_high: Irreversible or high-risk (Deletions, Payments, Deployments, Permission modifications).

High-risk tools must default to HITL (Human-in-the-Loop) approval, mandating the display of visual diffs/previews (Auditing).

2) Policy-as-Code: Express Policies via OPA-like Decision Engines

Policies should not be scattered arbitrarily across your codebase as if/else statements. OPA (Open Policy Agent) provides an entry point for a policy-as-code decision engine, acting as your PDP: Input attributes, output a decision. Reference: https://www.openpolicyagent.org/docs

3) An Implementable Policy File (Example)

This policy example emphasizes three things:

1. Authorization tiered by tool.
2. Allowlisting/Denylisting based on resource_targets.
3. Explicitly defined timeout, retry, idempotency, and audit requirements.

# zero_trust_policy.yaml
rules:
  - tool: "file_read"
    risk: "read_only"
    allow_paths: ["content/**", "src/**"]
    deny_paths: [".env", "**/secrets/**", "~/.ssh/**"]

  - tool: "apply_patch"
    risk: "write_low"
    allow_paths: ["content/**", "src/**"]
    require_wal: true
    require_idempotency_key: true
    timeout_ms: 10000
    max_retries: 1

  - tool: "shell_exec"
    risk: "write_high"
    require_approval: true
    allowed_commands: ["npm test", "npm run build", "git status"]
    forbidden_commands: ["rm", "chmod", "curl", "sh"]
    timeout_ms: 600000
    max_retries: 0

4) PEP Implementation Skeleton: Forced Blocking Prior to Execution

class PolicyDecision:
    def __init__(self, *, allowed: bool, reason: str):
        self.allowed = allowed
        self.reason = reason


class PolicyEngine:
    """PDP: Inputs attributes, outputs Permit/Deny."""
    async def decide(self, *, tool_name: str, attrs: dict) -> PolicyDecision:
        raise NotImplementedError


class ToolEnforcer:
    """
    PEP: The forced enforcement point prior to tool execution.
    """

    def __init__(self, *, policy: PolicyEngine, auditor):
        self._policy = policy
        self._auditor = auditor

    async def call(self, *, tool_name: str, args: dict, attrs: dict):
        decision = await self._policy.decide(tool_name=tool_name, attrs=attrs)
        
        # CRITICAL: Audit logging must happen regardless of Permit or Deny
        await self._auditor.record_policy_decision(tool_name, args, attrs, decision)

        if not decision.allowed:
            raise PermissionError(decision.reason)

        return await self._execute(tool_name, args)

[!IMPORTANT] record_policy_decision is a foundational component of the audit evidence chain. It must be written to an immutable audit log (Auditing).

5) Timeouts, Retries, Idempotency: Zero Trust Must Encompass Reliability

Many engineers reduce Zero Trust to "Permit/Deny," but for Agents, this is vastly insufficient. You must integrate reliability directly into your policies:

1. Timeouts: What happens if the policy query itself times out? What if tool execution times out? (Timeouts).
2. Retries: Is a denied call retry-able? Is a permitted call retry-able upon failure? (Retries).
3. Idempotency: If permitted, are the resulting side effects allowed to be replayed? This mandates Idempotency Keys + WAL (Idempotency, Auditing).
4. Degradation: If the policy system goes down, does it default to Deny? Does it allow degrading to read-only? (Degradation).

HITL and Kill Switches (Humans are the Final Enforcement Gate)

For high-risk tools, the system must support:

1. Visual Previews: Command previews, diff previews, resource target previews (Auditing).
2. One-Click Kill Switch: Terminate the current task and violently terminate child processes to prevent cascading actions (Resource Release).

Pitfall

1. Implementing Authentication but Skipping Authorization: Being logged in does not equal permission to operate (Permissions).
2. Policies Scattered in Code: Impossible to review or rollback system-wide rules (Auditing, Rollbacks).
3. PEP Misplaced: Attempting to enforce rules purely via the LLM prompt is meaningless (Isolation).
4. No Timeouts on Policy Queries: A slow policy engine will fatally drag down the entire execution chain (Timeouts, Degradation).
5. Missing Audit Evidence: Inability to answer "Why was this permitted/denied?" reduces the system to an un-debuggable black box (Auditing, Observability).

Debug

When debugging a Zero Trust system, follow this specific sequence:

1. Policy Input: Are the attrs fully populated (task_id, resource_targets, etc.)?
2. Policy Decision: Is the reason for rejection explicable? Was it captured in the audit log?
3. PEP Enforcement: Did the PEP physically block the tool execution?
4. Timeouts/Degradation: If the policy system was unavailable, did the default behavior align with expectations?

Minimal Schema for Audit Logs (Strongly Recommended to Hardcode)

A primary value of Zero Trust is "Accountability." Therefore, every decision must generate an audit record containing at least:

1. task_id / trace_id
2. tool_name
3. resource_targets
4. decision (permit / deny)
5. reason_code (e.g., policy_rule_id)
6. idempotency_key (for write operations)
7. approved_by (if HITL was triggered)
8. latency_ms (PDP decision duration, crucial for isolating timeouts)

Without these fields, you cannot answer "Why was this allowed/denied," and Zero Trust devolves into an opaque, frustrating interceptor (Auditing, Observability).

Handling Policy Query Timeouts (Mandatory Degradation Strategies)

The PDP itself is an external dependency. It will experience lag, timeouts, and outages. You must decide in advance:

1. Default Deny (Recommended): If the PDP is unreachable, immediately deny all high-risk tools (Permissions).
2. Read-Only Degradation: Permit read_only tools to execute, but aggressively deny write_high tools (Degradation).
3. Circuit Breaking: If the PDP times out N consecutive times, suspend all side-effect tools and demand human intervention (Timeouts, Degradation).

If this isn't explicitly defined, your system will randomly permit or randomly deny during an outage, leading to an uncontrollable blast radius.

Policy Caching (Use with Extreme Caution)

The immediate engineering reflex is to cache policy decisions to boost speed. For Agents, caching introduces severe risk: If the context attributes shift, the cached decision may no longer be valid.

If policy caching must be implemented, it must satisfy:

1. The cache key must include task_id / tool_name / resource_targets / risk_level.
2. The TTL must be brutally short. Furthermore, only cache permit decisions, never deny decisions (to avoid permanent lockdown states).
3. Upon any sensitive event (e.g., a permission denial or anomalous tool invocation), immediately evict related caches (Auditing).

Incident Post-Mortem Template (Converting Permission Incidents into Iterative Inputs)

When privilege escalation or erroneous approvals occur, the post-mortem must answer:

1. What were the attribute inputs (attrs) for this call?
2. Why did the PDP issue a permit? Which specific rule was triggered?
3. Did the PEP actually enforce the constraints bound to the permit (Timeouts / Idempotency / Path Allowlists)?
4. Did a retry loop amplify the side effects? (Retries, Idempotency).
5. How must the policy-as-code be modified to permanently prevent this specific class of incident? (Rollback, Auditing).

Source

1. NIST SP 800-207: https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST SP 800-207 PDF: https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf
3. OPA Docs: https://www.openpolicyagent.org/docs
4. BeyondCorp: https://beyondcorp.com/