Authority Continuity
When PIC-X starts, it exposes its public configuration at:
http://127.0.0.1:5556/pic-x/.well-known/pic-x-configuration
The document exposes public PIC-X endpoints and supported protocol capabilities. Internal Exchange Profiles are not exposed.
PIC-X as an Exchange into PIC
PIC-X provides the exchange interface into PIC.
It receives authorization material from an external mechanism, derives PIC authority, and returns a PIC Continuity Token.
In the OAuth-based flow described here, the PIC-X token endpoint implements the PIC profile of OAuth Token Exchange.
PIC-X receives an OAuth access token, validates it, and derives the initial PIC Context of Authority, or PCA. The PCA is a plain JSON authority context. It is not signed independently. PIC-X then places it in the first signed Continuity Transition, from which authority continuity begins.
OAuth access token
|
v
picX.exchange(accessToken, continuityProposal)
|
v
PCA 0
plain JSON PIC Context of Authority
|
v
signed Continuity Transition 0
|
v
PIC Continuity Token 0
|
+-- application PDP evaluation over current PCA
|
v
picX.exchange(continuityTokenN, continuityProposal)
|
v
PIC Continuity Token N+1
The application developer does not need to implement token validation, scope parsing, PCA construction, Continuity Transition signing, invariant selection, or continuity verification.
PIC-X stands for Provenance Identity Continuity Exchange.
Verifiable Authority Continuity across execution boundaries.
PIC has reached a point where the questions are becoming practical:
How can we use it? How can we test it? What should a real implementation look like?
Answering those questions requires more than specifications. It requires building the components that enable software engineers and architects to experiment with PIC in real systems.
The question. This article examines one narrowly defined security property: whether authority propagated across time and multiple execution boundaries remains verifiably attributable to the concrete execution and request for which it was granted.
The change of question in authority propagation: from actor selection to execution continuity
One scope condition should be kept in mind throughout this article: the following discussion of who concerns only the propagation of authority after initial authentication and authority origination. It addresses what happens when already-established authority is handed off, exchanged, resumed, attenuated, or otherwise continued across a later execution boundary. It does not claim that identity is unnecessary for authentication, initial authorisation, eligibility, accountability, revocation, or other security properties.
AI agent security is usually approached as an identity problem: the question becomes “what is the agent’s identity, and what is it allowed to do?”. This framing is inherited from decades of human-centric and client-centric authorization design, and it works reasonably well as long as the entity being authorized is stable, persistent, and accountable in its own right. AI agents are none of those things in practice, and the framing produces a steady accumulation of edge cases that identity-centric security models keep trying to patch without changing the underlying assumption.