How to Secure AI Agents
A practical authorization checklist for agents that call tools, delegate work, or act for people and organizations.
No package makes an agent secure by itself. A defensible design combines model and tool isolation, strong authentication, least-privilege authorization, input and output controls, monitoring, and incident response. Grantex addresses the delegated-authorization layer.
1. Give each agent an attributable identity
Do not rely on one shared API key to distinguish several agents. Bind a stable agent DID, principal identifier, and grant identifier into a signed authorization token so the receiving service can attribute the request.
2. Enforce least privilege at the tool boundary
Define action-specific scopes such as calendar:read and calendar:write. The service that owns the protected action—not the model—must verify and enforce the required scope before execution.
3. Capture a real delegation decision
Show the person or organization which agent is requesting which scopes, for how long, and for which service. A consent URL or UI is only one part of this: the authorization server must record the approved grant and reject mismatched or replayed exchanges.
4. Verify every token and request context
- Validate signature, algorithm, issuer, audience, expiry, and not-before claims.
- Require the expected agent, principal, and scope for the action.
- Retrieve signing keys from the configured JWKS endpoint and handle key rotation.
- Never treat an MCP session identifier or model-generated field as authentication.
5. Design revocation explicitly
Local JWT verification checks signatures and claims after JWKS retrieval. It does not prove current revocation unless the verifier performs an online state check or synchronizes revocation data. Use short token lifetimes as an additional exposure limit, not as a substitute for state when immediate revocation is required.
6. Attenuate sub-agent delegation
A child grant should never exceed its parent. Require a subset of parent scopes, track the parent grant and delegation depth, cap depth, and cascade state changes according to policy.
7. Separate authorization from audit
A valid grant proves what was authorized; it does not prove which tool actually ran. Add an audit integration at the execution boundary and record the agent, principal, grant, action, outcome, timestamp, and non-secret context. Hash chaining makes later changes evident, not impossible.
8. Apply budgets and domain policy
For spend or other metered actions, enforce limits server-side using a transactional source of truth. Combine scopes with amount, category, destination, time, and organizational policy; never trust a model to self-enforce a budget.
Implementation checklist
| Control | Evidence to test |
|---|---|
| Identity | Requests resolve to one agent, principal, and grant |
| Scope | A missing or narrower scope returns a denial before tool execution |
| Verification | Wrong issuer, audience, signature, or expiry is rejected |
| Revocation | The verifier receives current state within the documented window |
| Delegation | Broader child scopes and excessive depth are rejected |
| Audit | Successful and denied actions are attributable without logging secrets |
| Recovery | Operators can revoke, rotate keys, investigate, and restore service |
Choose the current implementation
- TypeScript application:
@grantex/sdk@0.3.13 - Python application:
grantex==0.3.14 - Go application:
grantex-go@v0.1.10, with the documented workarounds - MCP production integration: primary SDK or direct JWKS enforcement; treat MCP Auth 2.0.2 as evaluation software
Build the enforcement point first
Start with a protected service, one narrow scope, one denial test, and one revocation test.
Authorization quickstart Package statusTechnical review updated 12 July 2026.