Which key speaks for your agent, and what it may do
A passport is a signed statement about an agent: who issued it, which key the agent holds, and exactly what that agent is allowed to do. It is checked offline, by you, against keys you chose to trust.
Free and open source under Apache-2.0. Issue locally, verify locally, no account and no call home.
An agent with no identity has only your network to thank
Any agent, any name
Without an issued identity, an agent is only as trustworthy as the row it holds in your config file. A borrowed name carries borrowed authority.
Authority nobody can name
"The agent may send this email" is prose until it is a scope a machine can check, refuse on, and hand to an auditor.
Proof that needs a server
If checking an identity requires asking a vendor, you have traded one dependency for another and your evidence lives in someone else's building.
Five steps, all offline
1. Issue
An issuer signs a statement about a subject: the agent's public key is bound inside the signature, along with the scopes it may exercise. Issuing in an issuer's name without that issuer's key is refused, not warned about.
2. Verify
The verifier checks the signature against the issuer keys it trusts and reports the identity route, such as issuer attested. Trust is supplied by the verifier, never assumed from the document.
3. Authorise
Ask whether a specific action on a specific resource is inside the agent's scope. The answer is deny by default, and a refusal carries a machine-readable code rather than a shrug.
4. Challenge
A verifier issues a single-use challenge for one action, with a short window. It is not a bearer token: it dies with its window and with its nonce.
5. Prove and check
The agent proves it holds the private key its passport carries, over that challenge. A presentation that reuses a spent challenge is refused, and a replay guard that cannot be consulted is a refusal, not an assumption.
Where it sits
The passport answers who an agent is and what it may do. It does not claim the action happened: that is the evidence layer's job, and the two records are checked against each other.
Verification that does not trust us
The proof is checked on your machine against keys you already hold. There is no validation service in the path, no account, and no network call to Empire Labs. If we disappeared tomorrow, every passport you issued would still verify.
That property is why the library is free and stays free. A verification you have to buy from us is a verification you cannot check without us, and it would be worth nothing to your auditor.
Bundled keys prove consistency with those keys. Authenticate their identity independently.
The same discipline applies to grades. A passport reaches the identity rung of the ladder and no higher. Anchored records require an externally provisioned timestamp and an independent custodian, and we say so rather than implying otherwise.
Run it now
Python 3.10 or newer and nothing else. A packaged release is going through the same signed-release path the verifier and the MCP validator already use, so today it installs from source:
git clone https://github.com/narko4u/witnessos-passport.git cd witnessos-passport pip install .
Then issue for an agent, verify offline, and ask whether an action is inside scope:
witnessos-passport keygen --key-out issuer.key
witnessos-passport issue --subject agent-01 --issuer empire-labs \
--issuer-key issuer.key --key-out agent.key \
--scope "fs.write:workdir:/srv/notes"
witnessos-passport verify passport.json \
--trusted empire-labs=<issuer-public-key-hex>
witnessos-passport authorise passport.json --action fs.write \
--resource workdir:/srv/notes \
--trusted empire-labs=<issuer-public-key-hex>
The full sequence, including the challenge and the holder-bound presentation, is on the instructions page.
The parts a library cannot do for itself
The library is free forever, including every local check. What we operate, for teams who would rather not run it themselves, is the state and the independence around it. Early access, priced per call and per month rather than per seat.
Shared replay guard
A single-use claim that spans machines, so a second verifier can see what the first one spent. The library ships a local one and says plainly that it cannot cover a second machine.
Issuer directory
A signed, published directory of issuer keys with revocation, so trust can be delegated without handing out keys by email.
Managed anchoring
Batched RFC 6962 inclusion proofs and external RFC 3161 timestamps over your records. You still verify offline against your own anchors.
Not in the path of any check: nothing above is required to issue, verify or authorise a passport, and no hosted component can see your keys or your records.
Give your agents an identity an auditor can check
Issue one in the next ten minutes, or watch the governed-action flow first.