PAuth: Task-Scoped Implicit Authorization

• PAuth is an authorization model that grants only the specific operations implied by a natural language task, avoiding broad operator privileges.
• It employs NL slices as symbolic task specifications and envelopes to verify operand provenance across distributed services.
• Empirical evaluations demonstrate zero false positives and negatives, confirming PAuth’s ability to enforce faithful task execution in complex agentic workflows.

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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” (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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” (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Uchibeke, 21 Mar 2026, Cai et al., 30 Oct 2025, Zhu et al., 22 Jun 2026, Madhira, 12 May 2026).

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 (Sharma et al., 17 Mar 2026). 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:

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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

Second, the server derives slices from that code by traversing the syntax tree and computing the dependency closure for each target tool call (Sharma et al., 17 Mar 2026). 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:

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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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:

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). The enforcer resolves symbolic attributes, evaluates guards and operand expressions, verifies signatures on server-produced envelopes, and compares computed values to actual operands (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Madhira, 12 May 2026, Uchibeke, 21 Mar 2026).

5. Empirical evaluation

PAuth was prototyped in AgentDojo and evaluated on the Banking, Slack, Workspace, Travel, and Shopping suites (Sharma et al., 17 Mar 2026). The evaluation included 100 benign task runs and 634 forced-injection runs, for a total of 734 runs (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). The per-suite breakdown is likewise all zeros for both false positives and false negatives (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026). 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 (Cai et al., 30 Oct 2025). Open Agent Passport formalizes deterministic pre-action authorization at the tool-call boundary, using passports, policy packs, and signed audit records (Uchibeke, 21 Mar 2026). 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 (Zhu et al., 22 Jun 2026). “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 (Madhira, 12 May 2026). “Agentic JWT” binds workflow intent, delegation chains, and per-agent proof-of-possession to signed intent tokens (Goswami, 16 Sep 2025).

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 (Sharma et al., 17 Mar 2026). 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 (Yan et al., 14 May 2026). 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 (Sharma et al., 17 Mar 2026). Natural-language ambiguity remains unresolved: the model assumes the task is sufficiently unambiguous for correct server-side code generation (Sharma et al., 17 Mar 2026). Adoption would require standardization of slice languages, envelope formats, and deployment patterns across services (Sharma et al., 17 Mar 2026). 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 (Sharma et al., 17 Mar 2026).

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 (Sharma et al., 17 Mar 2026).