APS для делегированных кошельков и агентских счетов (Второй путь, Проект 3)
Оригинал: APS for delegated wallets and agent accounts (Track 2, Project 3)
Трек 2, Проект 3 близок к тому, для чего был создан APS: агент, действующий в рамках определенных полномочий, без раскрытия основного ключа владельца и без ручного одобрения при каждом вызове. Этот уровень авторизации и аудита — это то, что сегодня реализует APS, открытый и Apache-2.0, на npm.
Примитивы напрямую связаны с проектом:
- Предопределенные ограничения без раскрытия основного ключа: агент действует под делегированным ключом с ограниченным доступом. Главный ключ владельца никогда их не покидает. Ограничения могут охватывать объем, ограничение расходов, временное окно и разрешенные действия.
- Никакого ручного подтверждения каждого действия: область заранее разрешает класс вызовов. Каждый запрос проверяется на соответствие делегированию перед его выполнением без участия человека.
- Владелец сохраняет контроль: субделегации могут только сузить полномочия, а отзыв гранта распространяется на все последующие этапы.
- Проверка контрольного журнала: каждое авторизованное действие выдает подписанную квитанцию, которая проверяется в автономном режиме, поэтому след не зависит от доверия к шлюзу, который его создал.
Проект 3 также охватывает агентов, покупающих вычислительные ресурсы, а не только вызывающих логический вывод. Та же модель распространяется и на оплату: один независимый от железных дорог интерфейс с одинаковой авторизацией, лимитами расходов и подписанными квитанциями. Эталонные адаптеры поставляются для x402 (USDC на базе) и Nano с привязкой к AP2 (протокол агентских платежей Google), Stripe Issuing и ACP. Железная дорога с токенами Gonka будет реализовывать тот же интерфейс и унаследовать лимиты, отзыв и квитанции без нового оборудования.
Чтобы внести ясность в границы, APS не является кошельком, хранилищем или расчетом. Он находится перед всем, что хранит средства, и вызывает логические выводы, решает, разрешено ли данное действие агента, и оставляет проверяемую запись о том, что оно произошло. Он работает как библиотека или дополнительный модуль и не требует изменения протокола.
Я скорее покажу это, чем опишу, поэтому рад представить небольшую эталонную реализацию пути к делегированному кошельку. Два вопроса, чтобы нацелиться на него:
- Существует ли текущая ветка или интерфейс для работы с делегированным кошельком/аккаунтом агента, или Проект 3 все еще находится на уровне дорожной карты?
- Ожидаете ли вы, что проверка авторизации будет проводиться ближе к уровню кошелька/учетной записи или к шлюзу вывода? Это решает, где находится чек.
Репозиторий: github.com/aeoess/agent-passport-system · npm: npmjs.com/package/agent-passport-system
Track 2, Project 3 is close to what APS was built for: an agent acting within scoped authority, without exposing the owner's main key and without manual approval on every call. That authorization and audit layer is what APS implements today, open and Apache-2.0, on npm.
The primitives map to the project directly:
- Predefined limits without exposing the main key: the agent acts under a delegated key with a scoped grant. The owner's main key never leaves them. Limits can cover scope, spend cap, time window, and allowed actions.
- No manual confirmation per action: the scope authorizes a class of calls up front. Each request is checked against the delegation before it executes, with no human in the loop.
- Owner keeps control: sub-delegations can only narrow authority, and revoking a grant cascades to everything downstream.
- Audit-trail review: every authorized action emits a signed receipt that verifies offline, so the trail does not depend on trusting the gateway that produced it.
Project 3 also covers agents buying compute, not only calling inference. The same model extends to payment: one rail-agnostic interface carrying the same scoped authorization, spend limits, and signed receipts. Reference adapters ship for x402 (USDC on Base) and Nano, with bindings to AP2 (Google's Agent Payments Protocol), Stripe Issuing, and ACP. A Gonka-token rail would implement the same interface and inherit the limits, revocation, and receipts without new machinery.
To be clear on the boundary, APS is not a wallet, custody, or settlement. It sits in front of whatever holds funds and calls inference, decides whether a given agent action is authorized, and leaves a verifiable record that it happened. It runs as a library or an opt-in sidecar and needs no protocol change.
I'd rather show this than describe it, so I'm happy to put up a small reference implementation against the delegated-wallet path. Two questions to target it:
- Is there a current branch or interface for the delegated-wallet / agent-account work, or is Project 3 still at the roadmap level?
- Do you expect the authorization check to live closer to the wallet/account layer or the inference gateway? That decides where the check sits.
Трек 2, Проект 3 близок к тому, для чего был создан APS: агент, действующий в рамках определенных полномочий, без раскрытия основного ключа владельца и без ручного одобрения при каждом вызове. Этот уровень авторизации и аудита — это то, что сегодня реализует APS, открытый и Apache-2.0, на npm.
Примитивы напрямую связаны с проектом:
Проект 3 также охватывает агентов, покупающих вычислительные ресурсы, а не только вызывающих логический вывод. Та же модель распространяется и на оплату: один независимый от железных дорог интерфейс с одинаковой авторизацией, лимитами расходов и подписанными квитанциями. Эталонные адаптеры поставляются для x402 (USDC на базе) и Nano с привязкой к AP2 (протокол агентских платежей Google), Stripe Issuing и ACP. Железная дорога с токенами Gonka будет реализовывать тот же интерфейс и унаследовать лимиты, отзыв и квитанции без нового оборудования.
Чтобы внести ясность в границы, APS не является кошельком, хранилищем или расчетом. Он находится перед всем, что хранит средства, и вызывает логические выводы, решает, разрешено ли данное действие агента, и оставляет проверяемую запись о том, что оно произошло. Он работает как библиотека или дополнительный модуль и не требует изменения протокола.
Я скорее покажу это, чем опишу, поэтому рад представить небольшую эталонную реализацию пути к делегированному кошельку. Два вопроса, чтобы нацелиться на него:
Репозиторий: github.com/aeoess/agent-passport-system · npm: npmjs.com/package/agent-passport-system