XBPP: EXECUTION BOUNDARY PERMISSION PROTOCOL

ABSTRACT

1. PROBLEM STATEMENT

The current landscape of AI agent payments operates on a dangerous binary: agents either have full access to spend (via API keys, wallet private keys, or pre-authorized credit lines) or no access at all. Neither extreme works for production autonomous systems.

Full access creates unacceptable risk. An agent with an unrestricted API key can drain an account through rapid small transactions, pay inflated prices to compromised vendors, or execute transactions that violate corporate policy - all without any checkpoint.

No access defeats the purpose of autonomy. If every transaction requires human approval, the agent is merely a suggestion engine - slower and more expensive than a human doing the work directly.

The missing piece is graduated autonomy - a way for agents to operate independently within defined bounds, with clear escalation paths for edge cases. This is what xBPP provides.

2. DESIGN PRINCIPLES

3. PROTOCOL OVERVIEW

xBPP defines a standardized evaluation function:

evaluate(action, policy, state) → Verdict

The three inputs are:

• Action:What the agent wants to do - a payment request with amount, currency, target, and metadata.
• Policy:The rules governing the agent - limits, trusted recipients, rate limits, operating hours, verification requirements.
• State:The agent's current spending state - how much has been spent today, this week, this month, recent transaction history.

The output is a Verdict containing the decision (ALLOW, BLOCK, or ESCALATE), an array of reason codes explaining why, and metadata for audit trails.

4. DATA STRUCTURES

xBPP defines four core data structures. All are expressed as JSON and are designed to be serializable, hashable, and portable.

// Policy - the rules
{
  "schema": "xbpp-pay/v1.0",
  "posture": "BALANCED",
  "limits": {
    "max_single": 100,
    "max_daily": 1000,
    "require_human_above": 500
  },
  "verification": "BUILT_IN"
}

// Action - the intent
{
  "type": "xbpp-pay/transfer",
  "value": { "amount": 150, "currency": "USDC" },
  "target": { "address": "0x...", "chain": "base" }
}

// Verdict - the decision
{
  "decision": "ESCALATE",
  "reasons": ["HIGH_VALUE"],
  "confidence": 0.85,
  "metadata": { "evaluator": "xbpp-sdk/0.1.0" }
}

5. EVALUATION PIPELINE

The specification defines a 9-phase evaluation pipeline. Each phase can produce reason codes that contribute to the final verdict. Phases are ordered by priority - early phases can short-circuit the pipeline.

6. SECURITY MODEL

xBPP addresses the following threat categories with specific mitigations defined in the specification:

7. REFERENCE IMPLEMENTATION

The reference SDK (@vanar/xbpp v0.1.0-beta.1) is a TypeScript package with zero runtime dependencies. It implements the core policy engine covering:

• ▸Spending limits (per-transaction, hourly, daily)
• ▸Escalation thresholds
• ▸Recipient whitelisting and domain blocking
• ▸Rate limiting (requests per minute)
• ▸Suspicious pattern detection (rapid same-recipient transactions)
• ▸Operating hours enforcement
• ▸Currency filtering
• ▸Policy expiration
• ▸x402 payment protocol integration via fetch wrapper

8. COMPARISON

xBPP and x402 are complementary. x402 handles the payment mechanics (HTTP 402, stablecoins, settlement). xBPP handles the governance layer (should this payment happen at all?). The SDK's wrap() function demonstrates this integration directly.

9. ROADMAP