I built an authorization layer for AI agents. Here's why it had to be non-custodial.

Jonathan Klimoski — Mon, 30 Mar 2026 04:29:32 +0000

A few months ago I was prototyping an agent that needed to make purchases -- API credits, small SaaS subscriptions, that kind of thing. I started wiring it up to a payment method and immediately hit a wall I couldn't shake: there was no layer between the agent and the funds. No "is this actually okay right now?" check. Just a key with full access.

I looked for something that handled agent-specific authorization -- not just API rate limiting, but actual financial authorization with per-agent limits and a trust model. Nothing existed. So I built it.

That's Agentra. It authorizes transactions for autonomous agents and maintains trust scores for both sides of a transaction. It never holds private keys or custodies funds -- just says yes or no, and records the decision.
why non-custodial?

The obvious design is to custody funds -- hold USDC, move it on behalf of agents. That's what I initially sketched out. But it puts you immediately into money transmitter territory. Licensing, audits, state-by-state compliance. That's a dead end for infrastructure that needs to be everywhere agents are.

The architecture that made more sense: separate the authorization decision from the movement of funds entirely. The agent controls its own keys via Turnkey WaaS. Agentra's platform wallet never holds user funds. What gets recorded on-chain is the authorization event itself -- an EAS attestation on Base Mainnet.

That attestation is public. Any counterparty can verify an agent was authorized before accepting a payment without trusting the agent directly.
try it

The API is live. Register an agent:

curl -X POST https://api.agentrapay.ai/v1/agents/register \
-H "Content-Type: application/json" \
-d '{
"agent_name": "my-test-agent",
"agent_type": "payment",
"description": "testing"
}'
You get back an api_key (prefixed agn_) and an agent_id. New agents start at Unverified -- $100 per transaction, $250 daily. Limits increase as the agent builds a trust history. Denials come back with an upgrade_path object explaining exactly what the agent needs to do next, which turned out to be more important than I expected -- without it, limits just feel like a wall.
Check trust score:
curl https://api.agentrapay.ai/v1/trust/{agent_id} \
-H "X-API-Key: agn_your_key"

the stack

Rust / Axum 0.8 / PostgreSQL on Railway.

I went with Rust because authorization decisions need to be fast and the memory safety story matters when you're touching financial logic. The performance profile is worth the tradeoffs.
One sharp edge if you're using Axum 0.8: apply .with_state() to each sub-router individually before merging. If you apply a single .with_state() after .merge(), middleware bleeds across sibling routes in ways that are hard to debug. Burned a few hours on that.

The MCP server is also live at

https://api.agentrapay.ai/mcp -- published to the official MCP Registry as ai.agentrapay/agentra.

Agents that support MCP can discover and call Agentra natively without a separate SDK.
what's next

Framework integrations -- LangChain, AutoGen, CrewAI. If you're building in any of those ecosystems and want to test an early integration, I'd love to hear from you.

Free tier is 100 authorizations + 50 trust lookups per month, no credit card. If you try it and hit something broken or confusing, drop it in the comments.

agentrapay.ai | MCP Registry: ai.agentrapay/agentra | Docs

DEV Community: Jonathan Klimoski

I built an authorization layer for AI agents. Here's why it had to be non-custodial.