MCP is Winning

The Model Context Protocol is becoming the standard for connecting AI to external tools. Anthropic built it. OpenAI adopted it. It's how agents access databases, file systems, APIs, and services. There's just one problem: MCP inherited its authorization model from a world that assumed humans were always present.

THE EMERGING STANDARD MCP Model Context Protocol Claude Anthropic ChatGPT OpenAI IDEs VS Code, Cursor... Services DBs, APIs, Files Tools list, call, execute Authorization model assumes humans present inherited from OAuth — built for a different era

The OAuth Dance

Today, when an agent needs access to your documents, it triggers an OAuth flow. You're redirected to a consent screen. You select which documents. You click approve. A token is issued. This works—if a human is sitting there, ready to click.

THE OAUTH DANCE Agent wants access MCP Server tools/resources Auth Server OAuth 2.1 Human must be present 1. request access 2. initiate OAuth 3. redirect "Select documents..." "Grant permissions?" ✓ Approve 4. access token returned Token is scoped and time-limited This works — if a human is sitting there, ready to click.

Why This Breaks

What happens when the agent needs to act at 3 AM? When an orchestrator spawns sub-agents? When you have dozens of agents, each needing authorization? Consent fatigue leads to rubber-stamping—or abandonment.

WHY OAUTH BREAKS FOR AGENTS Scenario 1: The 3 AM Problem Agent needs access at 3 AM Human 💤 Token expired. Work stops. Scenario 2: The Delegation Problem Orchestrator Sub-Agent A Sub-Agent B Human authorized orchestrator. Did they authorize A? B? How deep does consent go? Scenario 3: The Scale Problem Human 😵 Agent 1 wants access Agent 2 wants access Agent 3 wants access Agent 4 wants access Agent 5 wants access "Consent fatigue" rubber-stamping or quit The OpenID Foundation's own whitepaper admits it: OAuth 2.1 "may fall short in scenarios that are cross-domain, highly autonomous, or asynchronous."

Flip the Model

DNTLS flips the model. Instead of authorizing at connection time, you declare policy ahead of time. The connection just verifies identity—proving the agent is who it claims to be. The service looks up what that identity is allowed to do.

THE PARADIGM SHIFT OAuth Model Authorization is an INTERACTION Human must be present Happens at connection time Tokens are ephemeral Scopes granted per-session Agents wait for humans DNTLS Model Authorization is a LOOKUP Policy declared ahead of time Connection just verifies identity Identity is the anchor Permissions are persistent Agents act on policy No consent dialogs. No token expiration. No human required at 3 AM. The service looks up what that identity is allowed to do.

Simple Example

You run a document service. You want agents to access documents on behalf of users. With DNTLS: declare that agent1.josh.dntls can read and write doc1. When the agent connects, the service verifies the identity and checks the permissions table. No OAuth dance. No consent screen. No human present.

DOCUMENT SERVICE EXAMPLE Step 1: Policy Declaration done once, ahead of time Document Service Permissions Table agent1.josh.dntls → [doc1, doc2] → read/write agent2.josh.dntls → [doc1] → read only Step 2: Connection no human needed agent1.josh.dntls "I want to write to doc1" Document Service 1. Verify DNTLS identity 2. Lookup permissions 3. ✓ Authorized Verification (three-part, as always): Key exists on-chain • Signature valid • Service record hash matches

Hierarchical Delegation

A human grants ONE permission: the orchestrator can set permissions—but only for identities under *.writers.foo.dntls. The orchestrator creates rules within its scope. New agents inherit permissions automatically. Delegation is built into the namespace.

HIERARCHICAL DELEGATION Phase 1: Initial Setup Human grants scoped meta-permission Document Service orchestrator.foo.dntls Can delegate: ✓ *.writers.foo.dntls ✓ *.editors.foo.dntls Cannot delegate: ✗ admin.foo.dntls ✗ billing.foo.dntls Human sets ONE scoped permission. Orchestrator can only delegate within its subtree. 1 of 4 Phase 2: Orchestrator Creates Policy Within its allowed scope orchestrator.foo.dntls Creates delegation rules: ✓ *.writers.foo.dntls → read/write ✓ *.editors.foo.dntls → comment ✗ admin.foo.dntls → read/write (rejected: outside scope) Orchestrator can only create rules within its delegated namespace subtree. 2 of 4 Phase 3: Agents Get Access Automatically Pattern matching grants permissions agent1.writers.foo.dntls agent2.writers.foo.dntls agent3.writers.foo.dntls Document Service *.writers.foo.dntls? ✓ Match → read/write All matching identities automatically get the permissions defined in the rule. 3 of 4 Phase 4: Scale Without Human Intervention New agents inherit permissions automatically orchestrator.foo.dntls "Spawn agent4" agent4.writers.foo.dntls ✓ Immediate write access No provisioning. No consent. No human. The meta-permission uses the same namespace hierarchy. No privilege escalation possible. Delegation is built into the namespace. 4 of 4

Cross-Domain Scaling

With OAuth, N agents × M services = N×M consent flows. Ten agents and five services? Fifty human interactions. With DNTLS, both services verify identity the same way. Add a third service? One more permission entry. That's it.

CROSS-DOMAIN SCALING With OAuth: The Multiplication Problem N agents × M services = N×M consent flows Document Service Planning Tool agent1 → Doc Service → OAuth → Token A agent2 → Doc Service → OAuth → Token C agent3 → Doc Service → OAuth → Token E agent1 → Planning → OAuth → Token B agent2 → Planning → OAuth → Token D agent3 → Planning → OAuth → Token F 6 consent flows. 6 unrelated tokens. Each expires separately. 10 agents × 5 services = 50 human interactions 1 of 2 With DNTLS: One Identity, Verified Everywhere Same verification, service-specific permissions Document Service config: *.writers.foo.dntls → read/write Planning Tool config: *.writers.foo.dntls → update status agent1.writers agent2.writers agent3.writers Same verification for both services Key exists • Signature valid • Service record matches Add a third service? One more permission entry. That's it. 2 of 2

What This Means

MCP's protocol mechanics don't change. Tools are still discovered via tools/list. What changes is the trust layer underneath. The agent presents its identity. The service verifies it. Policy determines access. This is what agent-native infrastructure looks like.

WHAT THIS MEANS TODAY Human-gated access Interactive consent Token management Per-service OAuth Manual provisioning Agents wait for humans WITH DNTLS Policy-gated access Declarative rules Identity verification Universal trust layer Hierarchical delegation Agents act on policy MCP protocol mechanics don't change: tools/list • tools/call • JSON-RPC What changes is the trust layer underneath. The agent presents its identity. The service verifies it. Policy determines access. No middleman. No consent fatigue. No 3 AM blockers. This is what agent-native infrastructure looks like.