Bounded Authority

Without Veridex, giving software the ability to spend means handing it a key with no limits. With Veridex, you hand it a bounded delegation — a contract that says exactly what it can do.

// Without Veridex: unlimited authority
wallet.sendTransaction({ to, value });          // Could drain everything
 
// With Veridex: bounded authority
sessions.createSession({
  permissions: ['transfer'],     // only transfers — no contract calls, no approvals
  chainScopes: [8453],           // only Base — not Ethereum, not Solana
  maxValue: parseEther('0.05'),  // hard cap per transaction
  dailyLimit: parseEther('1'),   // hard cap per 24h
  duration: 86400,               // expires in 24h
  label: 'payment-agent-001',    // human-readable purpose
});

A compromised session key in the second example can spend at most dailyLimit. A compromised wallet in the first can spend everything you own. The difference between those two outcomes is what Veridex calls bounded authority.

Below is the layered authority model that makes this work end-to-end.

The Four Layers

1. API Keys — Application Identity

Every application starts by registering and receiving an API key. This key:

• Identifies the application to the platform
• Scopes all downstream sessions and activity to one namespace
• Supports rotation with one-time reveal
• Creates an audit trail for every action taken under the key

2. Session Keys — Delegated Authority

Session keys are the primary execution primitive. A session key delegates bounded authority from a passkey-authenticated identity to software:

• Permissions: Which actions are allowed (read, transfer, swap, approve)
• Chain scopes: Which chains the session can operate on
• Spending limits: Maximum amount per transaction and per day
• Time bounds: Explicit expiration
• Labels: Human-readable purpose for each session

A single identity can hold multiple concurrent sessions. This supports:

• One long-lived developer session for a web app
• Multiple task-specific agent sessions with different limits
• Operator-driven rotation and revocation of risky sessions

3. Governed Execution — Policy Enforcement

Every action executed through a session key passes through policy evaluation:

• Spending limits: Per-transaction and daily caps
• Chain restrictions: Allowlisted chains only
• Token whitelists: Only approved assets
• Approval thresholds: Actions above a threshold require human approval
• Counterparty rules: Only approved recipients

If a policy blocks an action, the trace records the reason and the session stays active for future actions that comply.

4. Audit Evidence — Verifiable Traces

Every execution produces a trace record containing:

• The agent's reasoning (LLM output or intent)
• The proposed action
• Policy verdicts for each rule evaluated
• Signatures
• Transaction hash (if executed)
• Evidence bundle exportable as JSON or CSV

Comparison to Traditional Models

Next Steps

• Multi-Session Management — Create and manage multiple sessions
• Session Studio — Visual session management
• Governance — Approval and policy workflows