Proposal: a "Resource-Side, Stateful" extension profile for Pre-Action Authorization (PAA)

Summary

First, thanks for OAP and for naming the Pre-Action Authorization (PAA) category — the tool-hook + declarative-policy + signed-receipt pattern is the right shape, and the Vault CTF result is a great piece of evidence. This issue proposes a complementary extension profile within PAA, not an alternative to it, for deployments where the actions being authorized are irreversible and the resource is regulated (BFSI, healthcare, critical infrastructure).

I'd like to discuss whether the spec can accommodate three optional capabilities as a named profile (working name: RS-PAA — Resource-Side, Stateful PAA).

Motivation: three gaps that appear once actions are irreversible

The current pattern is, by design, agent-side (the check runs in the framework's before_tool_call hook) and stateless (one decision per call). In regulated, irreversible-action settings three properties become load-bearing:

Enforcement-point placement. An in-process hook shares the agent's trust domain: a re-hosted agent, a directly-held resource credential, or an injected instruction can issue the underlying call without invoking the hook. A profile that allows the enforcement/receipt point to be mediated at the resource boundary (a reference monitor in front of the DB/API) gives a non-bypassability property the in-process hook cannot, because the check no longer shares the agent's fate.
Statefulness. A per-call ALLOW/DENY cannot see multi-step or cross-session escalation in which each step is individually in-scope but the aggregate is not. An optional stateful envelope keyed to principal/purpose (constraining cumulative effect, not just the current call) would close this.
Reversibility semantics. For irreversible actions, the decisive property is undo-ability. An optional field binding a compensation handle or human-gate to an action (so an irreversible action commits only inside a valid transactional/reversibility context) would let policies express this.

Concrete proposal (for discussion)

A new optional profile in the spec that adds, without breaking existing passports/policy packs:

enforcement.placement: agent | resource (default agent; resource signals the decision+receipt is emitted by a resource-side mediator)
policy.envelope: an optional stateful-envelope block (key = principal/purpose; a cumulative-effect predicate; update-on-commit semantics)
action.reversibility: optional { compensation_handle | human_gate } required for actions tagged irreversible: true

These compose with the existing identity (passport / DID), policy packs, and signed receipts — the envelope state and reversibility outcome would simply be additional fields in the signed decision record.

Relation to existing work

This sits cleanly on top of the identity substrate (IETF draft-klrc-aiagent-auth, NIST NCCoE agent identity/authorization) and is orthogonal to OS-layer containment (which it actually depends on as a precondition for the resource-side guarantee). The separation-of-powers framing and the formal treatment of resource-side, stateful enforcement are developed in prior/related work (arXiv:2604.23646; and a follow-up formalizing a non-bypassability theorem + a BFSI benchmark, in preparation) — happy to share drafts.

What I'm offering

A written profile spec PR if there's interest.
A reproducible BFSI benchmark (tiered like the Vault CTF) whose tests isolate the three capabilities above: cross-framework bypass, multi-step/cross-session aggregation, and irreversible-action rollback — usable as conformance tests for the profile.

Would the maintainers/working group be open to a "resource-side, stateful" profile under the PAA umbrella? Happy to align naming and structure with how you'd prefer to extend the spec.

No file, test, or implementation entry point is named. Start by reviewing the existing PAA, passport, policy-pack, and signed-receipt definitions, then determine whether the three proposed capabilities fit the current spec; done would require maintainer agreement on the profile scope before a spec PR or conformance tests can be defined.

由索引模型根据 Issue 内容生成。