Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

ЛентыКонтактыКонфиденциальность© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
authproof-sdk — Криптографически подписанные квитанции делегирования для AI агентов. Четко определите, что AI может и не может делать — подписанные, проверяемые, защищенные от подделки. | Kitploit
Инструменты/GitHubGitHub/commonguy25/authproof-sdk
Аутентификация и авторизацияКриптографияУправление идентификацией и доступом (IAM)Безопасность Цепочки ПоставокБезопасность APIБезопасность ИИ
GitHubcommonguy25/authproof-sdk

authproof-sdk

Криптографически подписанные квитанции делегирования для AI агентов. Четко определите, что AI может и не может делать — подписанные, проверяемые, защищенные от подделки.

Репозиторий
62812 дней назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться
Сайт

AuthProof SDK

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 перед выполнением обёрнутого кода.

Скачать инструмент