It is already the latest posts!
It is already the oldest posts!

agent runtime lab en · 2026 · Technical Research Note

09. Agent Permission Is More Than Allow or Deny

Authorization decides whether one principal may perform one action on one resource under specific conditions

Modeling authorization across principal, action, resource, condition, and lifetime so read access does not expand into execution or network access.

Research edition · 9 chapters · 4 minute read · Updated 2026-07-27

Edition A · 中文 B · English
SCROLL

The test instructed every CLI to read the directory, modify nothing, and avoid the network. Storing that constraint as allowed=true loses who is allowed, which action is allowed, where it applies, and when it expires.

Five dimensions of authorization

DimensionQuestionExample
PrincipalWho acts?Main Agent or one child Agent
ActionWhat operation?Read, write, execute, connect, send
ResourceWhat target?File, domain, repository, account
ConditionUnder what restriction?Read-only, offline, confirmation required
LifetimeFor how long?One call, turn, session, persistent

Permission to read a workspace does not imply permission to execute its scripts. Permission to access API documentation does not authorize uploading data to arbitrary domains.

Model guidance and execution policy are separate

A system prompt can tell the model to ask before deleting. The executor still classifies the actual operation as deletion. The model chooses an appropriate action; policy decides whether the user authorized it.

If the model underestimates risk, policy rejects it. If policy permits the action but the model requests confirmation, the runtime may still ask. These decisions remain separate trace fields.

Permission does not propagate through a tool chain

After reading a page, the page asks the Agent to send email. Page-read permission does not grant email-send permission. Output from tool A cannot authorize tool B.

Delegation follows the same rule. A main Agent that can read a repository does not automatically grant every child the same scope. Each task packet receives a smaller action and resource set.

Approval states its scope

ItemExample
ActionWrite a file
Targetcontent/blog/
CountThis call once
ArgumentsInspectable normalized summary
InheritanceNot allowed

“Always allow for this session” is broader than one-call approval and must be a separate explicit choice.

A sandbox is not the whole permission system

A sandbox restricts the system resources a process can access. It can prevent filesystem escape and some network access. It cannot determine business authorization. Possessing an email API credential does not mean the user approved sending to a particular recipient.

The boundary combines filesystem sandboxing, network policy, credential scope, and business approval.

Normalize resources before matching

Policy evaluates canonical paths rather than raw strings and resolves relative segments, symbolic links, and relevant case rules. workspace/../secret can begin with the workspace string while resolving outside it. Domain policy similarly accounts for redirects and subdomain scope.

Logs omit credential values but retain normalized resource, matched rule identifier, and decision reason. That separates parsing failures, missing policies, and explicit denials.

The confirmation UI is part of authorization

The user-facing summary and executor arguments derive from the same normalized call. A dialog saying “write one article” does not authorize an expandable arbitrary Shell string.

Changing arguments after approval invalidates that approval. Otherwise a low-risk target can be approved and replaced before execution.

Regression tests

Fix five actions: workspace read, workspace write, outside-workspace read, allowed-domain access, and unapproved-domain access. Propose each through both the main Agent and a child, then repeat after one-call permission expires.

Every decision records the policy, matched resource, and expiration. A bare permission denied cannot distinguish correct enforcement from misconfiguration.

Authorization is a function

decision = policy(subject, action, resource, context, provenance)

Context includes time, network, workspace, and session state. Provenance says whether an argument came from the user, a project file, or a tool result. The model proposes action; the executor canonicalizes the resource and computes allow, deny, or confirmation.

MCP authorization forbids token passthrough and requires audience validation because possession of a token does not prove it is valid for this resource server. MCP Authorization

Path tests cover .., symlinks, case differences, mount boundaries, prefix confusion, and replacement after approval. The last is a time-of-check/time-of-use race. High-impact operations retain an opened handle or immutable resource identity.

Confirmation displays action, canonical resource, data destination, effects, and scope. Regression changes subject, action, resource, condition, provenance, and expiry one at a time.

Statement: If no specific statement in the content, the copyright belongs to sshipanoo . Reprint please indicate the link of this article.

(The content is authorized with CC BY-NC-SA 4.0 protocol)

Title:09. Agent Permission Is More Than Allow or Deny

Link:https://www.sshipanoo.com/en/blog/ai/agent-runtime-lab/agent-permission-beyond-allow-deny/