The Enterprise Fear: Rogue Agents
AI agents are moving from research to production. They're gaining authority to negotiate contracts, execute trades, access patient records, and manage supply chains. But what happens when an agent goes wrong?
Whether through prompt-injection attacks, hallucinations, or misconfigured permissions, the blast radius of a compromised agent is unlimited without cryptographically enforced boundaries. An agent with an API key to your payment processor doesn't know it's only supposed to charge up to $5,000 for airline bookings — it has the same authority as your entire backend.
The nightmare scenario: your procurement agent gets prompt-injected and starts booking $50,000 first-class tickets to Fiji for scammers. Your clinical agent hallucinates and accesses records outside its approved study. Your trading agent misinterprets market conditions and exceeds position limits. The agent doesn't know its boundaries because they were never cryptographically defined.
Why Current Systems Can't Contain Agents
API Keys
Binary access: you have the key or you don't. No concept of "authorized up to $5,000 for airline bookings until Friday." An agent with a Stripe API key can charge any amount to any card.
OAuth 2.0 / Scoped Tokens
Designed for human consent flows — assumes a person is present to authorize each scope. Still binary per scope. Can't express compound constraints like amount + action + time + vendor.
Policy Engines (OPA, Cedar)
Rules are configuration, not cryptographic commitments. Vulnerable to misconfiguration, drift, and insider threats. Agent can't prove its authority to third parties.
Sandboxed Agents
Limit which tools an agent can call, but not the authority it carries when calling them. A sandboxed agent with payment API access still has unlimited spending power.
| Capability | API Keys / OAuth | Exqub Credentials |
|---|---|---|
| Spending limits | External policy layer | Signed into credential |
| Time bounds | Token expiry only | Fine-grained validity windows |
| Selective disclosure | Not supported | Per-attribute Merkle proofs |
| Sub-delegation | New tokens from auth server | Agent mints sub-credentials |
| Revocation | Database lookup per request | Cryptographic SMT proof |
| Post-quantum | No (RSA/ECDSA) | Yes (ML-DSA-65) |
How Exqub Works
Four roles, one protocol. Authority becomes a signed object.
Issuer
The enterprise or authority that creates and signs credentials with their ML-DSA-65 key. Controls what agents are authorized to do.
Holder (Agent)
The AI agent that receives credentials, stores them in its wallet, and presents them to services when making requests.
Verifier
Any service that receives presentations from agents. Checks signatures, revocation status, and enforces the credential scope.
Revocation Registry
Sparse Merkle Tree maintained by the issuer. Enables instant revocation with compact cryptographic proofs.
Concrete Procurement Agent Example
{
subject: "procurement-agent-7f3a"
actions: ["book_flight", "reserve_hotel"]
spend_cap: $5,000
vendor: ["airlines", "hotels"]
expires: "2026-04-01T00:00:00Z"
signed_by: enterprise ML-DSA-65 key
}Key insight: These attributes are stored in a Merkle tree, not plaintext. The agent can selectively disclose only what's needed — revealing spend_cap and actions to an airline API without exposing vendor scope or internal identity.
Authority becomes a signed object.
Not configuration. Not policy. A cryptographic commitment.
What This Enables
Four capabilities that transform how enterprises deploy autonomous agents
Cryptographic Spending Caps
Spending limits are signed into the credential itself. The verifier enforces them in <50ms without calling back to a policy server.
→ REJECT (cryptographically enforced)
Selective Disclosure
Agents prove "authorized for this transaction" without revealing their principal identity or other permissions. Merkle proofs ensure privacy.
// WITHOUT revealing:
// - internal subject ID
// - vendor restrictions
// - other capabilities
Ephemeral Sub-Delegation
Agents can spawn sub-agents with time-limited, capability-capped sub-credentials. No roundtrip to auth server required.
sub_credential = {
parent: self.credential,
expires: "15 minutes",
spend_cap: $400
}
Instant Revocation
Compromised agents revoked in milliseconds using compact cryptographic proofs. No CRL downloads, no OCSP latency.
1M credentials → ~8KB proof
Verification: ~300µs native
Propagation: CDN-speed
Sub-Delegation in Action
The travel orchestrator autonomously mints short-lived sub-credentials for specialized tasks. Each sub-agent operates within cryptographically enforced boundaries. If one gets compromised, the blast radius is limited to its specific scope and time window.
Credential Lifecycle
From issuance to revocation — every step cryptographically secured
Issue
Enterprise signs agent authority
Use
Agent presents to services
Delegate
Spawn sub-agents
Refresh
Extend validity
Expire
Time-based expiry
Revoke
Instant via SMT
Instant Propagation
Revocation updates propagate via CDN in milliseconds, not hours.
Cryptographic Proof
Every state change is cryptographically verifiable, creating tamper-evident audit trails.
Zero Coordination
Verifiers check revocation without contacting the issuer, enabling offline verification.
Enterprise Benefits
Deploy agents with confidence. Sleep through the night.
Blast Radius Containment
Authority is bounded by credential scope. A compromised agent can only act within its cryptographically defined limits.
Verifiable Agent Identity
Every agent action is cryptographically signed and device-bound. Know exactly which agent did what, when.
Non-Repudiation
Signed credentials create undeniable proof of authorization. Perfect for regulated industries and compliance.
Cryptographic Audit Trails
Every credential presentation is logged with cryptographic proof. Tamper-evident records for forensics and compliance.
Regulatory Compatibility
Selective disclosure aligns with HIPAA minimum-necessary and GDPR data minimization principles.
Post-Quantum Security
ML-DSA-65 signatures protect against future quantum attacks. Credentials in audit logs remain valid for decades.
Target Industries
💳 Fintech & Banking
Agents executing trades, processing loans, and managing portfolios within cryptographically provable spending limits. Every transaction has non-repudiable authorization.
🏥 Healthcare
Clinical research agents accessing patient data with selective disclosure. Prove authorization for specific cohorts without revealing other permissions. HIPAA-compliant by design.
⚖️ Legal
Contract-drafting agents proving authority scope without exposing privileged information. Maintain attorney-client privilege while enabling autonomous document processing.
📦 Supply Chain
Agent-to-agent negotiation with verifiable bonding and insurance. Carriers prove authority, shippers verify coverage, all without central coordination.
Why Post-Quantum Matters
Credentials persist in audit trails for decades. A credential signed today with ECDSA could be retroactively forged by a quantum computer in 2035, invalidating years of audit history. ML-DSA-65 signatures remain secure even against future quantum attacks.
Seeking Design Partners in Regulated Agent Platforms
We are seeking 3–5 design partners building agent platforms for regulated industries. If your agents need to prove what they are authorized to do — not just that they hold an API key — we should talk.
What We're Looking For
✓ Your Platform
- • Deploying autonomous agents in production
- • Operating in regulated industries
- • Managing complex permission hierarchies
- • Need for cryptographic audit trails
✓ Your Challenges
- • Limiting blast radius of compromised agents
- • Proving compliance to auditors
- • Managing agent-to-agent delegation
- • Instant revocation requirements
As a design partner, you'll get direct access to our engineering team, priority feature development, and help shape the protocol's evolution.
Try it live
Paste a presentation (CBOR hex) → verified instantly by real Rust (exqub-core via WASM)
🎯 Demo: Selective Disclosure Examples
Click a scenario below to see how selective disclosure works. These are demo examples to illustrate the concept - in production, credentials would be cryptographically signed by trusted issuers and would verify successfully.
Credential Verifier
Paste an encrypted credential or try an example
What's a credential?
It's like a digital ID card or certificate that's been encrypted into a long string of numbers and letters. This ensures it's tamper-proof and can only be verified by authorized systems. Think of it as a QR code but in text form - meaningless to humans but perfectly readable by computers.