
Криптографически подписанные квитанции делегирования для AI агентов. Четко определите, что AI может и не может делать — подписанные, проверяемые, защищенные от подделки.
AuthProof — это криптографический протокол делегирования для агентного ИИ. Большинство протоколов в этой области обеспечивают соблюдение политики, определяемой оператором, предоставляя оператору полномочия расширять или переосмысливать исходное намерение пользователя постфактум. AuthProof построен на другой модели доверия: собственный закрытый ключ пользователя подписывает объект авторизации, управляющий выполнением, а состояние живой модели проверяется как в момент авторизации, так и непосредственно перед выполнением. Сочетание подписанной пользователем авторизации и блокировки на основе состояния живой модели является конкретным утверждением, а не общей историей принуждения.
Что делает его особенным:
Пользователь является подписывающим органом. Каждый конкурирующий протокол (AIP, AITH, OAP, SAGA, AgentSpec) обеспечивает соблюдение политики, определяемой оператором. В AuthProof закрытый ключ пользователя напрямую подписывает объект авторизации. Оператор не может расширить область действия после того, как пользователь подписал.
Двухфазная фиксация состояния модели. Модель измеряется в момент авторизации и повторно измеряется непосредственно перед выполнением. Если модель «дрейфовала» между этими двумя точками, выполнение блокируется на этапе проверки перед выполнением.
Различие между обновлением провайдера и вредоносной подменой. Протокол классифицирует изменения состояния модели на две категории: легитимные обновления провайдера (PROVIDER_UPDATE_REQUIRES_REAUTH) и несанкционированные подмены (MALICIOUS_MODEL_SUBSTITUTION). Каждая генерирует машиночитаемый код причины отказа, идентифицирующий, какие компоненты изменились.
Детерминированный шлюз, который запускается перед выполнением любого действия агента.
PreExecutionVerifier находится вне среды выполнения агента. Среда выполнения никогда не получает управление, пока верификатор не пройден. Скомпрометированный или вредоносный агент не может его пропустить — он запускается до запуска среды выполнения.
Традиционные проверки авторизации выполняются внутри среды выполнения агента. Если среда выполнения скомпрометирована, эти проверки могут быть пропущены, переупорядочены или обойдены. PreExecutionVerifier устраняет эту поверхность атаки, полностью вынося авторизацию за пределы среды выполнения. Агент выполняется только в том случае, если — и только если — все шесть последовательных проверок сначала пройдены.
import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier' import { RevocationRegistry } from 'authproof-sdk'
// 1. Set up the gate const delegationLog = new DelegationLog() const revocationRegistry = new RevocationRegistry() await revocationRegistry.init({ privateKey, publicJwk })
const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry }) await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })
// 2. Register your delegation receipt delegationLog.add(receiptHash, receipt)
// 3. Gate every action â before the agent runs const result = await verifier.check({ receiptHash, action: { operation: 'read', resource: 'calendar' }, operatorInstructions: 'Summarize meetings. Stay within scope.', programHash, // optional: prevents code substitution attacks })
if (!result.allowed) {
throw new Error(Blocked: ${result.blockedReason})
}
// Agent runtime only reaches here after all six checks pass
### Шесть последовательных проверок (остановка при первой неудаче)
| # | Проверка | Блокирует, когда |
|---|----------|------------------|
| 1 | Подпись квитанции | Недействительная подпись ECDSA P-256 или квитанция изменена |
| 2 | Отзыв | Квитанция была отозвана через `RevocationRegistry` |
| 3 | Временное окно | Квитанция истекла или еще не действительна (используется оракул временных меток, а не клиентские часы) |
| 4 | Область | Действие отсутствует в `ScopeSchema.allowedActions` или не проходит текстовое сопоставление области |
| 5 | Инструкции оператора | Текущие инструкции не соответствуют хешу, зафиксированному в квитанции при выдаче |
| 6 | Хеш программы | Предоставленный `programHash` не соответствует хешу `executes` (предотвращение подмены кода) |
Каждый результат проверки — пройдена или не пройдена — автоматически записывается в неизменяемый `ActionLog`, подписанный собственным ключом верификатора.
### Интеграции промежуточного ПО
Модули-обертки для распространенных фреймворков. Каждая обертка пропускает каждый вызов через `PreExecutionVerifier` перед выполнением обернутого кода.
- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/HEAD/src/middleware/langchain.js)** — оборачивает любого агента с методом `invoke()`
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/HEAD/src/middleware/express.js)** — промежуточное ПО для запросов для любого совместимого с Express фреймворка
- **[Обертка для произвольных функций](https://github.com/commonguy25/authproof-sdk/blob/HEAD/src/middleware/generic.js)** — оборачивает любую асинхронную функцию```js
// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })
// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))
// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })
Каждый существующий фреймворк IETF для идентификации агентов â AIP, draft-klrc-aiagent-auth, WIMSE â решает вопрос доверия между сервисом и агентом: как нижестоящий сервис проверяет, что агент авторизован для вызова этого сервиса. Ни один из них не рассматривает доверие между пользователем и оператором.
Цепочка делегирования в современных агентных системах:``` User â Operator â Agent â Services
Пользователь отдаёт инструкции оператору. Оператор отдаёт инструкции агенту. Но в момент делегирования не существует криптографической записи исходного намерения пользователя. Оператор становится доверенной третьей стороной с бесконтрольными полномочиями расширять, искажать или опускать инструкции пользователя до того, как они дойдут до агента.
Последствия:
- Пользователи не могут доказать, что они авторизовали.
- Регуляторы не имеют аудиторского следа.
- Суды не имеют цепочки доказательств.
- Агенты не могут отличить легитимные инструкции оператора от скомпрометированных или вредоносных.
AuthProof заполняет этот пробел.
---
## The Core Primitive: Delegation Receipt
**Delegation Receipt** — это подписанный объект авторизации, закреплённый в децентрализованном журнале с возможностью только добавления записей до того, как начнутся какие-либо действия агента. Он содержит четыре обязательных поля:
### Scope
Явный белый список разрешённых операций. Всё, что не перечислено, запрещено по умолчанию. Выражено в структурированном формате — не на естественном языке. Классы операций:
| Class | Description |
|---|---|
| `reads` | Доступ на чтение к указанным ресурсам |
| `writes` | Доступ на запись к указанным ресурсам |
| `deletes` | Удаление указанных ресурсов |
| `executes` | Выполнение конкретной программы, на которую ссылается её **static capability signature hash** |
`executes` — самый опасный класс. Он должен ссылаться на криптографический хэш статического графа возможностей (static capability DAG) программы Safescript — а не на имя, URI или описание. Несовпадение хэша означает отсутствие выполнения.
### Boundaries
Явные запреты, которые не могут быть переопределены инструкциями оператора ни при каких обстоятельствах. Определённые пользователем жёсткие ограничения, сохраняющиеся после любых последующих инструкций оператора.
### Time Window
Период действия авторизации. **Метка времени журнала (log timestamp)** является оракулом времени — не клиентские часы. Клиентские часы явно исключены из проверки времени.
### Operator Instruction Hash
Криптографический хэш заявленных инструкций оператора на момент делегирования. Если оператор впоследствии отдаст агенту другие инструкции, расхождение будет обнаружено в журнале без каких-либо дополнительных предположений о доверии.
Пользователь подписывает этот объект своим закрытым ключом через **WebAuthn/FIDO2 с использованием защищённого анклава устройства**. Подпись публикуется в журнал до любых действий агента. Каждое последующее действие агента ссылается на хэш подтверждения (receipt hash). Действия за пределами области действия (scope) криптографически недействительны.
---
## Trust Stack Architecture
Три протокольных уровня устраняют трёх доверенных третьих сторон:
### Layer 1 — Signed Capability Manifest *(устраняет доверие к реестру)*
В текущей экосистеме MCP нет криптографического подтверждения того, что описания сервера инструментов соответствуют тому, что он на самом деле делает. Оператор может предоставить произвольную схему.
Исправление: серверы инструментов публикуют **криптографически подписанный манифест возможностей (signed capability manifest)** до того, как произойдёт какая-либо авторизация пользователя. Поле `scope` объекта Delegation Receipt ссылается на **хэш этого манифеста** — а не на схему, которую сообщил сам оператор. Расхождение между поведением сервера и манифестом обнаруживается на уровне журнала.
### Layer 2 — Delegation Receipt *(устраняет доверие к оператору)*
Исходное намерение пользователя неизменно записывается до того, как инструкции оператора достигнут агента. Отклонение оператора доказуемо.
### Layer 3 — Safescript Execution *(устраняет доверие к коду)*
[Safescript](https://github.com/safescript) — это открытый язык с песочницей для выполнения агентов ИИ. Его статическая структура DAG означает, что полная подпись возможностей (capability signature) каждой программы может быть вычислена до её запуска — никакой динамической диспетчеризации, никакого расширения возможностей во время выполнения.
Класс области `executes` ссылается на конкретный хэш подписи возможностей Safescript. Если программа, предоставленная оператором, не соответствует зафиксированному хэшу, выполнение блокируется. Агент не может быть заменён другой программой после делегирования.
---
## Quick Start```js
import { AuthProof, Scope, KeyCustody } from 'authproof-sdk';
// Initialize with hardware-backed key custody (recommended)
const authproof = new AuthProof({
custody: KeyCustody.HARDWARE, // WebAuthn/FIDO2 via device secure enclave
log: 'https://log.authproof.dev',
});
// Define permitted operations â explicit allowlist, deny-by-default
const scope = new Scope()
.allow('reads', ['resource://calendar/events', 'resource://email/inbox'])
.allow('writes', ['resource://calendar/events'])
.deny('deletes', '*')
.execute('sha256:a3f1c9d8...', { program: 'scheduler-v1.sg' }); // Safescript hash
// Hard limits that survive any operator instruction
const boundaries = {
never: ['external-network', 'credential-store', 'payment-methods'],
};
// Issue the Delegation Receipt â anchored to log before any agent action
const receipt = await authproof.delegate({
scope,
boundaries,
window: { duration: '8h' }, // validated against log timestamp
operatorInstructions: instructionText, // hashed and committed
});
// receipt.id â unique receipt identifier
// receipt.hash â reference in every agent action
// receipt.log â append-only log anchor
// Agent-side: validate an action against the receipt
const check = await authproof.validate({
receiptHash: receipt.hash,
action: { class: 'writes', resource: 'resource://calendar/events' },
});
if (!check.authorized) {
// Out-of-scope action: surface a micro-receipt request to the user
const microReceipt = await authproof.requestMicroReceipt({
action: check.requestedAction,
parent: receipt.hash,
});
}
Для вызовов инструментов, не охваченных исходной делегационной квитанцией, агент не может действовать молча. Протокол предписывает:
Неизвестные действия требуют явной новой авторизации пользователя. Разрешение зависимостей следует тому же правилу — зависимости проверяются по хешу манифеста зависимостей, зафиксированному во время делегирования. Неожиданные зависимости являются нарушением области.
Каждое событие делегирования имеет уникальный идентификатор квитанции. Параллельные агенты ссылаются на свой собственный хеш квитанции. Они различимы по квитанции, а не по идентичности агента.
Аппаратное хранение является рекомендуемым по умолчанию. Закрытый ключ никогда не покидает защищённый анклав; подписание защищается биометрическими данными устройства или PIN-кодом.
Делегационная квитанция определяет, что уполномочен делать ИИ-агент. Журнал действий записывает, что он фактически сделал — и делает любое отклонение мгновенно проверяемым.
Каждое действие, выполняемое агентом, создаёт подписанную запись с меткой времени, связанную с активной квитанцией. Записи образуют цепочку, устойчивую к несанкционированным изменениям: каждая запись содержит SHA-256 хеш предыдущей, так что любая ретроактивная модификация обнаруживается без доверенной третьей стороны. Метод diff() является примитивом аудита — он сопоставляет авторизованную область квитанции с каждым зарегистрированным действием и возвращает любые отклонения.```js
import AuthProof, { ActionLog } from 'authproof-sdk';
// 1. Issue a delegation receipt as normal const { privateKey, publicJwk } = await AuthProof.generateKey();
const { receipt, receiptId } = await AuthProof.create({ scope: 'Search the web for competitor pricing. Read calendar events.', boundaries: 'Do not send emails. Do not make purchases.', instructions: 'Cite sources. Keep under 500 words.', ttlHours: 4, privateKey, publicJwk, });
// 2. Initialize the action log with the agent's signing key const log = new ActionLog(); await log.init({ privateKey, publicJwk });
// Register the receipt so diff() knows what was authorized log.registerReceipt(receiptId, receipt);
// 3. Record each action the agent takes const e1 = await log.record(receiptId, { operation: 'Search competitor pricing', resource: 'web/search', parameters: { query: 'rival.com pricing 2024' }, });
const e2 = await log.record(receiptId, { operation: 'Read calendar events', resource: 'calendar/events', parameters: { range: 'this_week' }, });
// 4. Verify an individual entry (signature + chain integrity) const check = await log.verify(e1.entryId); // { valid: true, reason: 'Signature and chain integrity verified' }
// 5. Diff: authorized scope vs. everything that was done const report = log.diff(receiptId); // { // clean: true, // totalEntries: 2, // compliant: [{ entry: {...}, reason: '"Search competitor pricing" matches authorized scope' }, ...], // violations: [], // }
// A scope violation surfaces immediately await log.record(receiptId, { operation: 'Send email', resource: 'email/outbox' }); const auditReport = log.diff(receiptId); // auditReport.violations[0].reason â // '"Send email" outside authorized scope (0% scope match, 92% boundary overlap)'
### API журнала действий
| Метод | Описание |
|---|---|
| `new ActionLog()` | Создать новый экземпляр журнала. Состояние хранится в памяти. |
| `log.init({ privateKey, publicJwk })` | Инициализация с ECDSA P-256 ключом агента. Требуется перед `record()`. |
| `log.registerReceipt(receiptHash, receipt)` | Зарегистрировать чек для сравнения областей. Требуется перед `diff()`. |
| `log.record(receiptHash, action)` | Добавить подписанную, цепочечно-связанную запись. Возвращает запечатанную запись. |
| `log.verify(entryId)` | Проверить подпись одной записи и её позицию в цепочке. Возвращает `{ valid, reason }`. |
| `log.getEntries(receiptHash)` | Все записи для чека в хронологическом порядке. |
| `log.diff(receiptHash)` | Сравнить все записи с областью чека. Возвращает `{ compliant, violations, clean }`. |
### Предупреждение о production
Метки времени в v1 используют системные часы клиента. Для соответствия требованиям или юридических контекстов, где метки времени должны быть независимо проверяемыми, замените их на доверенный центр меток времени RFC 3161 перед развёртыванием в production.
### Важно
Всегда определяйте область с помощью явных массивов `allowedActions`. Текстовое сопоставление области доступно только для разработки и не подходит для production или контекстов, требующих соответствия.
---
## Конфиденциальное развертывание
Запускайте агентов AuthProof внутри аппаратно-аттестованных доверенных сред выполнения (TEE). Класс `ConfidentialRuntime` привязывает чеки делегирования к измерениям анклава, так что любая подмена весов модели, кода верификатора или платформы обнаруживается до выполнения.
### Требования к оборудованию
- **Intel TDX** â Intel Ice Lake Xeon или новее (4-го поколения Xeon Scalable). Azure серии DCdsv3, GCP C3 Confidential VMs.
- **AMD SEV-SNP** â AMD EPYC 3-го поколения (Milan) или новее. Azure серии DCasv5, AWS m6a с Nitro Enclaves.
### Создание чека с привязкой измерений TEE```javascript
import { AuthProofClient } from 'authproof-sdk';
const client = new AuthProofClient();
const { receipt } = await client.delegate({
scope: 'Summarize calendar events',
operatorInstructions: 'Stay within scope.',
expiresIn: '2h',
privateKey,
publicJwk,
teeConfig: {
platform: 'intel-tdx',
verifierHash: verifierCodeHash, // SHA-256 of your verifier binary
modelHash: modelWeightsHash, // SHA-256 of model weights
},
});
// receipt.teeMeasurement.expectedMrenclave is now bound to the receipt
import { ConfidentialRuntime } from 'authproof-sdk';
// Generate deployment configuration const config = ConfidentialRuntime.azureTDXConfig({ receiptHash, verifierHash, modelHash, region: 'eastus', }); // config.vmSize === 'Standard_DC4ds_v3' // config.attestationEndpoint === 'https://sharedeus.eus.attest.azure.net' // config.receiptBinding binds the receipt to the VM measurement
// At runtime inside the VM: const runtime = new ConfidentialRuntime({ platform: 'intel-tdx', verifier, actionLog, }); const result = await runtime.launch({ receiptHash, agentFn, operatorInstructions, verifierHash, modelHash, teeMeasurement: receipt.teeMeasurement, // mismatch blocks execution });
Требования к SKU Azure: `Standard_DC4ds_v3` или больше из серии DCdsv3-series. Включите шифрование дисков конфиденциальной ОС. Используйте общую конечную точку Microsoft Azure Attestation (MAA) для проверки котировок.
### Развертывание на AWS Nitro Enclaves```javascript
const config = ConfidentialRuntime.awsNitroConfig({
receiptHash,
verifierHash,
modelHash,
region: 'us-east-1',
});
// config.instanceType === 'c6a.xlarge'
// config.enclaveOptions.enabled === true
// config.pcr0 is the combined receipt+verifier+model measurement
AWS requirements: c6a.xlarge or larger with --enclave-options Enabled. Use nitro-cli to build and run the enclave image. PCR0 in the attestation document must match config.pcr0 for the receipt binding to be valid.
const manifest = ConfidentialRuntime.kubernetesConfig({ receiptHash, platform: 'intel-tdx', namespace: 'production', }); // manifest is a full K8s List containing: // - Pod with TDX node selector and attestation sidecar // - ServiceAccount with minimal RBAC // - ConfigMap with receipt binding
Apply with `kubectl apply -f` after serializing to YAML. The node selector `intel.feature.node.kubernetes.io/tdx: "true"` requires the Intel Device Plugin for Kubernetes.
### eBPF kernel module â help wanted
The TEE enforcement layer is complete through the userspace side (`ConfidentialRuntime`, `TokenPreparer`). The final enforcement step â validating the signed capability token on every syscall via an eBPF LSM hook â requires a kernel module that is open for contribution.
Engineers with eBPF LSM experience (Isovalent, Red Canary, or similar) are especially welcome. Open an issue or PR at https://github.com/Commonguy25/authproof-sdk/issues
---
## Примеры
Two runnable examples live in the `examples/` directory.
**[`examples/langchain-example.js`](https://github.com/commonguy25/authproof-sdk/blob/HEAD/examples/langchain-example.js)** â Shows the full LangChain integration path: generate a key pair, issue a delegation receipt, initialize `PreExecutionVerifier`, and wrap any agent with `authproofMiddleware` so every `invoke()` call is gated before the agent runtime gets control. Includes a mock agent you can run immediately and the exact code pattern for a real `AgentExecutor`. Run with `npm run example:langchain`.
**[`examples/webauthn-example.html`](https://github.com/commonguy25/authproof-sdk/blob/HEAD/examples/webauthn-example.html)** â A self-contained three-card browser demo of the full delegation flow. Card 1 lets you define scope, boundaries, and operator instructions, then signs a receipt with a local key (swap in `navigator.credentials` for real WebAuthn). Card 2 displays the receipt ID, expiry, system prompt, and raw JSON. Card 3 lets you type any proposed action and verify it against the receipt in real time, showing each check result. Open directly in a browser â no build step required.
---
## Установка```bash
npm install authproof-sdk
WHITEPAPER.md| Модель | Описание | Рекомендуется |
|---|
| Аппаратное | WebAuthn/FIDO2 через защищённый анклав устройства. Закрытый ключ никогда не покидает оборудование. | Да — по умолчанию |
| Делегированное | Доверенный менеджер ключей хранит ключ от имени пользователя. | Среды без поддержки FIDO2 |
| Самоличное хранение | Пользователь сам хранит и управляет своим закрытым ключом. | Опытные пользователи, изолированные рабочие процессы |