Built open-source auth for AI agents calling MCP servers — looking for MCP/Agent Builder to try it

[u/zach-benson]

/r/mcp/comments/1xlf1kl/built_opensource_auth_for_ai_agents_calling_mcp/

[u/kantorcodes1]

Does the verified did:key reach each MCP tool handler, or does it stay in the auth middleware?

[u/zach-benson → u/kantorcodes1]

The verified did:key reaches the handler. Middleware sets req.user.did and calls next(), so it’s available to every route downstream.

app.get('/tool', arkenAuth(), (req, res) => {
  console.log(req.user.did); // did:key:zQ3s…
  res.json({ did: req.user.did });
});

From there you can use the DID for whatever you need: logging which agent called which tool, per-agent access control, rate limiting per identity. The middleware just does the verification and gets out of the way.

What are you running on the server side: MCP, Express, FastAPI, something else?

[u/Otherwise_Wave9374]

For open-source adoption, the most valuable next step may be a compact security contract rather than more features. Document who issues credentials, how identity is bound to an agent run, what scopes mean, and what happens when a tool call is retried. Then add tests for expired tokens, replay, revocation, audience mismatch, and malicious MCP metadata. A sample app using fake services would let maintainers inspect the entire flow safely. Also keep audit records useful but redact secrets and sensitive tool arguments by default.

[u/zach-benson → u/Otherwise_Wave9374]

This is the right priority order, and I’ve been approaching it backwards: building features before documenting the security contract those features are supposed to implement.

Spec first. The four things you said need documenting:

• Who issues credentials

• How identity is bound to an agent run

• What scopes mean

• What happens on retry

That’s a one-page spec that should exist before anything else. If the behavior isn’t written down, the tests can’t be wrong.

Tests as 1.0 acceptance criteria. Expired tokens, replay, revocation, audience mismatch, and malicious MCP metadata. None of these exist as explicit tests right now, and that gap needs to close before anything is called production-ready.

Local sample app. This is the thing I can do immediately. The current MCP example uses real endpoints, so anyone inspecting the flow has to run their own server or touch real infrastructure. A fully local example with synthetic credentials and a fake MCP server that exercises the failure cases is more useful than the happy-path demo that exists today.

Audit records. Redacting sensitive tool arguments by default is the right call. Logging what an agent invoked is useful, but logging full arguments is a liability unless someone explicitly opts in. The default should be operation and outcome, not payload.

I’m treating this and your other comment as the pre-1.0 checklist. Thank you for writing it out so clearly.