Pigeon, 서브 에이전트의 권한을 제한하는 서명된 Pass
Pigeon, a signed Pass for what a sub-agent may do
AI 에이전트가 하위 에이전트를 생성할 때, 부모의 API 키 전체를 넘겨주는 대신 Pigeon Pass라는 제한된 서명 자격 증명을 전달합니다. Pass에는 수행 가능한 작업, 대상 리소스, 제약 조건이 명시되며, 하위 에이전트는 이를 벗어날 수 없습니다. Pigeon은 서버가 필요 없으며, 에이전트의 생성 및 도구 호출 지점에 통합하여 권한을 검증합니다. MCP 미들웨어도 제공하며, Python 3.12 이상에서 사용할 수 있습니다.
Identity tells you who the agent is. Authority tells you what it may do.
- Retr0id
Retr0id:
> Pigeon Pass는 자체 자격 증명 형식입니다. JWT, CWT, macaroons, Biscuit, UCAN의 프로필이 아닙니다.
왜?
> Pigeon은 [...]가 아니라 [...] 키 관리자입니다.
그렇다면 여기서 무슨 일이 벌어지고 있는 건가요? https://github.com/pigeonlabsHQ/pigeon/blob/eb6a1e97b80c4951...
아마도 저는 이걸 처음으로 읽는 인간일 거예요.
- awestroke
awestroke:
사소한 문제를 매우 복잡한 방식으로 해결했네.
- pigeonlabshq
pigeonlabshq:
에이전트가 서브 에이전트를 시작할 때, 보통 동일한 자격 증명을 넘겨줍니다. API 키가 가장 명확한 예죠. 배포 권한, 데이터베이스 접근 권한, 메인 브랜치에 병합할 권한도 같은 패턴입니다. 그러면 자식 에이전트는 부모가 가진 모든 것을 갖게 됩니다.
Pigeon은 이를 위한 작은 프로토콜입니다. Pass(권한, 리소스, 제약 조건)를 부여하고, 더 좁은 범위의 Pass를 자식에게 위임하며, 도구가 실행되기 전에 검증합니다. 자식이 더 많은 것을 요구하면 실패로 종료됩니다. Identity는 에이전트가 누구인지, Authority는 무엇을 할 수 있는지를 나타냅니다.
서버가 없습니다. 실제 비밀은 러너에 남아 있고, 자식은 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: 자체 형식(JWT/Biscuit/UCAN 아님), Ed25519, 속도/횟수 제약, 체인 검증, MCP 헬퍼를 강제 지점으로 사용. 플랫폼이 아닙니다. 프롬프트 인젝션을 막지 않습니다.
저장소: https://github.com/pigeonlabsHQ/pigeon
릴리스: https://github.com/pigeonlabsHQ/pigeon/releases/tag/v0.1.0
데모: python demo/agent.py