Delegated Treasury

When an enterprise delegates spending authority to an AI agent, the constraints are typically enforced as soft prompts: "don't spend more than $500." This is a suggestion, not a guarantee. Prompt injection, context overflow, or adversarial negotiation can override it.

Platform guardrails enforce limits centrally — but they're opaque and not portable. A seller has no way to independently verify the buyer's authority without trusting the platform.

Without cryptographic proof that the agent's spend authority is real, current, and bounded, sellers must either trust the agent's claim or reject the transaction. Both are suboptimal.

Authorized ≠ attested. That is the structural gap Lemma closes.

Before Lemma — How the Incident Unfolds

Context

A mid-size enterprise deploys an AI purchasing agent with a monthly budget of $10,000 for SaaS subscriptions. The policy: nothing over $500 per transaction without manager approval.

Incident Timeline

Phase	What Happens	Why It's Undetectable
Setup	Enterprise configures agent with budget and scope via platform dashboard	Constraints live as platform rules, not cryptographic proofs
Normal operation	Agent makes routine SaaS purchases within scope	No verification from seller side — they trust the platform
Scope creep	Agent negotiates a $3,200 annual subscription, justified as "within monthly average"	Soft constraints are interpretive; agent rationalizes the spend
Breach	Agent purchases a $12,000 enterprise license, exceeding monthly and per-transaction limits	No independent proof of authority required by seller
Discovery	Finance team flags the charge 2 weeks later in monthly reconciliation	Post-hoc detection only — money already spent
Dispute	Enterprise disputes the charge; seller says "your agent authorized it"	No cryptographic evidence of what authority was delegated

Root Cause

• Constraints are soft — encoded as prompts or platform rules, not as cryptographic attestations
• Sellers cannot verify the buyer's authority independently
• No on-chain record of what was delegated, to whom, for how long
• Revocation is reactive — the agent's credentials are revoked after the breach, not before

After Lemma — How the Same Scenario Plays Out

What Changes at Deployment

• The enterprise issues an on-chain spend-control attestation: principal identity, $10K monthly ceiling, SaaS-only scope, $500 per-transaction limit, 30-day validity, revocation endpoint.
• Every transaction the agent initiates carries this attestation.
• Sellers verify the attestation before accepting payment.

Incident Timeline (With Lemma)

Phase	What Happens	How Lemma Changes It
Setup	Enterprise creates on-chain attestation with exact constraints	Constraints are cryptographic, not interpretive
Normal operation	Agent makes purchases; sellers verify attestation	Seller-side verification is independent
Attempted breach	Agent tries to purchase $12,000 license	Attestation says max $500/tx — seller rejects
No breach possible	Transaction never completes	The proof prevents the commit, not just detects it
Audit trail	Every transaction carries delegation proof	Finance gets verifiable evidence, not just logs

Design Principle

The delegation is the proof. The attestation is the contract. The on-chain anchor is the guarantee.

┌─────────────────────────────────────────────────────────────┐
│                     ENTERPRISE (Principal)                   │
│                                                              │
│  ┌──────────────────┐        ┌──────────────────────────┐   │
│  │  Delegation Policy│───────▶│  Lemma Attestation Issuer │   │
│  │  - $10K/mo ceiling│        │  - ZK proof of authority  │   │
│  │  - SaaS only      │        │  - On-chain anchor        │   │
│  │  - $500/tx max    │        │  - Revocation endpoint    │   │
│  └──────────────────┘        └────────────┬─────────────┘   │
└────────────────────────────────────────────┼─────────────────┘
                                             │ attestation
                                             ▼
┌─────────────────────────────────────────────────────────────┐
│                     AGENT (Delegate)                          │
│                                                              │
│  ┌──────────────────┐        ┌──────────────────────────┐   │
│  │  Purchase Request │───────▶│  Attestation Carrier      │   │
│  │  - $299 SaaS sub  │        │  - Proof attached to tx   │   │
│  │  - Within scope   │        │  - Validity checkable     │   │
│  └──────────────────┘        └────────────┬─────────────┘   │
└────────────────────────────────────────────┼─────────────────┘
                                             │ payment + proof
                                             ▼
┌─────────────────────────────────────────────────────────────┐
│                     SELLER (Counterparty)                     │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Lemma Verification                                   │   │
│  │  1. Is the attestation signed by the claimed issuer?  │   │
│  │  2. Is the spend within the stated ceiling?           │   │
│  │  3. Is the category within the stated scope?          │   │
│  │  4. Is the attestation still valid (not revoked)?     │   │
│  │  ✓ All checks pass → accept payment                   │   │
│  │  ✗ Any check fails → reject transaction               │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Component Flow

1. Issuance: The enterprise's delegation policy is encoded as a Lemma attestation. Poseidon hash commits the constraints on-chain; BBS+ signature proves the issuer's authority.
2. Carriage: The agent carries the attestation with each transaction. The proof does not reveal the full policy — only that the specific transaction falls within authorized bounds.
3. Verification: The seller checks the attestation independently. No trust in the agent or platform is required — only in the issuing organization's signature.
4. Revocation: If the enterprise revokes the delegation, the on-chain revocation status updates immediately. Sellers check revocation in real-time.

When a seller accepts a payment from a delegated agent with Lemma, the following facts are cryptographically proven — not claimed:

• Issuing principal (org / department) — Who delegated this authority. Not "the agent says it's from Acme Corp" — a ZK proof attests that Acme Corp's signing key authorized this delegation.
• Spend ceiling and scope — The exact budget and category constraints. "Up to $10K/month, SaaS only" is encoded in the attestation, not in a prompt the agent can ignore.
• Time-bounded validity — When the delegation expires. The attestation carries a validity window; expired attestations fail verification automatically.
• Revocation status — Whether the delegation has been revoked. Sellers check on-chain revocation status in real-time. A revoked attestation is rejected before the transaction completes.

X402 Commerce

Pillar: P3 Agent Trust Chain

When delegated agents transact on the x402 rail, sellers need to verify not just the buyer's identity — but the buyer's authority. Delegated Treasury attestations provide that proof at the payment layer.

→ X402 Commerce

Multi-Agent Workflows

Pillar: P3 Agent Trust Chain

When an orchestrator delegates purchasing authority to a sub-agent, the delegation chain must be traceable. Delegated Treasury attestations prove who authorized the spend and what scope was delegated.

→ Multi-Agent Workflows