Skip to content

Enterprise deploymentCustomer-hosted or fully managed.Contact salesView pricing

Identity-bound execution permits for autonomous agents

Technical paper · September 6, 2026 · 8 min readBy Samuel OyanEngineer
authorizationidentityarchitectureagents

An autonomous agent that holds standing privilege is a standing liability: one injection, one logic error, and it acts with everything it was ever granted. This paper specifies an alternative — zero standing privilege plus per-action, identity-bound execution permits — and shows how the same primitive answers both 'can this action run' and 'is this agent allowed to act for this user right now.'

Samuel OyanEngineer

Engineering notes on building a runtime AI-security gateway.

Technical paper · September 6, 2026 · 8 min read

The default way agents get access is the wrong way: hand the agent a credential that carries the union of everything it might ever need, then trust the model to use it responsibly. That design fails the moment the model is wrong — an injection, a specification-gaming shortcut, a hallucinated tool call — because the blast radius is the entire standing grant. This paper specifies the alternative the industry is converging on under names like intent-based access and just-in-time authorization: the agent holds no lasting privilege, and every action it takes is gated by an execution permit bound to a verified identity and issued for that action alone.

Zero standing privilege as the default

Zero standing privilege means the agent's identity, by itself, can do nothing consequential. It can request; it cannot act. Every consequential action requires a permit that is scoped to the specific resource and arguments, bound to the requesting identity, and short-lived. The permit is issued by a control-plane component that does not read model prompts and therefore cannot be argued into issuing one — the single property that makes this robust against the failure mode where the model is persuaded. If the agent is compromised, it still holds nothing; it can only ask for permits the control plane is free to refuse.

Per-action authorization, not standing access
Agent (NHI)own identityINTENT-BASED GATEthis agent · for this userthis action · right now?JITleast privallowdenyScoped permitTTL · this actionRefused + loggedzero standing privilege: authority is granted per action, not held by the identity

The gate asks the intent-based question — this agent, for this user, this action, now — and answers with a scoped, short-lived permit or a logged refusal. The identity holds no privilege between permits.

The permit is bound to a verified identity

An agent presents a runtime key. Tenancy and identity are derived from that key at the gateway rather than trusted from a claim in the request, which is what prevents one agent from asserting another's scope. The permit issued against that identity encodes four things: who is acting (the agent), on whose behalf (the delegated user authority), what may happen (resource and arguments), and for how long (a tight TTL). Binding the permit to the derived identity is what makes the delegation chain safe: authority cannot silently widen as work passes from agent to agent, because each action is re-authorized against the identity actually presenting the key.

Identity and tenancy derived from the key
ClientBearer itr_rt_*ExtAuthzverify-keyorg_idTenant ATenant BRLSA onlyRLSB only

Because scope is derived from the presented runtime key rather than asserted by the caller, a permit is always evaluated against the identity actually making the request — the foundation for preserving user authority across a delegation chain.

One primitive, two problems

The elegant part is that this is the same pre-action authorization step that stops a successful prompt injection from reaching a dangerous tool. Security teams tend to file 'stop the injection from acting' and 'govern the agent's identity' as separate projects. They are the same checkpoint. The action-authorization gate that refuses a tool call whose justification traces to an untrusted span is the same gate that refuses an action an agent is not entitled to take for this user. Provenance from ingress and identity from the key both feed one decision, evaluated at one place, at pre-action time.

Authorize, then permit, then execute
Agenttool intentPOST /v1/actionsauthorizePermitscoped · TTLExecutetool / MCP

The agent expresses intent; the gateway authorizes against identity, delegation, and provenance; a scoped permit is issued; only then does the tool run. The permit is the artifact that makes the decision auditable.

Behavioral bounds and evidence

Per-action permits also give you a natural place to enforce behavioral expectations. An agent has a normal envelope — the tools and data it usually touches for its approved task. Requests outside that envelope (a new data source, a privilege expansion, a tool it has never used) are exactly what the permit gate should escalate or deny, and each decision is emitted as an evidence event. That record is what turns agent authorization from an assertion into something a reviewer — or an EU AI Act auditor asking how a human can understand and interrupt the system — can actually inspect.

Scope of the claim

Identity-bound permits do not make an agent safe to hand unlimited autonomy; they make its authority explicit, scoped, revocable, and logged. The measurable change is blast radius: a compromised agent with zero standing privilege can attempt actions but holds none, so the damage is bounded by what the control plane grants in the moment rather than by everything the agent was ever provisioned. That is a smaller, defensible claim — and it is the one that survives the day the model is wrong.

Continue reading

← Back to blog