An RFC 8693 token exchange that mints a short-lived token carrying nested act, sender-constrained with RFC 9449 DPoP so a lifted token is useless to whoever lifted it. A revocation list enforcement points poll, and public keys anybody can verify against offline. Revoking a delegation ends the right to act on somebody's behalf at every enforcement point on its next poll of the list, 12 seconds by default at the gateway, whatever the token still says about its own expiry; a call admitted before that poll is not pulled back. Today only the TokenFuse gateway polls that list; no other enforcement point does yet.
The Agent Passport spec disclaims two things on purpose. It is not an authentication protocol: the Passport names an agent, it does not prove possession. And it is not a freshness claim: the delegation chain records who acted on behalf of whom, not when. So the estate held the record of a delegation and pointed at a mechanism that did not exist. This is that mechanism, and it does not replace on_behalf_of; it makes it provable and lets it be ended.
The minted token carries cnf.jkt, the thumbprint of the caller's own key. Spending it needs a fresh DPoP proof from that same key on every call, so a token copied out of a log buys nothing.
By one token id, or by subject for every token an agent already holds. The list carries as_of, so an empty answer and an unreachable service are never the same answer to a machine reading it. Run end to end on a cluster: an agent revoked by subject mid-run was refused at the gateway 2.2 seconds later, with the gateway polling every second rather than its default of every 12.
Public keys at a JWKS endpoint, so an enforcement point verifies offline. That is also why there is no introspection endpoint, on purpose: it would put this service on the request path of every enforcement point at once.
| POST /v1/token | The exchange. A subject_token and an actor_token in, plus a DPoP header. Out comes a short-lived JWT with nested act and cnf.jkt. Since 2026-09-24 the same route also runs Cross App Access's jwt-bearer grant (RFC 7523, an ID-JAG in), closed unless VOUCHRYX_CLIENTS is set. |
| POST /v1/revoke | By jti for one token, or by subject for every token an agent holds. Both actor and reason are required, because a revocation nobody can attribute is an outage rather than a decision. |
| GET /v1/revocations | What enforcement points poll, carrying as_of. Each entry holds only what a verifier needs, jti, subject, issued_before and expires; who revoked a token and why stay in the operator's record. |
| GET /.well-known/jwks.json | Public keys. Verification is offline and stays offline. |
| GET /.well-known/oauth-authorization-server | RFC 8414 metadata for this service's own endpoints and grants. |
| GET /healthz | Liveness, no credential. Answers 200 once the process is listening. |
| no introspection | Refused by design. Wardryx answers at a 3.2 ms p50 and nothing here is going to sit in front of that. |
Two signed tokens and a proof go in, a short-lived one comes out, and the enforcement point verifies it without asking anybody. The dotted path is the one that matters in an incident: a revocation reaches the poller and the same token stops working before it expires.
TokenFuse refuses a call with a 402 before the provider bills, which is the right answer to a runaway. It is the wrong answer to a compromised delegation, where the spend is affordable and the problem is that the agent may act for somebody at all. Revoking ends that at every enforcement point on its next poll, and the token's own expiry has no say in it.
Three values are required and have no default: VOUCHRYX_ISSUER, VOUCHRYX_SIGNING_KEY and VOUCHRYX_TRUSTED_ISSUERS. The listen address and the token lifetime have defaults, and the others switch optional features on. A missing or malformed value aborts the process and names the variable. The reason is the shape of the two failures: a token service that came up trusting nothing would issue nothing and look healthy, and one that came up trusting a default would issue everything.
An RFC 8693 exchange takes two signed input tokens and a DPoP proof whose public key travels in the JWS header, which is a JOSE client before it is a curl command. So the client ships with the service: vouchryx-demo makes the keys, performs the exchange and prints a proof.
Measured on 2026-09-27 on the forge lab, with a lab image of vouchryx rather than a published release: a call 0.9 seconds after the subject was revoked was still answered, and one 2.2 seconds after it was refused, and every call after that was refused too. 218 tests, and the repository gates that number against its own suite.
A key names nobody and ends nowhere. This mints a short-lived token that says which human the agent is acting for, in a nested act claim, bound to the caller's own key so a copy of the token is useless. When the delegation should end, one revocation ends it at every enforcement point on its next poll of the list, rather than waiting for an expiry. Today only the TokenFuse gateway polls that list; no other enforcement point does yet.
Its next use is refused. Enforcement points poll the revocation list, every 12 seconds by default, and refuse anything on it, so the token's own expiry has no say; a call admitted before that poll is not pulled back, and a door that cannot reach the list keeps the last one it fetched and, past a minute, refuses by default. Measured on a live box: a proven chain answered 200, and after the revoke the same token answered 401.
No, it is the half the Passport spec deliberately leaves out. The spec says plainly that it names an agent without proving possession, and records who acted for whom without saying when. This provides both, and the record still lives where it lived.
Because it would put this service on the request path of every enforcement point at once. Verification is offline against published keys instead, and the policy plane keeps answering in single-digit milliseconds.
It refuses to start and names the variable. A token service that came up trusting nothing would issue nothing and look healthy; one that came up trusting a default would issue everything. Neither failure should be quiet.