PIC: authority that can only shrink.
PIC (Provenance, Identity, Continuity) is an open authority protocol. It signs cryptographic capability chains in which the human at the root is fixed forever and every step downstream can hold equal or fewer permissions — never more. Proxilion is the deployable system built on it.
PIC is the work of Nicola Gallo. Proxilion did not invent it — Proxilion deploys it.
The protocol specification lives at pic-protocol.org. The open-source reference implementation — the Trust Plane that signs and validates chains, plus the supporting crates — lives in clay-good/provenance. Proxilion depends on provenance-core directly and runs the Trust Plane as a service; it does not reimplement the cryptography.
Everything Proxilion adds is the system around PIC: OAuth-path interception, the SaaS adapters, prompt-injection read-filtering, write-gating with human-in-the-loop override, the action stream, the killswitch, and the YAML policy engine. PIC is the primitive. Proxilion makes it deployable in front of a managed AI agent.
The problem PIC solves
A bearer token says what may be done. It does not say for whom, right now, this call.
A managed AI agent holds an OAuth token to a SaaS API. That token carries scopes — drive.readonly, gmail.send — but it does not carry the human the agent is acting for on any given request. One agent, skilled for the whole organization, holds the union of every permission its users have. The SaaS API on the far side cannot tell whether the intern or the CEO is on the other end.
That gap is where the confused-deputy attack lives: the agent is tricked — by prompt injection, a poisoned document, or plain instruction-following — into acting beyond the current user's authority, using a token that is technically valid for the action. PIC closes the gap by making the principal cryptographically explicit, and the authorized operations monotonically narrowing, on every single call.
Three invariants, enforced by construction
Not by policy. Not by configuration. By the code path that signs each link.
Provenance
Every action traces back to one immutable origin principal. A successor link copies p_0 from its predecessor, never from the request — so a confused agent cannot reissue itself as a different user, even if the agent platform is compromised.
Identity
Operations can only narrow. A link may request any subset of its predecessor's authority, but never a superset. Escalation is not rejected at runtime — it is non-expressible, because no valid successor can carry it.
Continuity
Each link carries a cryptographic link to its predecessor's key and signature. Any verifier can walk the chain back to the root and validate every signature offline — no round-trip to the issuer. A forged link fails.
The origin principal cannot mutate
In the Trust Plane's issuance path, p_0 is a hardcoded copy from the predecessor — it is never read from the request body. p_0 = alice propagates from the root link all the way to the leaf, hop after hop.
Operations only shrink
If the requested operations are not a subset of the predecessor's, the Trust Plane returns a monotonicity violation and signs nothing. An agent granted drive:read:alice/* cannot reach drive:read:bob/* or drive:write:alice/*.
The chain is cryptographic at every hop
Each successor carries its predecessor's key id and signature plus the executor's signature on the request for continuation. A verifier walks the chain to the root and checks every link; a successor without a valid predecessor signature fails verification.
What a PCA chain looks like
A PCA — Proof of Causal Authority — is one signed link. Authority narrows toward the single action being performed; the principal stays fixed.
Each link carries five things
A PCA is the tuple { p_0, ops, hop, provenance, signature }. p_0 is the origin principal; ops is the authorized operation set; hop is the position in the chain; provenance binds this link to its predecessor (predecessor key id and signature, plus the executor's signature on the proof of continuity); and the Trust Plane's signature makes the whole thing verifiable offline.
Encoding and the Trust Plane
Deterministic bytes, one signing authority, offline verification.
PCAs are encoded as COSE_Sign1 over CBOR (RFC 8152), not JSON. CBOR is deterministic by construction with the right encoding rules, so canonicalization is built in — there is no separate normalization step to get wrong. The default signature scheme is Ed25519; P-256 and P-384 are available for organizations with FIPS requirements.
The Trust Plane is the service that signs and validates PCAs and enforces the three invariants. Its signing scheme (CAT) signs every link so that downstream verifiers — in Proxilion's case, the adapter sitting in front of Google's APIs — can validate a leaf and walk the chain to the root without round-tripping back to the issuer. Issuance is centralized; verification is distributed.
The roles in one sentence each
The Trust Plane signs and validates. An Executor requests successor links and forwards them downstream — Proxilion is an Executor. A Resource Server validates the leaf against the action being attempted — Proxilion's adapter layer plays this role too, in front of the real SaaS API.
How Proxilion uses PIC
The chain is built in the OAuth and HTTP path, one link per layer.
At identity-federation time, the user's IdP groups (Okta, Azure AD, Google Workspace, OIDC) map to the root PCA_0 operation set. At OAuth bind, Proxilion mints PCA_1 narrowed to exactly the scopes the user consented to on the provider's screen. Then, per action, the adapter mints PCA_2 narrowed to the single operation being performed — one file, one recipient, one calendar event.
Operators pick the enforcement posture per policy. In audit mode, the chain is produced and persisted for every action and invariant violations are alerted but not blocked — useful for rollout. In runtime-gate mode, an invariant violation or a policy ops-mismatch blocks the action and drops it into the review queue. The sensible default is to audit reads and gate writes.
When an operator overrides a blocked action, the override does not bypass the chain — it creates a new attested branch with the operator as a co-attestor. p_0 stays unchanged (Invariant 1 still holds); the operator's authority and justification are bound cryptographically alongside the user's original chain. Six months later, an auditor can see exactly who attested what.
What PIC does — and does not — promise
PIC is about authority. It is precise about its own boundaries.
| Property | In scope? | Detail |
|---|---|---|
| Origin principal is fixed | Yes | p_0 propagates unchanged from root to leaf. A confused or compromised agent cannot act as a different user. |
| Authority only narrows | Yes | Each hop is a subset of the last. Privilege escalation is non-expressible, not merely denied. |
| Offline chain verification | Yes | Signed links let any verifier walk back to the root without contacting the issuer. |
| Whether content is malicious | No | A document saying "ignore previous instructions" passes PIC fine — PIC is about authority, not content. Proxilion's read-filter is an orthogonal layer. |
| Side channels within allowed actions | No | PIC bounds what the agent may do, not how. A determined attacker can still encode data into permitted actions. |
The primitive is open. The system around it is too.
Read the protocol, read the reference implementation, or run Proxilion in front of your agent in an afternoon. Free, MIT-licensed, self-hosted.