The Agent Economy Needs a Trust Layer

The pitch for autonomous agents has quietly shifted. It's no longer just "an agent that calls tools for me" — it's agents negotiating, ordering, and settling with other companies' agents, on their own, at machine speed. That's a real economy, and economies run on trust between parties who don't control each other. Right now, nothing enforces that trust. When Company A's agent talks to Company B's API, B is typically extending the same blind faith it would give its own internal script: hand the model a token or a tool with execute permissions, and hope the system prompt holds. That's a reasonable bet inside one company's four walls. It's not a bet either party can make about a counterparty's model — an LLM can't give a formal guarantee about its own behavior, and a prompt injection, a context shift, or a plain hallucination on their side becomes your unauthorized transaction. So before agents can actually run an economy, someone has to answer a boring but load-bearing question: what, concretely, stops one organization's agent from doing something the other organization never agreed to? This is a working engineer's notes on one answer I've been testing over the past few months. It's early-stage — not a finished product, not a standard, not externally audited — but the code is real and open, and I'd like feedback on where it breaks. The working hypothesis: reasoning and execution authority are two different layers ┌─────────────────────────────────────────────────────────────┐ │ SEMANTIC PLANE (Probabilistic) │ │ - Handled by AI models (LLMs, autonomous agents) │ │ - Understands and manages INTENT & rich task CONTEXT │ │ - Discovers tools, proposes actions, maps business schemas │ │ - Holds ZERO execution credentials. Cannot mutate state. │ └──────────────────────────────┬──────────────────────────────┘ │ ProposedAction envelope │ (Intent + Context + Arguments) ▼ ┌─────────────────────────────────────────────────────────────┐ │ CONTROL PLANE (Deterministic) │ │ - Pure Rust logic, no LLM involved │ │ - Evaluates call-chain depth and cycle limits (Layer 0) │ │ - Checks policy rules, contracts, & monetary thresholds │ │ - Mints short-lived, single-use Execution Grants (Ed25519) │ └──────────────────────────────┬──────────────────────────────┘ │ Cryptographic Grant ▼ ┌─────────────────────────────────────────────────────────────┐ │ TOOL EXECUTOR │ │ - Verifies grant signature & argument hash (RFC 8785) │ │ - Dispatches call to destination system │ │ - Scrubs PII / secrets from the output │ └─────────────────────────────────────────────────────────────┘ The semantic plane is where intent gets captured — the messy part LLMs are genuinely good at: parsing unstructured context, understanding what a counterparty is trying to accomplish, proposing a plausible next action. But because that context can be manipulated, this layer never holds raw credentials and never gets to decide the boundary of its own authority. The control plane is deterministic Rust, no ML involved. It doesn't interpret intent — it checks the proposed action against hard facts: caller identity, session state, call-chain depth, and signed contracts, then issues a single-use execution ticket if and only if everything checks out. If an agent wants to act, it packages intent and parameters into a ProposedAction. Only the control plane's approval turns that into something an executor will actually run. The actual unit of the agent economy is a bilateral contract Most AI-commerce discussion is about consumer chatbots checking out a cart. That's not the interesting case. The interesting case is two businesses letting each other's agents interact under negotiated terms — transaction caps, payment terms, geography, bilateral liability — with neither party able to inspect or constrain the other's model. A system prompt doesn't enforce any of that. A signed, mutually-agreed contract can. I treat an agent's authority as the strict intersection of three independent boundaries: ┌────────────────────────────────────────────────────────┐ │ EFFECTIVE AUTHORITY │ │ = │ │ Negotiated Terms ∩ Enterprise Policy ∩ Identity │ └────────────────────────────────────────────────────────┘ An agent has zero inherent authority. It only earns the right to trigger an action if all three hold at once: Negotiated Terms (bilateral): did both organizations agree this capability is allowed, at this limit, currency, geography? Enterprise Policy (local): does the host's internal policy allow it right now — rate limits, hours, maintenance windows? Agent Identity (cryptographic): is the agent provably who it claims to be, via did:web and active keys? Even if an LLM is 100% confident it should place a €30,000 purchase order, the control plane rejects the proposal before it touches a database if the bilateral agreement caps automated orders at €25,000. What's actually implemented, not just designed Cryptographic parameter binding (Execution Grants) A passed proposal doesn't just get approved: true — the gateway mints an ExecutionGrant signed with Ed25519. Arguments are bound via RFC 8785 JSON Canonicalization (JCS) + SHA-256, so any tampering between approval and execution — an altered account number, a changed amount — produces a hash mismatch and immediate rejection. Every grant carries a single-use nonce against replay. Layer 0 call-chain guard Before any business policy is evaluated: Cycle detection — rejects a call if the tool/agent is already in the active call stack (no A↔B loops) Depth ceilings — default max 10 hops Per-tool frequency caps — e.g. max 3 calls per task Session integrity checking — the gateway keeps its own authoritative call stack keyed by trace ID; a spoofed or truncated history from the agent is detected and denied Bilateral Interaction Contracts (NICP) Two parties, identified via did:web, draft an agreement (capabilities, transaction limits, geography), canonicalize and hash it (RFC 8785), and both sign the hash (Ed25519). At runtime, every proposal is checked against the active contract — an order over the agreed ceiling never reaches grant-minting. trustctl — a CLI enforcement point Reads tool JSON Schemas, maps them to CLI flags, computes canonical input hashes, and maps gateway responses to POSIX exit codes: 0 success, 1 schema failure, 126 policy denied, 127 unknown tool. Egress redaction Regex scrubbing for emails/card numbers/bearer tokens/API keys, recursive JSON traversal for nested objects, and audience-aware masking depending on whether the caller is an external agent or an internal auditor. What's still open Latency — canonicalization, signing, and gateway hops add real overhead; full grant-minting is probably overkill for high-frequency reads. Schema evolution — how should an existing bilateral contract handle a backend schema change without breaking live workflows? No external audit yet — none of the cryptographic ceremonies or state machines have had outside security review or pen-testing. Expressiveness vs. rigidity — where's the line between giving an agent enough room to solve real problems and keeping the guardrails tight? I don't think the trust layer this economy needs is a human approving every low-level click, and I don't think it's every company handing counterparties' agents raw API keys and hoping their system prompts hold. Separating probabilistic reasoning from deterministic, cryptographically-enforced execution authority feels like a sturdier foundation for agents to actually transact across organizational boundaries — but this is one engineer testing a hypothesis, not a solved problem, and I'd genuinely like to hear where it breaks in your production environments. Code: fcn06/trust_gateway on GitHub, including a working-draft whitepaper on the threat model. Treat it as an experimental research artifact, not a polished library.