v1.1.0 — Live on npm

Close the operator trust gap
in AI agent authorization

AuthProof commits user intent, scope, and operator instruction hashes to a decentralized append-only log before any agent action executes. Operators cannot exceed the signed boundary. Any deviation is cryptographically detectable.

⚡ Try Live Demo View on GitHub →
ECDSA P-256
Signing Algorithm
100%
Browser-native crypto
Open source
MIT License
agent.js 
import { AuthProofClient, Scope, KeyCustody } from 'authproof-sdk';

// User delegates to agent — scope is signed & committed
const client = new AuthProofClient({ custody: KeyCustody.HARDWARE });

const receipt = await client.delegate({
  scope: new Scope({
    allow: ['read:calendar', 'send:email'],
    deny:  ['delete:*', 'payment:*']
  }),
  operatorInstructions: 'Schedule meetings only',
  expiresIn: '2h'
});

// Before any action — verify against the signed receipt
const ok = await client.verify(receipt.hash, action);
// Any deviation is detectable before execution
Why AuthProof

The trust gap IETF frameworks leave open

Current AI authorization standards delegate trust to the operator. AuthProof removes the operator as a trusted party entirely.

⚠️
The Problem

  • Operators can silently expand agent capabilities
  • No cryptographic record of what the user authorized
  • Agent actions can't be audited against original intent
  • Operator instructions can contradict user scope

🔏
The Primitive

A Delegation Receipt is a signed Authorization Object committed to an append-only log before any action. It contains:

  • User intent hash
  • Explicit allow/deny scope
  • Operator instruction hash
  • ECDSA P-256 signature + timestamp

🏛️
The Trust Model

Operators are removed as trusted third parties. The signed receipt is the only authority. Any deviation between operator instructions and the committed hash is detectable by anyone with the public key.

  • User holds the private key
  • Log is append-only and auditable
  • No trust in the operator required
Protocol

How it works

Six deterministic steps from user intent to verifiable delegation.

1

User specifies intent

The user defines an explicit scope (allow list + deny list), time window, and operator instructions. Nothing is assumed or inferred.

2

Scope is structured

Allow and deny lists are parsed into a normalized canonical form. Wildcards (e.g. delete:*) are resolved at verification time, not delegation time.

3

Operator instructions are hashed

SHA-256 of the operator's stated instructions is embedded in the receipt. Any subsequent modification produces a detectable mismatch.

4

Payload is signed (ECDSA P-256)

The full payload — scope, hashes, timestamps, receipt ID — is signed with the user's private key via the Web Crypto API. The key never leaves the hardware enclave.

5

Receipt committed to append-only log

The signed receipt and its hash are committed before any agent action executes. The log is immutable — entries can be appended but never modified.

6

Every action verified against receipt

Before execution, each agent action is checked against the signed scope. If the action falls outside the allow list or matches the deny list, it is blocked — cryptographically, not by policy.