
Криптографически подписанные квитанции делегирования для AI агентов. Четко определите, что AI может и не может делать — подписанные, проверяемые, защищенные от подделки.
AuthProof — это слой аудита и атрибуции для AI-агентов. Он позволяет доказать, что авторизовал пользователь до того, как агент выполнил действие, и фиксирует, что агент фактически сделал в рамках этой авторизации.
Механизм прост. Пользователь подписывает делегационную квитанцию своим приватным ключом. Квитанция содержит область действия, границы, инструкции оператора (в виде хеша) и временное окно. Верификатор предварительного выполнения проверяет каждое предлагаемое действие на соответствие квитанции, а журнал действий, доступный только для добавления, фиксирует, что было выполнено. Результат — доказательства: что было авторизовано, сопоставленное с тем, что произошло.
Это не средство защиты от злонамеренного оператора. Верификатор работает в том же процессе, что и агент, и недобросовестный оператор может просто не вызывать его. Никакое криптографическое свойство не может это исправить изнутри той же среды выполнения. AuthProof доказывает авторизацию для развёртываний, которые используют этот шлюз, и даёт аудиторам, регуляторам и пользователям запись, которую они могут проверить постфактум.
Что отличает его:
Пользователь является подписывающей стороной. Объект авторизации подписывается приватным ключом пользователя, а не записывается в управляемую оператором политику. Подписанная область действия и хеш программы в квитанции всегда имеют приоритет над метаданными журнала оператора. Если метаданные оператора конфликтуют с подписанной квитанцией, шлюз отклоняет действие вместо того, чтобы следовать метаданным.
Двухфазная фиксация состояния модели. Модель измеряется в момент авторизации и повторно измеряется перед выполнением. Эти измерения вычисляются программно и самоподтверждаются, они не имеют аппаратного корня доверия. Это свидетельство несанкционированного изменения для добросовестных развёртываний, а не защита от враждебного хоста.
Обновление от провайдера и злонамеренная подмена различаются. Изменения состояния модели классифицируются на легитимные обновления провайдера (PROVIDER_UPDATE_REQUIRES_REAUTH) и несанкционированные подмены (MALICIOUS_MODEL_SUBSTITUTION). Каждый случай порождает машиночитаемый код причины отказа, указывающий, какие компоненты изменились.
Шлюз, который запускается до выполнения любого действия агента.
PreExecutionVerifier.check() проверяет каждое предлагаемое действие на соответствие подписанной делегационной квитанции. Направляйте каждое действие через него в процессе вашего агента, до выполнения действия. Верификатор подписывает свои собственные решения о разрешении/отказе в журнал аудита, так что каждый результат становится частью записи.
Одна жёсткая истина, которую нужно учитывать при проектировании: верификатор работает в том же процессе. Он проверяет доказательство; он не может остановить оператора, который отказывается его вызывать. Используйте его там, где вам нужны доказательства, а не там, где вам нужно принуждение против оператора, запускающего код.
Большая часть авторизации агентов сегодня — это слово оператора: политика, написанная оператором, исполняемая кодом, который контролирует оператор. Когда что-то идёт не так, нет записи о том, что пользователь фактически авторизовал, есть только реконструкция оператора. AuthProof меняет это. Подписанная квитанция пользователя предшествует выполнению, а журнал действий фиксирует, что было выполнено в её рамках. Вопрос «авторизовал ли пользователь это?» становится проверяемым, а не спорным.
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 thirteen checks pass
| # | Проверка | Блокирует, когда |
|---|---|---|
| 1 | Подпись квитанции | Подпись ECDSA P-256 недействительна или квитанция подделана |
| 2 | Отзыв | Квитанция была отозвана через RevocationRegistry (каскад: отозванный предок запрещает своих потомков) |
| 3 | Временное окно | Квитанция истекла или ещё не действительна (оракул временных меток журнала, а не часы клиента) |
| 4 | Область действия | Действие отсутствует в ScopeSchema.allowedActions; без структурированной схемы сопоставление по ключевым словам носит рекомендательный характер и никогда не блокирует |
| 5 | Инструкции оператора | Предоставленные инструкции не совпадают с хешем, зафиксированным в квитанции при выпуске; пропускается с предупреждением, когда вызывающая сторона их опускает |
| 6 | Хеш программы | Предоставленный programHash не совпадает с зафиксированным хешем executes (опционально) |
| 7 | Риск сессии | Превышены пороги доверия/риска (опционально) |
| 8 | Целостность схемы инструмента | toolSchemaHash не совпадает с квитанцией (опционально) |
| 9 | Состояние модели | Обнаружен дрейф модели (опционально; измерение, вычисляемое программно и подтверждаемое самостоятельно) |
| 10 | Привязка хеша вывода инструмента | Хеш вывода не совпадает с квитанцией (опционально) |
| 11 | Происхождение инструкции | Источник инструкции отсутствует в trustedSources квитанции (опционально) |
| 14 | Содержание родительской области | Подквитанция выходит за пределы области родителя (только для подквитанций); отзыв любого предка запрещает дочернюю квитанцию во время проверки |
| 15 | Дрейф состояния полномочий | authorityStateCommitment изменился с момента выпуска (опционально) |
Слоты 12 и 13 так и не были реализованы; пробел в нумерации исторический. Шлюз останавливается на первой неудачной проверке. Расход одноразового использования выполняется последним, после прохождения всех проверок, поэтому слот расхода никогда не сжигается на квитанции, которая была бы отклонена по другой причине.
Каждый результат проверки, успешный или неудачный, автоматически записывается в неизменяемый ActionLog, подписанный собственным ключом верификатора.
Подписанные данные имеют приоритет. Область действия и хеш программы подписанной квитанции всегда имеют приоритет над метаданными журнала оператора. Если неподписанные метаданные DelegationLog противоречат подписанной квитанции, шлюз отклоняет действие (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). Метаданные журнала являются запасным вариантом только тогда, когда квитанция не содержит структурированной области действия или подписанного значения executes.
Управляемое делегирование управляется наблюдением. ScopeDiscovery.guided() и AuthProofClient.delegateGuided() выполняют observe → generateScope → approve → finalize за один вызов, и полная наблюдаемая черновая область действия автоматически одобряется без участия человека. Для подлинного момента человеческой авторизации передайте хук reviewDraft (одобрить, изменить или отклонить черновик до выпуска) или выполните шаги по отдельности с явным approve().
Готовые обёртки для распространённых фреймворков. Каждая обёртка пропускает каждый вызов через PreExecutionVerifier перед выполнением обёрнутого кода.