Pigeon

Pigeon решает одну конкретную ошибку: агент запускает субагента и отдаёт ему тот же API-ключ, так что субагент может делать всё то же, что и родительский агент. Вместо этого родитель передаёт Pigeon Pass - подписанный мандат со списком разрешённых дочернему агенту действий, а исполнитель инструмента проверяет Pass перед выполнением побочного эффекта. Это библиотека, а не сервис: никакого сервера Pigeon здесь нет.

Модель

grant создаёт Pass для субъекта с возможностями (действиями вроде deploy или open_pr), ресурсами (environment:staging, repo:acme/api) и ограничениями, например лимитом частоты запросов. delegate порождает дочерний Pass от родительского. verify проверяет запрошенное действие по Pass и никогда не возвращает простой boolean: отказ содержит код причины (RESOURCE_NOT_ALLOWED, CAPABILITY_NOT_GRANTED), сообщение и не сошедшееся сравнение запрошенного с разрешённым.

from pigeon import delegate, grant, verify, DelegationError

parent = grant(
    subject="agent:orchestrator",
    capabilities=["deploy", "open_pr"],
    resources=["environment:staging", "repo:acme/api"],
    constraints={"max_deploys_per_hour": 3},
)

worker = delegate(
    parent,
    subject="agent:pr-bot",
    capabilities=["open_pr"],
    resources=["repo:acme/api"],
    constraints={"max_deploys_per_hour": 3},
)

assert verify(worker, action="open_pr", resource="repo:acme/api").allowed

try:
    delegate(worker, "agent:rogue", ["open_pr", "deploy"], ["repo:acme/api"])
except DelegationError as exc:
    assert exc.reason_code == "PRIVILEGE_ESCALATION"

Делегирование работает только на сужение. Дочерний Pass не может добавлять возможности, расширять ресурсы, повышать лимит или отменять ограничения родителя; если Pigeon не может доказать, что дочерний пропуск уже, он отклоняет делегирование. Это идея сужения прав (attenuation) из токенов возможностей вроде macaroons, применённая к деревьям агентов.

В существующем агенте меняются два места. Там, где ключ копировался бы в субагента, вызывается delegate. Там, где происходит побочный эффект (развёртывание, запрос, MCP-инструмент), вызывается verify с отказом при запрете. Настоящий секрет остаётся у исполнителя. Интеграция с MCP выпускает более узкий Pass под каждый вызов инструмента на стороне клиента и проверяет его на сервере перед запуском инструмента (pass_for_tool, execute_tool). В CLI есть pigeon keygen и pigeon inspect pass.json.

git clone https://github.com/pigeonlabsHQ/pigeon.git
cd pigeon
pip install .

Ограничения, в основном указанные в README

В README границы применимости описаны на редкость прямо. Pigeon - это не платформа, не движок политик, не провайдер идентификации и не хранилище ключей; он также не защищает от prompt injection. Он лишь ограничивает радиус поражения по тем параметрам, которые записаны в Pass, и ни по каким другим. И, по выражению авторов, если исполнитель ни разу не вызывает verify, Pass остаётся декорацией: исполнение правил ровно настолько надёжно, насколько полно покрыты вызовами verify все инструменты с побочными эффектами. Если у субагента есть любой другой доступ к ресурсу - через сетевой маршрут или переменные окружения с готовыми учётными данными, - Pigeon на это никак не влияет.

В примерах из README работа с ключами не показана. grant вызывается без ключа, поэтому то, где хранятся ключи подписи и как проверяющая сторона узнаёт, каким из них доверять, описано в связанных SPEC.md и SECURITY.md, не изучавшихся для этой страницы. Библиотека ставится из клона git-репозитория; пакет в PyPI не упоминается. Требуется Python 3.12 или новее.

Место в контексте

onecli скрывает учётные данные от агентов, но оставляет каждому агенту полные полномочия каждого привязанного ключа; Pigeon дополняет его, сужая полномочия при каждой делегации, ничего не скрывая. В agent-identity-attribution разграничение прав для каждого агента названо сильнейшим практическим аргументом в пользу присвоения агентам идентичности, а Pass реализует такое разграничение без инфраструктуры идентификации. credential-compartmentalization ограничивает ущерб от утечки разделением учётных данных по разным хранилищам; аттенюация ограничивает его разделением полномочий по дереву агентов. В примерах из README у Pass есть ограничения по частоте, но нет срока действия, так что свойство ephemeral-credentials здесь явно не обеспечивается. Проверка на стороне исполнителя - это слой политик, описанный в sandboxing-ai-agents, перенесённый из сети на уровень вызова инструмента.

Находится на watchlist: проекту неделя, все коммиты сделаны за один день, 41★, а также это примитив безопасности без аудита и внедрений.

MIT, 41★, 2 форка, создан 2026-09-06, последний push 2026-09-06. Репозиторий: https://github.com/pigeonlabsHQ/pigeon