Pigeon

Your agent spawned a sub-agent and handed it the same API key. That sub-agent can now deploy to production, read the payments database, and merge to main.

Pigeon stops that. You hand the child a Pigeon Pass : a narrowed, signed credential for what it may do, not a copy of everything you can do.

There is no Pigeon server to connect to. You change two places you already have:

Spawn. Where you would have copied an API key into a sub-agent, call delegate(...) and give the child a Pass.

Tool. Where the side effect happens (deploy, query, MCP tool), call verify(...) and do not run the tool if it is denied.

Keep the real secret on the runner. The child carries the Pass.

A child cannot add capabilities, widen resources, raise a bound, or drop a parent constraint. If Pigeon cannot prove the child is narrower, it rejects.

This is an enforcement point, not part of the protocol. The client mints a narrower Pass per tool call. The server verifies it before the tool runs.

Identity tells you who the agent is. Authority tells you what it may do.

Pigeon is a small primitive. It is not a platform, a policy engine, an identity provider, or a key custodian. It does not stop prompt injection. It bounds blast radius along the dimensions you put on the Pass, and only those.