AI Agent Permission Dilemma: Planning Is Not Permission — How Intent-Based Authorization Breaks the Deadlock

When an Agent's "Plan" Meets the Boundary of "Permission"

When a coding agent is troubleshooting a production bug, it may need to read the code repository, query logs, or even submit a Pull Request. If during its investigation it discovers suspicious behavior in another service, reading that service's logs seems like a reasonable next step. But whether it should have that permission depends on the specific investigation task — yet in reality, its credentials often grant fixed permissions unrelated to the task at hand.

This is a core contradiction in today's AI Agent security landscape: API keys and tokens carry almost no information about what the agent has been asked to do, who assigned it, or how the task reached the agent. Permissions are static and pre-configured, while tasks are dynamic and contextual. The gap between the two is becoming the biggest security concern for enterprises deploying agents.

Intent-Based Authorization: Making Access Follow the Task

To address this problem, intent-based authorization proposes a new approach: using the purpose and context of a task to determine the permissions for each access.

Specifically, when a request arrives, the authorization system evaluates three dimensions: whether the requested access matches the permission scope of the task assigner (a person or system), what the purpose of the task assigned to the agent is, and whether organizational policy permits it. For example, even if a customer support agent's toolchain can technically reach HR records, a request to retrieve HR data should be denied — because it falls outside its task remit.

A Real-World Incident Investigation Scenario

Imagine an alert about an error in a payment service. The orchestrator proposes launching an investigation, and the authorization service evaluates the request based on the authenticated trigger, the roles the agent is allowed to assume, and policies independent of the agent's control. It then grants the incident agent read access to the previous hour of logs for that service.

As the investigation progresses, the agent finds evidence pointing to the authentication service and requests access to its logs. Policy may automatically allow this additional access, or it may require human approval — but the runtime blocks the request before permission is granted. The agent can follow new leads deeper into the investigation, but it cannot unilaterally decide the scope of permissions that follow.

If the incident agent delegates the log analysis task to another agent, the recipient uses its own verifiable identity, receives only the permissions needed to complete its portion of the task, and stays within its own permission boundary. This handoff can narrow an existing authorization scope, but cannot expand it, while preserving task context and recording who passed the task along.

Capability Narrowing is a key security property in multi-agent collaboration. When Agent A delegates a subtask to Agent B, the permission scope B receives must be a subset of the permissions A currently holds — not a union or superset. This principle derives from the classic Principle of Least Privilege, but in the dynamic scenario of inter-agent delegation it requires additional mechanisms: each delegation must carry verifiable identity credentials, an explicit task scope, and a delegation chain record. If any link in the delegation chain attempts to expand permissions, the authorization system should reject the request outright. This way, even if an intermediate agent is compromised, an attacker cannot obtain permissions beyond the original task scope through the delegation chain.

Distinguishing Trusted Context from Untrusted Content

Throughout the investigation, the authorization system must strictly distinguish trusted context from untrusted content. An authenticated alert may contain log lines written by an attacker — trusting the source of the alert does not mean that instructions inside the alert can authorize access to another system. This distinction is critical for preventing prompt injection attacks.

Prompt Injection refers to an attacker hiding malicious instructions within seemingly normal data carriers (such as log lines, web content, or documents). When a large language model processes this content, it may mistake it for legitimate instructions and execute them. Unlike traditional SQL injection, prompt injection exploits the model's confusion between natural language instructions and data. In agent scenarios, the risk is further amplified: agents can not only "understand" malicious instructions but also have the ability to execute tool calls, so a carefully crafted log line could induce an agent to access unauthorized systems, leak sensitive data, or perform destructive operations. This is why an intent-based authorization system must separately judge "whether the source of the content is trustworthy" and "whether the content itself is trustworthy."

Software Factory: When Agents Start "Assigning Work" Too

In the Software Factory model, agents not only execute tasks but increasingly propose them. An orchestrator can monitor incidents and issues found by scanners, pick up bugs without a ticket, and dispatch agents to investigate and propose fixes.

But there is a key constraint here: an agent's ability to identify useful tasks does not give it the authority to assign the permissions those tasks require. The factory needs an independent authorization decision mechanism that enforces restrictions while the agent is running.

Limits Extend Beyond Access Control

These limits are not confined to access permissions, because an agent may execute a legitimate task in a bad way. It might issue thousands of unnecessary requests, or produce a change that passes review but fails in production.

Therefore, the control system needs multiple layers of protection: budget mechanisms limit resource consumption, checks and tests determine which changes can proceed, audit records outside the agent's control preserve operational history, and revocable access permissions let operators halt activity when problems arise.

Revocable Access stands in sharp contrast to traditional static API keys. Once a static key leaks, it remains valid until rotated; revocable permissions are typically implemented through short-lived tokens (such as OAuth 2.0 short-term Access Tokens) or dynamic credentials, allowing operators to revoke them immediately upon detecting anomalous behavior. In agent scenarios, this means: when a budget mechanism triggers an alert, audit records show anomalous patterns, or a review step discovers a suspicious change, the system can immediately cut off the agent's further access without affecting other normally running tasks. This "runtime interruptibility" is an indispensable security baseline for highly autonomous agent systems.

The Four-Boundary Architecture

The Software Factory reference architecture, developed jointly by Keycard, Docker, Barclays, Socket, and Aaron Stanley, shows how these controls work together. Built on top of the Agent Baseline, the architecture defines four boundaries:

• Identity and Access: Ensure every agent operation is traceable to a clear identity and authorization
• Supply Chain: Control the origin and integrity of software components used by the agent
• Sandbox: Constrain the agent's execution environment
• Network: Constrain the range of systems the agent can reach

These boundaries hold even as autonomy increases, combining task-scoped access with control over the software the agent uses, where it executes, and which systems it can reach.

Software Supply Chain Security faces new challenges in agent scenarios. Traditional supply chain security focuses on the origin, integrity, and vulnerabilities of dependency packages, but agents may dynamically generate code, call third-party tools, or introduce runtime dependencies, significantly expanding the attack surface. The supply chain boundary in this architecture requires that every component the agent uses undergoes origin verification and integrity checks, and that code generated or modified by the agent be independently reviewed before entering production. The sandbox boundary uses containerization or virtual machine isolation to ensure that even if an agent is induced to perform malicious operations, its impact is confined to an isolated environment. The network boundary further constrains the systems the agent can reach, preventing lateral movement. Together with the identity and access layer, these three form a defense-in-depth system.

Separating "Deciding What to Do" from "What Is Permitted"

The core insight of this architecture is that the factory can let agents decide for themselves what to investigate next, while keeping access decisions under independent control. This separation enables the system to take on more responsibility and autonomy without giving every agent broader standing permissions.

In other words, an agent's plan is not permission. It can plan, reason, and propose next actions, but how much access each step actually receives should be decided by an authorization layer independent of the agent itself. This is both a security necessity and a prerequisite for agents to move toward greater autonomy.

For teams building agent systems, this means re-examining the underlying assumptions of the permission model: shifting from "what can this agent do" to "what does this task require, and who has the authority to approve it."

One-line Summary

AI Agent security's core contradiction lies in the gap between static permissions and dynamic tasks, with intent-based authorization and the four-boundary architecture offering a path forward.

Paragraph Summary

Today's AI Agent API keys and tokens carry almost no task context information; permissions are statically pre-configured while tasks are dynamic and contextual, and this gap is becoming the biggest security concern for enterprises deploying agents. The article proposes intent-based authorization: dynamically determining each access based on three dimensions — the task assigner's permissions, the agent's task purpose, and organizational policy. Through an incident investigation scenario, it shows how agents can follow leads within authorization boundaries while ensuring delegation cannot expand permissions. The Software Factory reference architecture further defines four boundaries — identity and access, supply chain, sandbox, and network — alongside multi-layered protections such as budget mechanisms, checks and tests, audit records, and revocable permissions. The core insight is separating "deciding what to do" from "what is permitted," letting agents plan autonomously without autonomously expanding their authority.