The gap between request and permission

An objective is not an access-control policy

“Get me to Edinburgh” is expressed in the language of outcomes. An authorization system must work in the language of principals, operations, resources and conditions. OAuth established a widely used framework for delegated authorization, in which a client receives limited access to a protected resource rather than the user’s password.[3] That is necessary infrastructure. It does not, by itself, infer which combination of calls faithfully implements a particular human objective.

The translation gap is easy to hide with scopes. A travel application may request calendar.read, travel.book and card.charge. Each scope sounds reasonable. Their Cartesian product is not. The card scope may work across merchants, the booking scope across trips, and the calendar scope across years. A task that needs one journey for one meeting inherits a standing region of authority.

Rich Authorization Requests improve the vocabulary by allowing structured authorization details rather than relying only on short scope strings.[10] Resource Indicators let a client name the intended protected resource, helping an authorization server audience-restrict a token.[8] DPoP can bind a token to a key so that mere possession is insufficient for replay.[11] These are valuable mechanisms. None decides whether the requested authority is the smallest authority that satisfies the human’s actual task.

The causal problem is authority coupling

A language model is probabilistic in two places that matter. It may infer the objective incorrectly, and it may select an unsafe route even after inferring the objective correctly. When the same runtime also holds broad credentials, uncertainty in interpretation is coupled directly to authority. Improving average reasoning quality lowers error frequency. It does not cap error consequence.

A compiler changes the causal structure. It inserts a representation that is narrower than the prose request and a separate enforcement path that the model cannot rewrite. The model may propose, “reserve room 214 at supplier H for £142.” The compiler resolves the supplier, action, amount, timing and approval rules into a capability request. A policy decision point checks that request. A token service or capability issuer produces the artefact. The hotel adapter validates it again before creating the reservation.

This is analogous to an ordinary compiler only in a bounded sense. Source text can be ambiguous; executable authority cannot. The intermediate representation exposes what would otherwise remain implicit. Type checks eliminate invalid combinations. Static analysis can identify wildcards, missing limits and unauthorised re-delegation. The compiled output is then consumed by a runtime with its own checks. The analogy breaks because human objectives lack the precise semantics of a programming language. The correct response to unresolved intent is rejection or elicitation, not a best-guess grant.

A toy example: scheduling one meeting

Suppose an assistant must schedule a thirty-minute call with Dev next week. It needs to read free-busy data and create one calendar event. A role called calendar.editor permits reading event details, deleting meetings and inviting any address. A compiled capability can instead permit freebusy.read for Mira and Dev over a seven-day window, followed by one event.create whose attendees equal the approved set and whose duration is at most thirty minutes.

Both permissions may be represented by tokens. Only the second encodes the task. The distinction is not “token versus capability” as a matter of format. It is standing authority versus task-shaped authority. A JWT can carry a narrow capability; an opaque token can reference one. A cryptographically elegant token remains overbroad if its claims are overbroad.

Why authority grows faster than the task

Consider a system with twenty tools. Each exposes five operations, and each operation may touch ten resource groups. A role designer does not create one grant for each possible task. They bundle access into something a human administrator can manage. The bundles are then reused across many workflows. This reduces administrative effort but creates permission combinations that no single objective needs.

Now increase the tool catalogue from twenty tools to two hundred. The model may become more capable because it can choose among more routes. The authority problem changes differently. Even when each tool retains the same five operations, the number of possible resource-action cells grows tenfold. Cross-tool compositions grow faster still: reading a customer record, exporting a file and sending a message may each be legitimate separately while their composition creates a disclosure path.

A common intuition says that better planning will select only the needed cells. That confuses use with possession. An agent may call three operations while holding three hundred. The unused permissions still exist when a prompt injection, stale plan or adapter bug changes the route. Least privilege is a property of the grant, not a retrospective description of which calls happened.

The compiler makes scaling tractable by generating task-specific grants from a stable action catalogue. Administrators maintain operation semantics, consequence classes and policy rules once. Individual objectives then instantiate narrow cells. This moves complexity from an expanding inventory of human-designed roles into a tested translation process. It does not remove policy administration. It changes the unit of administration from “what can this kind of agent generally do?” to “what authority does this configured task require now?”

flowchart LR
  A["The booking that should have<br/>been easy"] --> B["The gap between request and<br/>permission"]
  B --> C["What the compiler must make<br/>explicit"]
  C --> D["Authority under attack and change"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#087A98,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

What the compiler must make explicit

The delegation intermediate representation

Access-control systems already supply many pieces. Attribute-based access control evaluates subject, object, operation and environment attributes against policy.[5] Zanzibar-style systems model relations between subjects and objects at large scale.[6] Cedar expresses an authorization request as principal, action, resource and context, and is designed for policy analysis.[14] A delegation compiler should not replace these systems. It should produce a typed request they can evaluate.

The proposed Delegation IR has eleven fields. Each answers a different question that prose tends to blur:

1. Delegator: whose authority is being exercised?
2. Delegatee: which attested agent or workload may exercise it?
3. Objective: what outcome explains the grant, without itself granting anything?
4. Resources: which exact objects or bounded collections may be touched?
5. Actions: which typed operations are permitted?
6. Context predicate: which purpose, case state, location, device or approval facts must hold?
7. Validity: when does authority begin and end?
8. Budgets: what quantitative ceilings apply to money, calls, rows, messages or compute?
9. Delegation depth: may the agent create a child capability, and how much depth remains?
10. Evidence obligations: which decision and effect receipts must be written?
11. Revocation and recovery: how is the grant suspended, cancelled, compensated or safely recompiled?

Identity, world state and evidence are inputs to compilation, not strings the model may invent. The model proposal is another input. Authority is the compiler output. The typed action is a later request made under that authority. The verified outcome arrives only after readback from the authoritative system. Keeping these objects separate prevents the word “context” from becoming a sack containing everything.

Compile the plan in both directions

A one-way compiler starts with a proposed plan and asks which permissions each step needs. That is useful but incomplete. Authority should also shape the plan. If a route requires a permission that policy will not grant, the system should replan before obtaining credentials or touching external state.

Take the travel task. The first plan may propose an air ticket, a taxi and a hotel. The user’s preference for rail is soft, but the organisation’s travel policy may forbid domestic air for this route without an exception. The compiler rejects the flight operation. A bidirectional loop sends a typed reason back to the planner: air.reserve is unavailable; rail and approved ground transport remain available. The model can then search a smaller action space. This differs from telling the model “please obey travel policy”. The unavailable action is absent from the executable authority even if later context argues for it.

The loop needs a stopping rule. Repeatedly broadening a grant until a plan compiles would defeat the design. Replanning may only choose among actions already permitted by the objective, parent authority and policy. When no valid route remains, the output is an escalation request containing the blocked objective, rejected operation and minimum additional authority required. A human can then change the objective, provide an exception or stop the task.

This yields a useful separation. The planner optimises within a feasible authority region. The compiler defines that region. The policy engine decides whether a requested point belongs to it. The gateway enforces the final point against live state. No component may silently enlarge the region merely because completion is inconvenient.

Three invariants do most of the work

Let a capability be a set of permitted request cells. Each cell pairs one resource with one action and attaches conditions. If a parent capability permits cell set C_p, a child capability may use C_c only when:

This is monotonic attenuation. A child can do less, for less time, with less budget and fewer opportunities to delegate again. Macaroons demonstrated a practical credential design in which additional caveats can restrict a credential during decentralised delegation.[4] The compiler generalises that design principle to a richer task representation. It must never interpret an added caveat as permission.

The second invariant is no effect without a matching typed action. A generic call such as execute or admin defeats compilation because its real semantics live in an untyped payload. The operation registry should distinguish draft_message, send_message, place_hold and release_funds, each with different parameter bounds and review requirements.

The third invariant is authority must remain live. The gateway checks expiry, revocation, current entitlement, case-state digest and one-time-use status immediately before the effect. Token revocation and introspection are standard mechanisms for invalidating or querying token state.[18][19] Short lifetimes reduce exposure but do not replace explicit revocation when consent or entitlement changes mid-task.

A small numerical example: authority-area

Teams need a way to see how much authority they are leaving live. A simple illustrative measure is capability-hours. Count permitted resource-action cells and multiply by validity time. It is not a probability of harm. It is a comparison of exposed opportunity under a stable action catalogue.

A broad travel role covers twelve resources and eight actions for twenty-four hours: 12 × 8 × 24 = 2,304 capability-hours. Three grouped scopes cover four resources and four actions for twelve hours: 192 capability-hours. The compiled Edinburgh grant covers four specific resource-action cells for half an hour: 2 capability-hours. The ratio is informative even though the absolute unit is synthetic. Add consequence weights only when the organisation can defend them.

Worked example: a configured procurement system

A procurement assistant receives the objective: “Replace four failed analyst laptops this week, using the standard configuration, with total spend below £5,000.” The source authority comes from a cost-centre owner whose own limit is £10,000. The assistant has a distinct workload identity. The procurement catalogue exposes typed operations: search, quote, reserve, submit order and cancel order.

The compiler resolves “standard configuration” to catalogue bundle analyst-v7, checks that the four named employees are assigned to the cost centre, and binds the supplier set to two framework vendors. It permits search and quote immediately. It permits reservation for twenty-four hours. It permits one order submission only when quantity equals four, unit price stays below £1,250, the total remains below £5,000, delivery addresses match the employees’ registered offices, and the state digest still shows those assets as failed. The capability expires at the end of the week and emits a decision receipt plus a supplier acknowledgement.

What has the compiler contributed? Not purchasing intelligence. The agent may still choose the slower supplier or misread a product description. The compiler has made one claim enforceable: any executed order must remain inside the exact authority the cost-centre owner delegated for this replacement task.

Authority under attack and change

Issuance is one moment in a lifecycle

Designs often lavish attention on consent and token issuance, then treat expiry as the lifecycle. Real delegation changes while work is in progress. The user withdraws consent. The employee changes role. A payment beneficiary changes. The agent version is quarantined. A legal hold freezes the case. A capability that was valid at 10:00 may be invalid at 10:02 even when its cryptographic signature remains correct.

The runtime therefore needs a small state machine. A draft grant has no authority. Validation resolves policy and dependencies. Issuance creates a capability. Activation may wait for a task start or approval. Suspension blocks use without erasing the grant. Revocation ends it explicitly. Expiry ends it by time. Consumption ends a one-use grant. Recompilation creates a new version rather than mutating the old one invisibly.

Forks reveal whether authority really attenuates

Token exchange standards can represent delegation and impersonation across security domains.[9] GNAP defines a mechanism for delegating authorization to software and conveying the resulting artefacts.[12] These protocols are useful substrates. The compiler must still decide which parent facts survive into the child. The safe default is intersection, not inheritance: child authority equals the requested child task intersected with parent authority and current policy.

The runtime architecture: model proposal inside, authority outside

The clean system boundary places the model in an untrusted proposal zone. It may read permitted context, create a plan and populate typed action proposals. It cannot select the represented user, alter the capability, sign approval evidence or call consequential systems directly. A gateway verifies the workload identity, capability signature, audience, sender binding, expiry, revocation and action parameters. A policy engine re-evaluates live attributes. The adapter performs the effect and obtains readback. An evidence ledger stores the decision receipt and effect receipt.

Zero-trust architecture offers the wider principle: protect resources rather than trusting network location, and evaluate access using current information.[7] SPIFFE supplies a portable way to identify workloads cryptographically.[15] Workload identity answers “which running software is this?” It does not answer “may this software place this order for this person now?” The capability carries that narrower answer.

The confused deputy test

Norm Hardy’s confused deputy describes a programme that holds legitimate authority but applies it to a request whose authority is different.[2] Agents make the old problem easier to trigger because natural-language instructions, retrieved documents and tool results all enter the same reasoning context. Prompt injection is one route. Misresolved identity, stale entitlement and an innocent ambiguity can create the same authority confusion.

This thought experiment shows why receipts must record lineage, not only values. The policy decision should say which trusted fact established the beneficiary, which policy version ran, which capability was issued and which immutable proposal it authorised. The effect receipt should say what the downstream system actually changed. A generated rationale cannot substitute for either record.

The strongest boundary: intent has no complete compiler

Human objectives are open-textured. “Choose a sensible hotel” depends on neighbourhood safety, accessibility, loyalty preferences and facts not stated at instruction time. No compiler can derive a uniquely correct permission set from arbitrary language. A model can help elicit missing constraints, but its answer remains a proposal. The compiler’s reliable function is narrower: detect missing fields, bind trusted entities, enforce subset relations and reject grants that violate declared policy.

There is also a rival explanation for any observed safety gain. Perhaps the improvement comes entirely from adding a good policy engine, not from the compiler metaphor or the Delegation IR. That rival is serious. The proposal is strengthened only if the IR improves coverage, reviewability and test generation beyond hand-written policy for the same tasks. It is weakened if teams can achieve equal containment and lower operational burden with direct, carefully engineered policy requests.

Do not apply the full design indiscriminately. A public search or reversible personal draft may need only workload identity, rate limits and ownership checks. Compiling a one-use capability for every trivial read can add latency and consent fatigue. The method earns its cost when actions cross accounts, parties or authority domains; consume material budgets; disclose protected data; create external commitments; or become hard to reverse.

Failure case: the type name lies

Typed actions create confidence only when their adapters preserve the declared semantics. Imagine an operation registered as customer.note.create. Reviewers treat it as a reversible internal annotation. A downstream platform update makes notes visible in the customer portal and triggers an email notification. The capability is still narrow by name, yet its consequence has changed from internal drafting to external communication.

The compiler cannot detect this from the request. Its proof rests on the action catalogue. The catalogue therefore needs semantic versioning, contract tests and effect readback. A material adapter change must invalidate prior capability profiles until the operation is reclassified. The release test should compare declared and observed effects: which records changed, which messages left the boundary, which people could see the result, and what reversal actually restores.

This counterexample matters because it locates the proposal’s boundary. Delegation compilation can prove relations among declared objects. It cannot prove that the world implements those declarations. A narrow capability over a dishonest operation is still unsafe. The trusted computing base includes the action registry, policy evaluator, issuer, gateway and adapter, not only the compiler.

stateDiagram-v2
  [*] --> Claim
  state "An objective is not an<br/>access-control policy" as Claim
  state "The causal problem is<br/>authority coupling" as Test
  state "A toy example, scheduling one<br/>meeting" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Build and test the smallest useful compiler

Start with rejection, not automatic issuance

The smallest useful implementation does not need to mint production credentials. It needs an operation catalogue, a Delegation IR schema, a linter and a policy simulation step. Feed it proposed tasks. Make it reject wildcards, unnamed resources, excessive lifetimes, missing evidence, unsafe re-delegation and irreversible actions without the required approval. This alone turns invisible assumptions into reviewable errors.

The browser lab below implements that minimum. It uses synthetic data and does not call any service. Choose a sample or enter your own objective. The compiler generates resource-action cells only after mandatory fields pass. It then reports warnings that deserve human or policy review. A positive result means the request is structurally eligible for policy simulation and token issuance. It does not mean the user is entitled, the task is wise or the resulting action is safe. A negative result means the requested grant is under-specified or overbroad, not that the objective is impossible.

{
  "status": "not_compiled"
}

The schema is a contract, not a suggestion

A production implementation should validate the IR against a versioned schema and then translate it into the chosen policy and credential mechanisms. The shape below is deliberately technology-neutral. A Cedar policy, RAR request, GNAP access request, macaroon caveat set or proprietary capability token can be generated from it, provided the target preserves the same restrictions.

type DelegationIR = {
  schema: "delegation-ir/0.1";
  delegationId: string;
  delegator: { id: string; authorityRef: string };
  delegatee: { workloadId: string; keyThumbprint?: string };
  objective: { text: string; purpose: string };
  resources: readonly ResourceRef[];
  actions: readonly ActionRef[];
  conditions: {
    notBefore: string;
    expiresAt: string;
    stateDigest?: string;
    counterparties?: readonly string[];
  };
  budgets: Readonly<Record<string, number>>;
  delegationDepth: number;
  approval: "always" | "conditional" | "never";
  evidence: { decisionReceipt: true; effectReceipt: true };
  revocation: { handle: string; statusCheck: "required" };
  recovery: { onDeny: "replan" | "escalate"; onPartial: "compensate" | "pause" };
};

// Invariant for every child grant:
// child.cells ⊆ parent.cells
// child.validity ⊆ parent.validity
// child.budgets[k] ≤ parent.budgets[k]
// child.delegationDepth < parent.delegationDepth

The type separates identity, objective, authority, evidence and recovery. It does not prove that resource identifiers or action semantics are truthful; those require trusted registries and adapters.

Choose a compile profile by consequence

A practical rollout can use three profiles without changing the IR. A read profile permits bounded retrieval and reversible private writes. It requires workload identity, resource binding, short validity and a decision receipt, but may omit per-call human approval. A commitment profile covers messages, reservations and orders. It adds named counterparties, quantitative budgets, effect receipts, replay protection and compensation rules. A high-consequence profile covers actions such as releasing funds, changing legal status or disclosing sensitive data across parties. It adds current state digests, one-use authority, separation of duties and immediate status checks.

The profile is selected from operation metadata, not by the model’s confidence. A highly confident model does not make a payment easier to reverse. Conversely, a low-confidence model drafting a private note may need better review but not stronger financial controls. This keeps epistemic uncertainty and authority consequence distinct.

Begin with one operation in each profile. Compile real task requests in shadow mode, compare them with existing permissions and inspect every rejection. The first useful metric is often the difference between standing authority and compiled authority, not an end-to-end automation rate. Large differences reveal where current roles subsidise underspecified workflows.

A failure-injection protocol for the causal claim

Do not evaluate the compiler only by asking whether valid tasks complete. Compare three configured systems: a broad role, grouped scopes and compiled capabilities. Give each the same model, prompts, tool catalogue and task set. Then inject faults that target distinct assumptions:

1. Untrusted text requests a valid action on an invalid resource.
2. A valid resource identifier is replaced after approval.
3. User entitlement is revoked between planning and execution.
4. The agent forks a sub-agent and attempts to copy authority.
5. A one-use action is replayed after apparent timeout.
6. The system is interrupted after a reservation but before payment.
7. The action catalogue changes semantics without a schema-version change.

Measure at least five outcomes: legitimate task completion, unauthorised effects, authority-area, human interventions and recovery completeness. Add compile latency and policy-operation burden so safety is not purchased with an unusable system. Predefine a prohibited inference: a reduction in unauthorised effects does not establish that the model understood the user better.

What a positive or negative result permits

A positive result permits a narrow engineering conclusion: the compiler is a useful authority-shaping control for the tested action catalogue and failure distribution. It supports extending the task family gradually. It does not justify unattended operation in a new domain, a claim of general agent safety or removal of business approvals.

A negative result can mean several things. The compiler may be too restrictive. The action catalogue may hide dangerous semantics. Entity resolution may be untrustworthy. Runtime enforcement may not preserve the IR. Or the task may genuinely require flexible authority. Each failure should be typed. “The agent could not finish” is not enough. Record whether compilation rejected, policy denied, the gateway blocked, the system effect failed, or recovery could not restore a consistent state.

The current standards landscape reinforces the need for this separation. Agent authorization is an active IETF problem area. A recent use-case and gap-analysis draft names the disconnect between high-level user intention and specific authorization, along with delegation-chain and mass-revocation gaps, while explicitly remaining work in progress rather than an endorsed standard.[17] The right near-term posture is therefore modular: use stable standards for identity, audience, token exchange, sender constraint, status and policy evaluation; keep the task-shaped Delegation IR portable; and treat emerging agent profiles as replaceable encodings.