Pigeon, a signed Pass for what a sub-agent may do

Your agent created a sub-agent and granted it the same API key. This child sub-agent is now capable of deploying to production, accessing payment data, and merging changes to the main codebase. However, Pigeon introduces a safeguard by providing a Pigeon Pass - a limited, signed credential that defines what the sub-agent can actually do, rather than a duplicate of your full permissions.

Unlike a standard pass, Pigeon's verification response includes not only a simple yes or no, but also a detailed reason code, a message explaining the denial, and the specific comparison that failed when validating your request against what the software allows. There is no external Pigeon server to connect to; instead, you manage the real secret on the host machine, and the child sub-agent carries this narrow Pass.

The child sub-agent cannot broaden its capabilities, expand its resource access, raise its bounds, or remove any constraints placed by the parent agent. If Pigeon cannot confirm the child sub-agent is more restricted than itself, it rejects the request. The runner must call the verify function for the Pigeon Pass to take effect - it is merely decorative if the runner never invokes this verification.

Each call from the client results in a narrower Pass being minted for that specific tool usage. The server checks the validity of this Pass before executing the intended tool. Identity and authority are distinct concepts - identity identifies who the agent is, while authority defines what actions the agent is permitted to perform.

Pigeon serves as a modest primitive, not a comprehensive platform, policy engine, identity provider, or key guardian. It does not prevent prompt injection attacks. Instead, Pigeon confines the blast radius of an AI agent's actions to the specific dimensions outlined in the Pass, and only within those boundaries.