> Pigeon Pass is its own credential format. It is not a profile of JWT, CWT, macaroons, Biscuit, or UCAN.

Why?

> Pigeon is [...] not a [...] key custodian.

What's going on here then? https://github.com/pigeonlabsHQ/pigeon/blob/eb6a1e97b80c4951...

I suppose I'm the first human to read any of this.

A trivial problem solved in a very complex way

When an agent starts a sub-agent, it usually hands over the same credentials. An API key is the obvious case. The same pattern is deploy rights, database access, or permission to merge to main. The child then has everything the parent has.

Pigeon is a small protocol for that. You grant a Pass (capabilities, resources, constraints), delegate a narrower one to the child, and verify before the tool runs. If the child asks for more, it fails closed. Identity says who the agent is. Authority says what it may do.

There is no server. The real secret stays on the runner. The child carries the Pass.

from pigeon import grant, verify auth = grant( subject="agent:deployer", capabilities=["deploy"], resources=["environment:staging"], ) verify(auth, "deploy", "environment:staging").allowed # True verify(auth, "deploy", "environment:production").reason_code # RESOURCE_NOT_ALLOWED v0.1: own format (not JWT/Biscuit/UCAN), Ed25519, rate/count constraints, chain verify, MCP helpers as an enforcement point. Not a platform. Does not stop prompt injection.

Repo: https://github.com/pigeonlabsHQ/pigeon Release: https://github.com/pigeonlabsHQ/pigeon/releases/tag/v0.1.0 Demo: python demo/agent.py