CUBIC □ WHITEPAPER — V1.0 · SEPTEMBER 2026
The Agent Authorization Network.
Cloudflare for agent actions. Agents never hold credentials — every tool call is interrogated against identity, intent, policy, and trust, then allowed, denied, or escalated. Allowed actions receive scoped five-minute capabilities, not keys.
ABSTRACT · INTENT → POLICY → CAPABILITY → EXECUTION → AUDIT · LIVE ON BASE SEPOLIA + HEDERA TESTNET
01 — The problem
Modern agents hold long-lived credentials for GitHub, Slack, wallets, and DeFi. Once the credential reaches the agent process, prompt injection, malicious tool output, or a compromised MCP server turns one intended action into general access. The fix is to change the unit of authorization from credential possession to action capability: instead of “here is a GitHub token, you can use GitHub,” the agent receives “agent 8472 may merge PR #421 in acme/backend, under policy X, until timestamp T” — and nothing else.
02 — What Cubic is — and is not
It is: an agent-facing authorization gateway · a capability broker · a deterministic policy layer · an intent-to-action audit system · an identity/reputation consumer · a secret-protection seam · a multi-tenant control plane · a network observability surface.
It is not: a replacement for Composio or API integrations · a secrets manager · a blockchain that executes tool calls · an LLM that decides ALLOW/DENY · a decentralized agent OS. Rule: we authorize agent actions; existing systems execute them.
03 — Architecture
The gateway sits between the agent and its tools. It identifies the agent, normalizes the tool call into a structured intent, gathers context (reputation, validation, task, budget), evaluates deterministic policy, issues a scoped capability or escalates, and records the full chain. Downstream executors — MCP servers, Composio, native adapters — perform the concrete API calls.
04 — Core flow + data model
Agent → Intent → Policy/Context evaluation → Allow | Deny | Escalate → Capability → Tool execution → Result → Audit event. Intents carry task, agent, normalized action, resource, and risk class. Decisions record the matched rule, reasons, and risk score. Capabilities are narrowly scoped, 5-minute, policy-hash-bound artifacts — replayed or expired consumes are rejected with explicit reason codes (replay, expired, not_found, revoked). The audit chain connects intent → decision → capability → execution → result per task and is queryable via trace APIs.
05 — Deterministic policy engine
LLMs draft and summarize intent; they never authorize. A pure rule engine decides ALLOW / DENY / ESCALATE with first-match-wins semantics over versioned policy documents (default-v1 for general tools, payment-v1 for spend: service allowlist · task budget · reputation floor 0.80). Risk classes: reads are low, merges/deploys and money movement are high and always escalate. Reason codes are verbatim and stable: tool_not_allowed, secret_resource, resource_outside_task, budget_exceeded, reputation_below_threshold, risk_requires_approval.
06 — Trust context: ERC-8004 × The Graph
Demo agents hold real ERC-8004 onchain identities. Reputation is read live from The Graph's Agent0 subgraph and changes real outcomes: the contractor agent lab-1 carries genuine negative feedback onchain, so the gateway escalates everything it does. The console shows the exact GraphQL query and The Graph's verbatim response per agent — the trust signal comes from the indexer, never our database. Hedera hosts no ERC-8004 contracts: read-on-Base, enforce-on-Hedera.
07 — Machine payments: x402 on Hedera
Paid services answer 402 Payment Required with a $0.25 quote. The gateway checks the task's spend policy (approved service · amount ≤ remaining budget · reputation), then the server-held payment authority settles in HBAR on Hedera testnet through the Blocky402 facilitator (/verify → /settle, x402 v2). The settlement reference is recorded on the payment row and the merchant independently verifies it against the mirror node before returning any report. The agent never touches a wallet key.
08 — Human approvals + anchoring
High-risk actions escalate to named approval councils (deploy-council, treasury-council). The approver signs with their own wallet (EIP-191 personal_sign); the server verifies the signature against the registered approver address and seals signer + signature into the approval event. Ledger is the hardware root-of-trust path (wallet-cli ring / Key Ring); without a device the dev provider is used and honestly labeled DEV (stand-in) — never claimed as hardware security. Every allowlisted audit event is sha256-fingerprinted and submitted fire-and-forget to a Hedera Consensus Service topic; the verify page recomputes each fingerprint against the mirror node (VERIFIED / PENDING / NOT-ANCHORED).
09 — Onchain registry
Everything below is public and safe to share. No private keys appear anywhere in this repo's docs — signing keys live only in the gitignored app/.env.local (HEDERA_OPERATOR_KEY, AGENT_OWNER_KEY) and are never printed, logged, or committed. What is written out here is the verifiable public surface: contracts, identities, accounts, topics, and explorers.
FACILITATOR api.testnet.blocky402.com · RPC sepolia.base.org · FAUCET portal.hedera.com · SCAN PRICE $0.25 ≈ 3.3 HBAR · NO NEW SOLIDITY CONTRACTS IN THE MVP (FOUNDARY SCAFFOLD UNTOUCHED)
10 — Demo tenant: Acme
Acme is a fictional 120-person fintech (invoicing SaaS, GitHub monolith + onchain USDC/ETH treasury) invented so the demo story, script, and transcript describe the same imaginary customer. Repos, PRs, secrets, deploys, and quotes are simulated and labeled on screen. What is real: the authorization pipeline every fictional action passes through, the ERC-8004 identities, the HBAR settlements, the wallet-signed approvals, and the HCS anchors. Cast: deploy-agent (ship code) · treasury-agent (move money) · reader-agent (reads only) · lab-1 (unproven contractor, supervised). Each pilot incident maps to a beat: injected .env read → DENY · over-budget scan → DENY · cross-task read → DENY · low-rep read → ESCALATE · merge/deploy → ESCALATE → approve → execute.
11 — Integration surface
Agents reach the gateway over standard MCP (five tools via our MCP server + official SDK client) or plain HTTPS tool-call routes. Console: agents, tasks, policies, approvals, payments, audit traces, network stream (SSE). Trust reads: live Agent0 subgraph with offline fixture fallback. Payments: x402 challenge → budget policy → Blocky402 settle → mirror-verified report. Approvals: pending queue → wallet sign → resolve → capability. Anchors: per-event fingerprint → HCS topic → verify page.
12 — Security properties
The model drafts, the policy decides — the LLM is never the ALLOW/DENY oracle. Capabilities are single-action, single-resource, five-minute, policy-bound. Agents hold budget scopes, never payment keys. Settlements are merchant-verified fail-closed against the mirror node; replays, expiries, and tampered nonces are rejected. Private tenant data (prompts, arguments, secrets) stays offchain; only identity, reputation, attestations, payments, and fingerprint anchors touch the chain. Dev/mock surfaces are always labeled; a simulator is never presented as hardware security.
13 — Run it yourself
14 — Sources
□ CUBIC — MCP GIVES AGENTS TOOLS. ERC-8004 GIVES THEM IDENTITY. WE DECIDE WHAT THEY MAY DO.