---
title: 'PAuth: Task-Scoped Implicit Authorization'
url: https://www.emergentmind.com/topics/precise-task-scoped-implicit-authorization-pauth
type: topic
---

# PAuth: Task-Scoped Implicit Authorization

Precise Task-Scoped Implicit Authorization, usually abbreviated **PAuth**, is an authorization model for agentic systems in which submitting a natural-language task implicitly authorizes only the concrete operations required for that task’s faithful execution, rather than granting broad permissions over operators such as `TRANSFER` or `SENDMAIL` [2603.17170]. It was introduced for the “agentic web,” where AI agents act on behalf of users by invoking existing services and tools, and it is motivated by the claim that operator-scoped authorization, exemplified by OAuth, is structurally misaligned with natural-language task delegation because it ties permissions to operators rather than to the specific operations implied by a task [2603.17170]. PAuth’s central technical devices are **NL slices**, which are symbolic specifications of expected service calls derived from the task and upstream results, and **envelopes**, which bind each concrete operand value to symbolic provenance so that servers can verify whether a received call is a faithful task step [2603.17170].

## 1. Conceptual basis and problem statement

PAuth was formulated against the background of the “agentic web,” in which users delegate open-ended natural-language tasks to AI agents that then interact with web services, tools, or Model Context Protocol servers [2603.17170]. In prevailing web authorization practice, delegated access is typically implemented through OAuth 2.0 scopes. Those scopes are operator-scoped: they authorize invocation of an operator such as `TRANSFER`, not a particular operation such as “transfer \$100 to Bob from my account” [2603.17170].

The resulting mismatch is the core problem PAuth addresses. For the task “Transfer \$100 to Bob from my account,” an OAuth-style bank must grant a generic `TRANSFER` permission, which authorizes any transfer using that operator rather than just the transfer implied by the task [2603.17170]. The paper argues that this inevitably overprivileges agents. It further argues that merely making scopes finer grained does not solve the issue, because multiple operands, dynamic numeric constraints, and runtime data dependencies produce a combinatorial explosion in permission variants and still fail to express relationships such as “one quarter of my Citi credit card balance” [2603.17170].

PAuth therefore shifts the unit of authorization from the operator to the concrete operation implied by the task. In this model, the relevant question is not whether a token contains a scope for a tool, but whether a received operator invocation with its concrete operands is consistent with the user’s task and with authoritative upstream results [2603.17170]. The threat model assumes one user, one agent, and multiple servers; the agent is untrusted and may be malicious, compromised, or subject to direct or indirect prompt injection; servers are assumed truthful about data for which they are the authority; and secure communication and an authentic user interface are assumed [2603.17170].

This places PAuth within a broader transition from identity-centric or operator-centric authorization toward task-centric and intent-governed controls. Related systems similarly argue that agents need authorization tied to current intent or current task, including deterministic pre-action authorization, task-centric access control, intent-governed narrowing, and portable authorization payloads [2603.20953] [2510.26212] [2606.22916] [2605.11487].

## 2. NL slices as symbolic task specifications

The first core mechanism in PAuth is the **NL slice**. An NL slice is a symbolic specification of the calls a given service expects to receive for a task, including which operator may be called, how each operand must be derived, and which preconditions must hold [2603.17170]. It is not a general policy language detached from the task; it is derived from the task itself.

For the task “Please pay a quarter of my Citi credit card balance using my Chase account,” with tools `Citi.getBalance(user)` and `Chase.transfer(sender, recipient, amount)`, the Chase slice is:

```ocaml
Chase.transfer(USER_ID, CITI_ID, Citi.getBalance(USER_ID)/4)
```

This means that the expected transfer amount is symbolically bound to the Citi balance, and that a concrete transfer is authorized only if its amount and recipient are consistent with that symbolic computation [2603.17170].

In the prototype, slices are derived in two phases. First, each server takes the signed natural-language task and tool schemas and uses an LLM to generate restricted Python code, represented as a single `def run(): ...` function [2603.17170]. This generated code is intentionally constrained: it may call only known tools and five helper functions—`min`, `max`, `len`, `first`, and `last`; loops are forbidden; and the language is restricted to simple control flow and schema-aligned tool calls [2603.17170].

Second, the server derives slices from that code by traversing the syntax tree and computing the dependency closure for each target tool call [2603.17170]. The resulting slice contains only the statements needed to compute that call’s operands and the branch conditions that guard it. The paper presents shopping-task examples such as:

```ocaml
let details = shop.get_product_details("Aurora Noise Cancelling Headphones")
assert details.stock > 0
assert details.price < 150.0
let cart = shop.get_cart_summary()
bank.send_money("GB33BUKB20201555555555", cart.total, "Order payment", "2024-06-11")
```

This slice states that the bank transfer is task-legitimate only if the product details show stock availability and a price below `150.0`, and only if the transfer amount is the `cart.total` obtained from the shop service [2603.17170].

At generation time, each slice is compiled into enforcer rules that record the allowed call, symbolic argument expressions, guard predicates, `let` definitions, and cross-service dependencies [2603.17170]. These rules are then used during runtime enforcement. The slice is thus the symbolic task specification; the compiled rule set is its executable authorization form.

## 3. Envelopes and symbolic provenance

The second core mechanism in PAuth is the **envelope**. An envelope binds a concrete value to a symbolic expression describing how that value was obtained, so that a server can verify the provenance of operands it receives [2603.17170]. The paper presents envelopes as values such as:

\[
\langle 17,\ G.g(F.f(1)+1) \rangle
\]

where `17` is the concrete value and `G.g(F.f(1)+1)` is the symbolic provenance [2603.17170]. If the envelope is produced by a server, it is digitally signed by that server; if it is produced by the agent for constants or local arithmetic, it is unsigned and therefore not authoritative in the same way [2603.17170].

Envelopes are used to carry symbolic provenance across service boundaries. In the three-server example with `F`, `G`, and `H`, the task-level code is:

```python
a = F.f(1) + 1
b = 2 * G.g(a)
c = H.h(b + 100)
```

The slice for `H` is:

\[
H.h(2 * (G.g(F.f(1)+1)) + 100)
\]

At runtime, `F` returns a signed envelope for `F.f(1)`, `G` returns a signed envelope for `G.g(F.f(1)+1)`, and the final call to `H` carries an envelope whose concrete value is checked against the symbolic expression `2 * G.g(F.f(1)+1) + 100` [2603.17170]. `H` verifies signatures on upstream envelopes, binds symbolic variables to concrete values, evaluates the slice expression, and confirms that the incoming concrete operand matches the result [2603.17170].

The same pattern appears in the Chase/Citi banking example. Citi returns a signed envelope for the card balance, such as `⟨1200, Citi.getBalance("Me@Citi")⟩`, and Chase verifies that the concrete transfer amount equals `bal/4` and that the recipient matches the slice before executing the transfer [2603.17170]. If an injected agent attempts to transfer `301` to `John@Chase` instead of transferring `300` to `Citi@Chase`, Chase detects both the operand mismatch and the provenance mismatch and treats the call as off-slice [2603.17170].

The envelope mechanism is therefore not merely data packaging. It is the runtime substrate that lets a server verify that each operand in a tool call arises from legitimate computations authorized by the task, rather than from arbitrary agent-side manipulation.

## 4. End-to-end workflow and enforcement architecture

In PAuth, the lifecycle begins when the user submits a natural-language task and the interface shows that text back to the user for digital signing [2603.17170]. The signed task text becomes the authoritative contract for authorization. The agent then distributes the signed task to the involved servers, and each server independently generates restricted code, derives slices, and compiles rules for its own tools [2603.17170].

During execution, the agent may behave benignly or maliciously. All tool calls pass through an **enforcer** that consults the precompiled rules and checks the received envelopes [2603.17170]. The enforcer resolves symbolic attributes, evaluates guards and operand expressions, verifies signatures on server-produced envelopes, and compares computed values to actual operands [2603.17170]. If a call is on-slice, it executes and the result is returned in a new envelope; if it is off-slice, the system raises a missing-permission warning or denies the call [2603.17170].

The AgentDojo implementation uses two pipelines. The task-submission pipeline performs imperative code generation, slice derivation, and rule generation; the execution pipeline intercepts agent calls, consults the rules, and stores envelopes in shared memory [2603.17170]. The authors also built a multi-host demo in which each service runs as an MCP server with its own PAuth runtime and envelope verification logic, so the same task-derived authorization checks occur across host boundaries rather than only inside a single process [2603.17170].

PAuth’s runtime posture is effectively fail-closed, because a call is allowed only if a matching rule exists and the concrete operands can be justified by the slice and envelopes. That design aligns with adjacent work on portable authorization and pre-action enforcement, which similarly emphasizes explicit constraints, deterministic evaluation, and fail-closed handling of mismatches [2605.11487] [2603.20953].

## 5. Empirical evaluation

PAuth was prototyped in AgentDojo and evaluated on the Banking, Slack, Workspace, Travel, and Shopping suites [2603.17170]. The evaluation included **100** benign task runs and **634** forced-injection runs, for a total of **734** runs [2603.17170]. Forced injections were constructed so that dangerous calls corresponding to original AgentDojo injection tasks were guaranteed to be executed by the agent, thereby stress-testing runtime enforcement rather than agent-side resilience [2603.17170].

The reported precision results were exact. Across all benign runs, PAuth produced **0** false positives, meaning no intended operation was blocked; across all forced-injection runs, it produced **0** false negatives, meaning every injected off-task operation triggered a permission violation [2603.17170]. The per-suite breakdown is likewise all zeros for both false positives and false negatives [2603.17170]. The paper therefore concludes that PAuth’s reasoning about permissions is precise in the evaluated scenarios.

The shopping suite was used to illustrate higher-complexity task structure. Those tasks produced between **13** and **24** rules per task, reflecting richer preconditions and cross-tool dependencies [2603.17170]. The evaluation also measured the token cost of code generation, which is the dominant LLM cost in the design because each involved server independently runs its own code generator on the task. Reported per-task cost ranged roughly from **\$0.002** to **\$0.038**, and the total cost scales linearly with the number of involved servers [2603.17170].

The paper additionally reports that GPT-4.1 was used for the full benchmark and that GPT-5-Mini, Gemini-3-Flash-Preview, and Claude Sonnet-4.5 were also tested on subsets, with all able to generate correct code for those tasks [2603.17170]. The empirical message is therefore twofold: the task-derived symbolic pipeline is executable at benchmark scale, and its runtime enforcement successfully separates faithful execution from injected deviations.

## 6. Relation to adjacent authorization research and open issues

PAuth is closely related to a family of recent task-centric and intent-governed authorization proposals, but its technical center of gravity is distinct. AgentSentry frames runtime task-centric access control as dynamic, minimal, and ephemeral policy generation for mobile agents, with default-deny and revocation at task completion [2510.26212]. Open Agent Passport formalizes deterministic pre-action authorization at the tool-call boundary, using passports, policy packs, and signed audit records [2603.20953]. Intent-Governed Access Control treats user intent as a monotone, auditable policy attribute that narrows static tool authority through intent certificates, manifest filtering, and intent-tool-payload consistency checks [2606.22916]. “Digital Identity for Agentic Systems” proposes a portable authorization model with issuer-authored payloads, typed constraint algebra, delegation attenuation, fail-closed evaluation, and pre-flight discovery [2605.11487]. “Agentic JWT” binds workflow intent, delegation chains, and per-agent proof-of-possession to signed intent tokens [2509.13597].

These systems share PAuth’s rejection of broad standing privilege. What distinguishes PAuth is its attempt to make authorization depend on **faithful execution of a natural-language task**, using **NL slices** to express the symbolic call structure expected by each service and **envelopes** to prove that each operand’s concrete value arises from legitimate task computations [2603.17170]. Related research on coding-agent least-privilege inference further suggests that exact task-scoped authorization is difficult for direct one-shot policy generation and benefits from decomposing sufficiency and tightness, rather than treating authorization as a single calibration problem [2605.14859]. This suggests that PAuth’s server-side derivation of slices, rather than trusting an agent to infer its own boundary, is a fundamental design choice rather than an implementation detail.

The paper also states several open issues. Real tasks often arise from multi-turn conversations rather than from a single self-contained instruction, so a reconfirmation step may be needed to synthesize and approve a canonical task description before PAuth enforcement begins [2603.17170]. Natural-language ambiguity remains unresolved: the model assumes the task is sufficiently unambiguous for correct server-side code generation [2603.17170]. Adoption would require standardization of slice languages, envelope formats, and deployment patterns across services [2603.17170]. Finally, the runtime cost of PAuth is not dominated by rule checking or envelope verification, but by the per-server LLM calls used to derive task code and slices, which means deployment cost grows with the number of services participating in a workflow [2603.17170].

In that sense, PAuth is best understood as a proposal for replacing operator-scoped delegation with **task-derived, provenance-checked, service-local authorization semantics**. Its central claim is not merely that authorization should be narrower, but that servers can verify faithful execution directly from the signed task, symbolic slices, and signed envelopes, without trusting the agent that orchestrates the workflow [2603.17170].

Source: https://www.emergentmind.com/topics/precise-task-scoped-implicit-authorization-pauth