Why AI Agents Need Their Own Authorization Protocol (and How We Built One)

Every AI agent framework — LangChain, CrewAI, OpenAI Agents SDK, Vercel AI — has the same blind spot: authorization.

Your agent can read emails, book meetings, deploy infrastructure, and spend money. But how does it prove it's allowed to? The answer, for most teams,

is an API key with full access stuffed into an environment variable.

That's not authorization. That's a breach waiting to happen.

## The problem with API keys for agents

API keys were designed for server-to-server auth. They assume a single trusted caller. AI agents break every one of those assumptions:

• No scoping. The agent has the same permissions as the key owner.
• No consent. The user never approved what the agent can do.
• No per-agent identity. You know the key was used, but not which agent used it, or why.
• No revocation granularity. One agent misbehaves? Rotate the key. That kills every agent sharing it.
• No delegation control. Agent A calls Agent B? You're copy-pasting credentials.
• No spending limits. An agent with a cloud API key can provision unlimited resources.

OAuth 2.0 solved this for web apps 15 years ago. IAM solved it for cloud infrastructure. AI agents have nothing.

## Grantex: delegated authorization for agents

Grantex is an open protocol (Apache 2.0) that gives AI agents scoped, time-limited, revocable permissions —
with user consent.

Here's the flow:

1. Your app requests authorization for a specific agent and specific scopes
2. The user consents (optionally with FIDO2/WebAuthn passkey)
3. The agent receives a signed JWT with scoped claims — calendar:read, email:send, etc.
4. Any service verifies the token offline via JWKS — no callback to an auth server
5. Tokens expire, can be revoked, and are fully audited

typescript
  import { Grantex } from '@grantex/sdk';

  const gx = new Grantex({ apiKey });

  // Request authorization
  const auth = await gx.authorize({
    agentId: 'agent-123',
    userId: 'user-456',
    scopes: ['calendar:read', 'email:send'],
  });

  // Exchange for a grant token
  const { grantToken } = await gx.tokens.exchange({
    code: auth.code,
    agentId: 'agent-123',
  });

  // Verify anywhere — offline
  const grant = await verifyGrantToken(grantToken, {
    jwksUri: 'https://your-server/.well-known/jwks.json',
  });
  // grant.scopes → ['calendar:read', 'email:send']

  Works the same in Python:

  from grantex import Grantex

  gx = Grantex(api_key="...")
  auth = gx.authorize(agent_id="agent-123", user_id="user-456", scopes=["calendar:read"])
  result = gx.tokens.exchange(code=auth.code, agent_id="agent-123")

  And Go:

  client := grantex.New("your-api-key")
  auth, _ := client.Authorize(ctx, grantex.AuthorizeParams{
      AgentID: "agent-123",
      UserID:  "user-456",
      Scopes:  []string{"calendar:read"},
  })

  Delegation: agents authorizing other agents

  This is where it gets interesting. In real agentic systems, agents call other agents. A travel planner agent delegates to a booking agent, which       
  delegates to a payment agent.

  Grantex supports delegation chains with scope narrowing and depth limits:

  const delegation = await gx.grants.delegate({
    parentGrantToken: travelPlannerToken,
    subAgentId: 'booking-agent',
    scopes: ['booking:create'], // narrower than parent
  });

  Revoke the parent? Every child delegation dies automatically. Cascade revocation.

  Budget controls

  Give an agent a spending limit. The protocol enforces it atomically — no race conditions:

  await gx.budgets.allocate({
    grantId,
    amount: 50.00,
    currency: 'USD',
  });

  // Agent tries to spend
  const result = await gx.budgets.debit({
    grantId,
    amount: 12.50,
  });
  // result.remaining → 37.50

  Exceed the budget? The agent gets a 402 INSUFFICIENT_BUDGET. Not a silent failure — a hard stop.

  What else is in the box

  - FIDO2/WebAuthn — passkeys for consent approval
  - W3C Verifiable Credentials — portable agent identity
  - SD-JWT — selective disclosure (agent proves specific claims without revealing everything)
  - Real-time events — SSE/WebSocket streams for authorization events
  - Full audit trail — every action logged and queryable

  Framework integrations

  Drop-in integrations for the frameworks you're already using:

  ┌─────────────────────┬───────────────────────┐
  │      Framework      │        Package        │
  ├─────────────────────┼───────────────────────┤
  │ LangChain           │ @grantex/langchain    │
  ├─────────────────────┼───────────────────────┤
  │ CrewAI              │ grantex-crewai        │
  ├─────────────────────┼───────────────────────┤
  │ OpenAI Agents SDK   │ grantex-openai-agents │
  ├─────────────────────┼───────────────────────┤
  │ Vercel AI           │ @grantex/vercel-ai    │
  ├─────────────────────┼───────────────────────┤
  │ Google ADK          │ grantex-adk           │
  ├─────────────────────┼───────────────────────┤
  │ AutoGen             │ @grantex/autogen      │
  ├─────────────────────┼───────────────────────┤
  │ Express.js          │ @grantex/express      │
  ├─────────────────────┼───────────────────────┤
  │ FastAPI             │ grantex-fastapi       │
  ├─────────────────────┼───────────────────────┤
  │ MCP (Claude/Cursor) │ @grantex/mcp          │
  ├─────────────────────┼───────────────────────┤
  │ Terraform           │ grantex provider      │
  └─────────────────────┴───────────────────────┘

  Standards track

  This isn't a weekend project. The protocol has:

  - An IETF Internet-Draft submitted to the OAuth Working Group
  - A NIST NCCoE public comment filed
  - AuthZEN conformance mapping
  - SOC 2 Type I certification completed
  - A frozen, public https://github.com/mishrasanjeev/grantex/blob/main/SPEC.md

  Try it

  Everything is open source under Apache 2.0:

  - GitHub: https://github.com/mishrasanjeev/grantex
  - Docs: https://docs.grantex.dev
  - Playground: https://grantex.dev/playground

  npm install @grantex/sdk    # TypeScript
  pip install grantex          # Python
  go get github.com/mishrasanjeev/grantex-go  # Go

  If you're building agents that act on behalf of users, I'd love to hear how you're handling authorization today — and what's broken about it.