An AI procurement agent autonomously buys cloud compute for a Fortune 500 company. In 2024, this was managed by API keys and rate limits. Today, DUAL enables something far more powerful: a single governance token that embeds spending limits, counterparty whitelists, compliance checks, and audit trails—all executed in O(1) time.
The agent initiates a $5,000 cloud compute purchase. In < 1 second:
- Token checks: does the agent have authority to spend $5,000? Yes (monthly limit: $100,000, YTD spent: $87,000)
- Token checks: is the counterparty (Vendor XYZ) on the approved whitelist? Yes
- Token checks: does the purchase comply with SOX financial controls? Yes
- Token checks: is there a signed vendor agreement on file? Yes
- Transaction executes. Token state updates: YTD_spent → $92,000
- Webhook fires to audit system: "Agent 001 spent $5,000 on cloud compute"
All governance rules are in the token, not in external systems. The agent doesn't need a human approval loop. Compliance is instant and continuous.
The Agent Mandate: Governance in a Token
Agent Mandates encode authority, limits, and rules as token properties. A single mandate token can govern hundreds or thousands of transactions:
{
"token_id": "agent_mandate_procurement_001",
"agent_did": "ai_agent_procurement_v2_did",
"current_state": "ACTIVE",
// Spending limits
"spending_controls": {
"monthly_limit_cents": 10000000, // $100,000
"ytd_spent_cents": 8700000, // $87,000
"remaining_this_month": 1300000, // $13,000
"per_transaction_max_cents": 500000 // $5,000 max per tx
},
// Approved vendors
"counterparty_whitelist": [
{
"vendor_name": "AWS",
"vendor_did": "aws_integration_did",
"category_allowed": ["compute", "storage", "networking"],
"pricing_cap_per_unit": "$0.50/hour"
},
{
"vendor_name": "Google Cloud",
"vendor_did": "gcp_integration_did",
"category_allowed": ["compute", "storage"],
"pricing_cap_per_unit": "$0.45/hour"
}
],
// Compliance requirements
"compliance_checks": {
"requires_sox_compliance": true,
"requires_vendor_agreement": true,
"requires_security_review": false,
"max_data_residency_days": 3
},
// Escalation rules
"escalation_rules": {
"if_monthly_budget_exceeds_80_percent": "alert_cfo",
"if_new_vendor_requested": "require_procurement_approval",
"if_monthly_budget_exceeds_100_percent": "block_transaction"
}
}
This token is self-enforcing. When the agent attempts a transaction, the token's embedded logic validates:
Real Transaction: Complete Validation Flow
Total time: < 500ms. No human intervention. No external policy lookups. The token is the authority.
Why This Is Revolutionary: The Old Way
Previously, an AI agent buying compute would work like this:
| Step | Traditional (API Keys) | DUAL (Mandate Tokens) |
|---|---|---|
| 1. Spending Check | Query accounting database (~200ms) | Token property lookup (instant) |
| 2. Vendor Approval | Query procurement system (~300ms) | Token whitelist check (instant) |
| 3. Compliance | Call compliance API (~500ms) or wait for manual review | Token embedded rules (~10ms) |
| 4. Execute | API call to vendor (~1000ms) | API call to vendor (~1000ms) |
| 5. Audit Log | Write to audit table (async, may lag hours) | Immutable token state change (instant) |
| Total Time | ~2 seconds (or indefinite if manual review needed) | < 500ms, always |
The traditional approach has additional problems:
- Race conditions: Two agents simultaneously check budget. Both see $13,000 remaining. Both execute $8,000 purchases. Over-budget by $3,000. Audit log is inconsistent.
- Compliance drift: Accounting database says vendor XYZ is approved, but compliance database hasn't been updated in 3 days. Agent buys from XYZ without realizing they're no longer approved.
- Manual approval bottleneck: Large purchases require human sign-off. A $10,000 purchase waits 4 hours for a manager to approve. Opportunity cost: $0 earned while waiting.
- Audit trail lag: Transactions are logged asynchronously. An auditor querying the system sees data from 6 hours ago. Can't reconstruct the agent's decision-making in real-time.
DUAL solves all of this. The token IS the source of truth, IS enforced atomically, and IS audited immutably at transaction time.
Complex Rules: Recursive Mandates
Some agents need to delegate authority to sub-agents. For example, a CFO's agent might delegate procurement authority to a sub-agent for specific vendors:
{
"token_id": "agent_mandate_cfo_delegated",
"agent_did": "ai_agent_cfo_v1_did",
"delegations": [
{
"delegated_to_agent": "ai_agent_procurement_v2_did",
"authority": "SPEND_UP_TO_100000_ON_COMPUTE",
"approved_vendors": ["AWS", "GCP"],
"cannot_override_to_vendors": ["RiskyVendor_Inc"],
"expires_at": 1712730000 // Q2 2026 end
}
]
}
The CFO's mandate token can be queried to answer: "Does the procurement agent have authority to spend on AWS?" Answer: Yes, up to $100,000 total through Q2 2026. Delegation is encoded as token state, not in a separate permissions system.
Real-Time Revoking and Escalation
If an agent behaves unexpectedly (e.g., starts buying from unauthorized vendors), the mandate can be revoked instantly:
- CFO observes agent behavior: "Why is procurement_agent buying from UnknownVendor_LLC?"
- CFO updates the mandate token: state → REVOKED
- Agent attempts next transaction: token returns REVOKED status
- Transaction denied immediately
- Webhook fires to security team with details
No need to rotate API keys. No need to update three different policy servers. The token state change is atomic and global.
Comparison: API Keys vs. Mandate Tokens
API Key Rate Limiting (e.g., OpenAI)
Controls: Rate limits only (e.g., 100 requests/minute)
Spending limits: Not enforced at API level; billing audit after the fact
Vendor approval: No mechanism; must use separate policy system
Revocation: Rotate API key (breaks all clients that hold it)
DUAL Mandate Tokens
Controls: Spending, vendors, categories, pricing, compliance, escalation
Spending limits: Enforced pre-transaction; never overspend
Vendor approval: Whitelist embedded in token
Revocation: Set state → REVOKED (all agents holding token see it)
Multi-Agent Scenarios: Coordinated Procurement
Some organizations have teams of agents. A Wage Protocol token can govern shared budget allocation across multiple agents:
{
"token_id": "shared_budget_marketing_agents",
"total_monthly_budget_cents": 50000000, // $500,000
"allocated_agents": [
{
"agent_did": "ad_spend_agent_did",
"allocation_cents": 30000000, // $300,000
"spent_cents": 24500000 // $245,000
},
{
"agent_did": "content_creation_agent_did",
"allocation_cents": 20000000, // $200,000
"spent_cents": 15000000 // $150,000
}
]
}
The token maintains a shared budget pool. When ad_spend_agent spends $5,000, the token updates allocation atomically. If one agent exceeds their budget, the token blocks further spending for that agent but allows others to continue (subject to their own limits).
AML and Compliance in Real-Time
Mandate tokens can embed compliance checks that fire automatically:
// AML (Anti-Money Laundering) check embedded in token
rule "aml_screening" {
on_new_transaction {
vendor_did = get_transaction_vendor()
aml_status = query_aml_oracle(vendor_did)
if (aml_status == "SANCTIONED") {
deny "Vendor on sanctions list"
emit "COMPLIANCE_VIOLATION_AML"
}
if (aml_status == "HIGH_RISK") {
escalate_to "compliance_officer"
require_approval
}
}
}
Each transaction automatically checks: is this vendor on a sanctions list? Is there a known AML risk? The check happens before the transaction executes, not in a compliance audit 3 months later.
What's Next
We've now explored five core properties of DUAL: mutable state, embedded compliance, event-driven architecture, geofencing, and agent governance. In Part 6 (our finale), we'll step back and show how these five properties combine into a unified architecture that handles 30+ distinct tokenization patterns across completely different industries.