Why LLM orchestration is broken (and how cryptographic agent identities fix it)

Last week, a “helpful” coding agent opened a PR, commented on the issue, triggered CI, and then tried to deploy to staging.

The weird part? Nobody could answer a basic question:

What rights did that agent actually have, and who gave them?

Not “which API key did it use.”
Not “which workflow ran.”
Not even “which model generated the output.”

I mean: which agent took the action, what it was allowed to do, and whether that authority was delegated intentionally.

That’s the orchestration rights problem, and it’s getting worse as teams wire up Claude, Cursor, Copilot, Devin, internal bots, MCP servers, GitHub Actions, and homegrown tools into one giant autonomous spaghetti pile.

The real problem isn’t tool calling

Most agent systems today still treat identity like this:

• the agent uses a shared API key
• the orchestrator decides what tools it can call
• logs tell you something happened
• approvals happen out-of-band, if at all

That works until multiple agents share the same tools, act on behalf of users, or hand off tasks to other agents.

Then your access model turns into:

“I guess this request came from the agent-ish part of the system?”

That’s not identity. That’s vibes.

What actually needs to exist

If agents are going to act in production, they need the same primitives we expect from humans and services:

• a stable identity
• verifiable authentication
• delegated rights
• auditable actions
• revocation and policy checks

In practice, that means giving each agent its own cryptographic identity instead of letting it hide behind shared tokens.

For example, an agent can have an Ed25519 keypair and use it to sign requests. Now a tool, MCP server, or proxy can verify:

1. which agent is calling
2. whether it’s acting for itself or on behalf of a user
3. what rights were delegated
4. whether policy allows this action

That sounds obvious when you say it out loud, but most LLM orchestration stacks still don’t do it.

Why delegation chains matter

A lot of agent actions are really delegated authority:

• Alice approves a task
• Planner agent breaks it into subtasks
• Coder agent edits code
• Deployer agent pushes to staging

If all those steps share one token, you lose the chain of responsibility.

With delegated identity, you can represent it more like this:

Alice
  ↓ delegates "open PRs on repo X"
Planner Agent
  ↓ delegates "edit files in /src only"
Coder Agent
  ↓ requests "write src/auth.ts"
MCP Tool / Repo API

Now the receiving system can evaluate the full chain, not just the last caller.

That matters for security, but also for debugging. When something goes wrong, you want to know:

• did the user approve this?
• did the planner exceed scope?
• did the coding agent attempt an action outside policy?

Without cryptographic identities and delegation, you’re mostly reconstructing intent from logs after the fact.

A tiny runnable example

Here’s the basic idea in Node using Ed25519 signatures.

npm install tweetnacl tweetnacl-util

const nacl = require("tweetnacl");
const util = require("tweetnacl-util");

const keys = nacl.sign.keyPair();
const request = JSON.stringify({
  agent: "coder-agent",
  action: "write_file",
  resource: "src/auth.ts"
});

const msg = util.decodeUTF8(request);
const sig = nacl.sign.detached(msg, keys.secretKey);

const ok = nacl.sign.detached.verify(msg, sig, keys.publicKey);

console.log("request:", request);
console.log("verified:", ok);
console.log("agent pubkey:", Buffer.from(keys.publicKey).toString("hex"));

That example only proves authorship, not authorization. In a real system, you’d pair it with:

• RBAC or policy rules
• short-lived delegated tokens
• approval workflows for sensitive actions
• audit logs tied to the verified agent identity

If you already use OPA, keep using OPA. It’s a good fit for policy evaluation here. The missing piece is often just that the “subject” in your policy needs to be a real agent identity, not a shared service account.

What this architecture looks like

[ User ]
   │ approves / delegates
   ▼
[ Agent Identity ]
   │ signs request
   ▼
[ Orchestrator ]
   │ passes delegation chain
   ▼
[ MCP Server / Tool Proxy ]
   │ verifies signature + policy
   ▼
[ Tool executes or denies ]

That verification step is where a lot of current stacks are still weak.

If your MCP server can’t distinguish between:

• a trusted deploy agent
• a random local script
• a compromised agent session

…then your authorization model is mostly ceremonial.

What changed recently

A year ago, a lot of this was theoretical because agents mostly generated text and maybe called a weather API.

Now they:

• edit production code
• open PRs
• access secrets
• trigger workflows
• hit internal APIs
• coordinate with other agents

That means identity is no longer optional plumbing. It’s part of the execution model.

The moment one agent can delegate work to another, you need rights to travel with the request in a verifiable way.

Try it yourself

If you’re working on agent security or MCP auth, here are a few free tools that are actually useful:

• Want to check your MCP server? Try https://tools.authora.dev
• Run npx @authora/agent-audit to scan your codebase
• Add a verified badge to your agent: https://passport.authora.dev
• Check out https://github.com/authora-dev/awesome-agent-security for more resources

The practical takeaway

If your agent platform still relies on shared API keys and trust-me bro orchestration, you don’t really have agent authorization.

You have tool access with extra steps.

Cryptographic agent identities won’t solve every problem, but they do give you a solid answer to the question that matters most:

who is this agent, and what is it actually allowed to do?

How are you handling agent identity today? Drop your approach below.

-- Authora team

This post was created with AI assistance.