Building cryptographic trust boundaries for the agentic web

There’s a moment in every software architect’s career when you realize the system you built assumes everyone is nice. It happened to me in 1987 with a shared file server. It happened again in 2003 with a web app that trusted client-side validation. And it’s happening right now, across the entire AI agent ecosystem, at a scale that would make Douglas Adams reach for his towel.

The Problem: Trust Me, I’m an Agent

Here’s the setup. You have an AI assistant. It’s helpful. It can search the web, read your documents, send emails, book meetings. You ask it to research a topic, and it delegates that research to a cheaper, faster sub-agent. Reasonable architecture. Every framework supports it.

Now here’s the question nobody’s asking: what stops that research sub-agent from reading your private files? What stops it from sending an email as you? What stops it from spending $500 on API calls when you expected $0.50?

The answer, in every major agent framework today, is nothing. CrewAI, AutoGen, LangGraph, OpenClaw, whatever you’re using. The delegation model is “here’s a task, go do it, I trust you.” There are no scoped permissions. No budget enforcement. No cryptographic proof that work was completed correctly. No way to revoke a delegation mid-flight.

It’s the honor system, applied to autonomous software that hallucinates.

If that doesn’t worry you, you haven’t been paying attention. And if you have been paying attention, you’ve probably been waiting for someone to build the solution. I got tired of waiting.

The DeepMind Paper: Someone Finally Said It

In February 2026, Google DeepMind published a paper (arxiv.org/abs/2602.11865) that laid out the agent infrastructure stack as it exists today. MCP handles tool access. A2A handles agent-to-agent communication. But between these two layers, there’s a gap the size of the Ravenous Bugblatter Beast of Traal.

Nobody handles delegation trust. Nobody handles accountability. Nobody handles the question of “Agent B says it completed the task, but did it actually, and can we prove it?”

The paper didn’t build a solution. It identified the gap. That was enough for me.

What We Built

DelegateOS is a TypeScript library that adds cryptographic delegation to multi-agent systems. The core concept is the Delegation Capability Token, or DCT. It’s an Ed25519-signed JSON token that encodes everything about what an agent is authorized to do:

• Capabilities: Which namespaces, actions, and resources. “Web search on *.edu domains” is a valid scope.
• Budget: Maximum spend in microcents. Enforced at every verification checkpoint.
• Expiry: When the token dies. No renewals.
• Chain depth: How many levels of sub-delegation are allowed.
• Contract reference: What task this delegation is for, and what “done” means.

The critical property is monotonic attenuation. When Agent A delegates to Agent B, B’s token can only be equal to or narrower than A’s token. B can then delegate to C, but C’s scope can only shrink further. Capabilities never expand as you go down the chain. This isn’t a policy. It’s math. The verification algorithm rejects any token that attempts to widen scope.

How It Works

Let’s walk through the personal assistant use case. You’re the root authority. Your assistant gets broad capabilities. It delegates research to a sub-agent with narrow scope.

import { generateKeypair, createDCT, attenuateDCT, verifyDCT } from 'delegateos';

// Everyone gets an Ed25519 keypair
const you = generateKeypair();
const assistant = generateKeypair();
const researcher = generateKeypair();

// You grant your assistant broad capabilities
const assistantToken = createDCT({
  issuer: you,
  delegatee: assistant.principal,
  capabilities: [
    { namespace: 'web', action: 'search', resource: '*' },
    { namespace: 'docs', action: 'read', resource: '/home/me/**' },
    { namespace: 'email', action: 'send', resource: '*' },
  ],
  contractId: 'ct_daily',
  delegationId: 'del_001',
  parentDelegationId: 'root',
  chainDepth: 0,
  maxChainDepth: 2,
  maxBudgetMicrocents: 1_000_000, // $10
  expiresAt: new Date(Date.now() + 86400_000).toISOString(),
});

// Assistant delegates research — ONLY web search, ONLY .edu, $0.50, 10 minutes
const researchToken = attenuateDCT({
  token: assistantToken,
  attenuator: assistant,
  delegatee: researcher.principal,
  delegationId: 'del_002',
  contractId: 'ct_daily',
  allowedCapabilities: [
    { namespace: 'web', action: 'search', resource: '*.edu/**' },
  ],
  maxBudgetMicrocents: 50_000,
  expiresAt: new Date(Date.now() + 600_000).toISOString(),
});

When the researcher tries to use a tool, DelegateOS verifies the token. Web search on arxiv.org? Allowed. Read a file? Denied. The capability was never delegated. Send an email? Denied. Spend more than $0.50? Denied. Try after 10 minutes? Denied, expired.

This isn’t access control in the traditional sense. There’s no central authority maintaining a permissions database. The token itself carries the proof. Any verifier with the root public key can independently confirm that this token grants these capabilities and no more.

The Rest of the Stack

Tokens alone aren’t enough. DelegateOS also includes:

Contracts. Every delegation references a task contract that specifies what “done” means. The contract includes a JSON Schema for the expected output, verification method (schema match, deterministic check, LLM judge, human review, or composite), and constraints like budget and deadline.

Attestations. When an agent completes a task, it produces a signed attestation. This is cryptographic proof of completion: what was done, by whom, at what cost, verified against the contract. Attestations chain back to the root delegator, forming an auditable trail.

Revocation. You can revoke any delegation mid-flight. Single token or cascading (revoke a token and everything delegated from it). The revocation list is checked at every verification.

Trust scoring. Agents build reputation over time. The trust engine tracks reliability, quality, and speed with exponential decay. Cold-start agents get a neutral score. Good performance rises. Bad performance falls. The delegation broker uses trust scores to select agents.

MCP middleware. DelegateOS ships a plugin that intercepts MCP tools/call requests and enforces DCT permissions transparently. Drop it into an existing MCP setup, define which tools map to which capability namespaces, and every tool call gets verified against the caller’s token.

What’s Next

DelegateOS is at v0.3 with 374 tests across 27 files. The core is solid. What’s coming:

• Biscuit token backend as an opt-in upgrade from the current SJT format. The Datalog engine is already built.
• Distributed revocation with gossip-style sync between nodes.
• HTTP+SSE transport for running the MCP middleware as a standalone service.
• Real LLM judge and human review adapters (currently mocked for testing).

The repository is at github.com/newtro/delegateos. MIT licensed. TypeScript all the way down. npm install delegateos.

If you’re building multi-agent systems and you haven’t solved the trust problem yet, you’re building on sand. Don’t panic. But do bring a towel.

First published February 17, 2026 on 42 Insights.