Why AI Agents Need Authorization
A traditional API integration has a developer, a credential, and a service. The developer writes the code, decides which endpoints to call, and ships it. The credential never makes autonomous decisions. AI agents break this model. An agent decides at runtime which tools to call, which APIs to hit, and which actions to take. The same agent might read your calendar one moment and try to delete a database table the next — all within a single conversation. Without proper authorization, the only thing standing between an agent and a catastrophic action is the LLM’s judgment. That is not a security model. That is a prayer. Three specific problems make AI agent authorization different from traditional API auth:- Dynamic tool selection. You cannot predict at build time which tools an agent will invoke. The agent decides based on the user’s request and its own reasoning.
- Delegation chains. A parent agent may spawn sub-agents, each of which needs its own narrowly-scoped permissions. API keys do not support this.
- Auditability. When an agent performs an action, you need to know which agent, which user approved it, what scopes were granted, and when the permission expires. API keys give you none of this.
The Problem with API Keys
Most agent frameworks today tell you to pass your API keys as environment variables. The agent gets the same access as the key holder — typically full read/write access to the service. Here is what goes wrong:| Problem | API Keys | Delegated Auth |
|---|---|---|
| Scope | All-or-nothing access | Per-action scoped permissions |
| Revocation | Rotate the entire key | Revoke individual agent grants instantly |
| Audit trail | ”Someone used the key" | "Agent X did action Y, approved by user Z” |
| Delegation | Share the same key (dangerous) | Parent grants child a strict subset of permissions |
| Expiry | Manual rotation | Automatic time-limited tokens |
| Identity | Key identifies the developer | Token identifies the agent, user, and developer |
How Delegated Authorization for AI Agents Works
Delegated authorization follows a pattern similar to OAuth 2.0, but extended for agent-specific requirements. The flow works like this:- Agent registration. The agent gets its own cryptographic identity (a DID). This is not a shared credential — it uniquely identifies this agent instance.
- Authorization request. The agent requests specific permissions (scopes) from a human user. The user sees exactly what the agent is asking for.
- Consent. The user reviews the requested scopes and approves or denies. This is the human-in-the-loop step that API keys skip entirely.
- Token exchange. After approval, the agent receives a grant token — a signed JWT containing the approved scopes, the agent identity, the user identity, and an expiry time.
- Enforcement. On every tool call, the token’s scopes are checked against the tool’s required permission. If the agent tries to call a tool outside its granted scopes, the call is rejected before execution.
- Revocation. The user (or an admin) can revoke the grant at any time. The agent’s access stops immediately.
Implementing AI Agent Authorization with Grantex
Grantex is an open protocol (Apache 2.0) that implements this entire flow. Here is a working example in TypeScript:Scope Enforcement on Tool Calls
Authorization alone is not enough. You also need enforcement — checking the token’s scopes against the tool’s required permission on every call, before execution. Grantex ships 53 pre-built tool manifests covering popular services (Salesforce, Jira, Stripe, HubSpot, GitHub, Slack, and more). Each manifest maps tool names to required permission levels:Comparing AI Agent Authorization Approaches
| Approach | Scoped | Revocable | Auditable | Delegable | Standard |
|---|---|---|---|---|---|
| Raw API keys | No | Rotate all | No | No | N/A |
| OAuth 2.0 (human flow) | Yes | Yes | Partial | No | RFC 6749 |
| Service accounts | No | Yes | Partial | No | Varies |
| Custom JWT issuance | Yes | Manual | Manual | Manual | Custom |
| Grantex (delegated auth) | Yes | Yes (instant) | Yes (hash-chained) | Yes (depth-limited) | Open spec |
Getting Started
If you are building AI agents that interact with real services, you need authorization that matches the autonomy you are giving those agents. API keys are not enough. Start here:- Quickstart guide — up and running in under 5 minutes
- How it works — the full authorization flow explained
- Scope enforcement guide — enforce per-tool permissions with manifests
- Protocol specification — the full Grantex spec (v1.0, frozen)
- GitHub repository — Apache 2.0, open source