Permission Envelope Compilation: Why Static Permissions Are the Hardcoded Query Plans of Agent Systems

While working on agent permissions, I ran the same task three times.

The only thing I changed was the number of tools available to the agent.

First run: 34 tools. Second run: 7. Third run: 4.

It used the same 4 tools every time.

Thirty capabilities were unnecessary.

Most authorization systems assume the execution path is known ahead of time. Permissions are assigned at credential issuance through OAuth scopes, RBAC roles, or delegation grants, and the runtime is expected to stay within those boundaries.

That assumption works well for deterministic software. It becomes much harder to maintain when the execution graph emerges through reasoning.

Ask an agent to research a prospect and prepare outreach notes. Depending on what it discovers, it may consult Slack, HubSpot, Notion, Google Drive, or some combination of them. The path is not known in advance, yet the authorization model is expected to be.

The result is a familiar tradeoff: permissions are either restrictive enough to block useful work or broad enough to include authority the task never actually requires.

The more I work with agents, the more this resembles an older systems problem.

Databases stopped relying on fixed execution plans decades ago because the optimal plan depends on information that only becomes visible during execution. Agent authorization may be heading in a similar direction.

Static permissions are starting to look a lot like hardcoded query plans.

The challenge isn't identity alone, and it isn't delegation alone. Identity answers who is acting. Delegation answers what authority was granted. Neither answers what authority is justified for this intent, right now.

The intuition is surprisingly simple: start with the delegation grant, then progressively remove everything the task doesn't need.

I've started calling this Permission Envelope Compilation:

Effective Authority = Policy ∩ Delegation ∩ Intent Envelope

The envelope becomes the runtime boundary around the task itself.

Identity tells you who is acting.

Delegation tells you what authority was granted.

The envelope determines what they may do for this task, at this moment.

Last week I wrote about Uber's agent identity architecture. What stood out most wasn't the identity model or the delegation chain. It was what appeared next on the roadmap: Dynamic Access Control.

Identity was the first layer.

Governable execution appears to be the next.