AI agents are no longer experimental. Production systems today delegate real action, such as sending emails, committing code, and modifying records, to autonomous runtimes that chain tool calls without pausing for confirmation. That shift introduces authentication challenges that classic OAuth and session models were never designed to handle.
\nThis post maps the full authentication blueprint for AI agent systems: who the principals are, how tokens flow across trust boundaries, where policy enforcement must sit, and when a human must approve before execution continues.
\nFour distinct actors exist in a typical agentic system:
\nEach actor has its own identity, and each boundary between them is a potential trust gap.
\nClassical web applications execute deterministic code paths. Agents do not. The primary new risks are:
\nBecause agents act autonomously, the blast radius of a misconfigured permission is orders of magnitude larger than a misconfigured human-facing role. Scope narrowing is not optional: it is the primary control.
\nMinimal sequence diagram:
\nEnd-User → App Backend: authenticate (OIDC/OAuth)\nApp Backend → Agent Runtime: spawn(session_token, scopes=[narrow])\nAgent Runtime → Tool Server A: call(capability_token_A)\nAgent Runtime → Tool Server B: call(capability_token_B)\nTool Server → Policy Engine: evaluate(actor, action, resource)\nPolicy Engine → Tool Server: allow | denyEach agent identity should be scoped to a single tenant or organization. An agent operating inside Org A must never present credentials that are valid inside Org B. Org IDs must be encoded into every token, every log line, and every policy evaluation. Cross-tenant isolation is not a nice-to-have; it is the foundational invariant.
\nA healthy architecture separates session lifetimes into two tiers:
\nAgent sessions should expire when the task completes or when the wall-clock TTL expires, whichever comes first.
\nScopes flow strictly downward. A user token carrying repo:read can produce an agent token carrying repo:read, but never repo:write. An agent token can produce a per-tool capability token carrying an even narrower scope. The rule is: only narrow, never widen.
| Token Type | \nIssued To | \nAudience | \nRotation | \n
|---|---|---|---|
| User access token | \nEnd-user | \nApp backend | \nOn refresh | \n
| Agent session token | \nAgent runtime | \nAgent runtime | \nPer task | \n
| Capability token | \nAgent → Tool | \nSpecific tool server | \nPer call or per minute | \n
Standard bearer tokens can be replayed if intercepted. Sender-constrained tokens bind a token to the entity presenting it. Two\nstandard mechanisms exist:
\nDPoP is generally preferred for agent-to-tool communication because it works over standard HTTPS without requiring certificate infrastructure at every tool server.
\nUse RFC 8693 (OAuth 2.0 Token Exchange) to derive capability tokens from agent session tokens. Key rules:
\nEvery tool call maps to a structured permission check:
\nsubject: agent-id / tenant-id \naction: github.issues.label \nresource: repo:acme-org/payments-service Verbs, resource IDs, and any contextual constraints (time of day, rate limits, spend thresholds) are all inputs to the policy engine.
\nRBAC (role-based access control) is sufficient when tool access maps cleanly to a small number of roles. It fails when:
\nIn those cases, fine-grained authorization (FGA) systems such as OpenFGA or AWS Cedar evaluate relationship graphs rather than flat role assignments.
\nPolicy must be evaluated by the tool server or a sidecar policy engine immediately adjacent to it. Evaluating policy inside the LLM prompt is not a security control; it is advisory text that a sufficiently crafted prompt can override. The tool server must return a structured allow or deny response with a reason code, regardless of what the agent was told to do.
Minimal policy schema:
\n{\n\"subject\": \"agent:a1b2/tenant:acme\",\n\"action\": \"github.issues.label\",\n\"resource\": \"repo:acme/payments\",\n\"decision\": \"allow\",\n\"reason\": \"policy:triage-agent-v2\"\n}Not every action requires human approval. A risk-scoring layer should route requests into one of three buckets:
\n| Ruleset | \nExample Condition | \nOutcome | \n
|---|---|---|
| Auto-allow | \nRead-only ops under rate limit | \nExecute immediately | \n
| Soft-hold | \nSpend > $10, first run of new tool | \nQueue for async approval | \n
| Must-approve | \nDelete op, cross-tenant data access | \nBlock until explicit approval | \n
Every approval or denial must be stored with: agent ID, tenant ID, action, resource, a hash of the input parameters, the approver identity, and a timestamp. This record is the chain of custody if an action is disputed later.
\nAPI keys, database credentials, and tokens must never appear in the agent’s context window. The correct pattern is: the agent calls a tool; the tool server fetches the secret from a vault and uses it server-side. The agent receives only the result.
\nBefore any agent-generated content is committed to a downstream system, validate it against a strict schema. Reject outputs that contain unexpected fields, executable content, or values outside allowed ranges.
\nAnti-patterns to avoid:
\nEvery tool invocation should produce a structured log event containing:
\nactor (agent ID + tenant ID)scope presentedaction and resourcePropagate a shared trace-id and span-id from the frontend through the backend, into the agent runtime, and into every tool server call. This makes it possible to reconstruct the full execution chain of a multi-step task in a single trace view. OpenTelemetry is the standard instrumentation layer for this.
Configure alerts on:
\n| Threat | \nControl | \n
|---|---|
| Prompt injection via tool output | \nSanitize tool outputs; treat them as untrusted data, not instructions. | \n
| Tool abuse / scope escalation | \nAllow-list tools per agent role; enforce at tool server. | \n
| Supply chain compromise | \nSign dependencies; maintain SBOMs; use runtime isolation (containers/VMs). | \n
| SSRF via agent-initiated HTTP calls | \nEgress allow-list on agent runtime network; block RFC 1918 ranges. | \n
| Data exfiltration | \nContent filters on outbound tool calls; canary data in sensitive datasets. | \n
| Token replay | \nDPoP or MTLS on all agent-to-tool calls. | \n
| Cross-tenant data access | \nTenant ID in every token claim; policy engine enforces isolation. | \n
SuperTokens supports custom session claims. Encode the following into the agent session payload:
\n{\n \"sub\": \"user:u123\",\n \"agent_id\": \"agent:a456\",\n \"tenant_id\": \"acme\",\n \"scopes\": [\"github.issues.read\", \"github.issues.label\"],\n \"task_id\": \"task:t789\",\n \"exp\": 1700000300\n}# Issue a short-lived capability token for one tool\ndef issue_capability_token(agent_session, tool_audience):\n claims = {\n \"sub\": agent_session[\"agent_id\"],\n \"tenant\": agent_session[\"tenant_id\"],\n \"aud\": tool_audience, # e.g. \"tool:github-triage\"\n \"scopes\": narrow_scopes( # only scopes valid for this tool\n agent_session[\"scopes\"], tool_audience\n ),\n \"exp\": now() + 120 # 2-minute TTL\n }\n return sign_jwt(claims, private_key)def validate_dpop_request(http_request):\n proof = parse_dpop_proof(http_request.headers[\"DPoP\"])\n token = parse_bearer_token(http_request.headers[\"Authorization\"])\n\n assert proof[\"htu\"] == http_request.url\n assert proof[\"htm\"] == http_request.method\n assert token[\"cnf\"][\"jkt\"] == thumbprint(proof[\"jwk\"])\n\n assert not replay_cache.seen(proof[\"jti\"])\n replay_cache.add(proof[\"jti\"], ttl=120)\n\n return evaluate_policy(token)def evaluate_policy(token):\n decision = policy_engine.check(\n subject=token[\"sub\"],\n tenant=token[\"tenant\"],\n action=current_action(),\n resource=current_resource(),\n scopes=token[\"scopes\"]\n )\n\n audit_log(token, decision)\n\n return decision # allow | deny + reasonThe triage agent may apply labels, assign issues, and post comments. It may not delete issues, push code, or modify repository settings. These boundaries are encoded in the capability token scopes, not in the system prompt.
\n# triage-agent-policy.yaml\nagent: github-triage\ntenant_scope: per_org\n\nallowed_actions:\n - github.issues.label\n - github.issues.assign\n - github.issues.comment\n\nrate_limits:\n per_hour: 200\n business_hours_only: false\n\nhitl_triggers:\n - action: github.issues.move_repo\n ruleset: must-approve\n - cost_usd_per_task: 5.00\n ruleset: soft-hold{\n \"event\": \"tool_call_denied\",\n \"agent_id\": \"agent:triage-01\",\n \"tenant_id\": \"acme\",\n \"action\": \"github.issues.delete\",\n \"resource\": \"repo:acme/payments#441\",\n \"reason\": \"action_not_in_allow_list\",\n \"trace_id\": \"4bf92f3577b34da6\",\n \"timestamp\": \"2025-11-01T14:23:07Z\"\n}| Phase | \nCapability | \nExit Criteria | \n
|---|---|---|
| Dev | \nFull access in an isolated sandbox | \nZero policy violations in 48h | \n
| Shadow | \nLive traffic; all actions logged but not executed | \nDeny rate < 1% | \n
| Read-only | \nRead operations only in production | \nStable for 5 business days | \n
| Partial write | \nWrites to low-risk resources; HITL on all others | \nApproval rate < 20% | \n
| Full write | \nFull-scoped write access; HITL on high-risk only | \nDeny rate stable; no anomalies | \n
Every agent deployment should have a per-tenant circuit breaker (disable one tenant’s agent without affecting others), a feature flag (disable globally in under 30 seconds), and a hard cost cap (agent halts if cumulative spend exceeds threshold within a rolling window).
\nLog the minimum necessary. Hash or truncate PII in audit logs. Define retention windows per data class, for example, 30 days for tool invocation metadata, 7 days for prompt/response hashes, and immediate deletion for any inadvertently logged credentials.
\nAttach a data_region claim to every agent session. Route token issuance, key storage, and audit log writes to region-specific infrastructure. Encryption keys should never leave their designated region.
Conduct quarterly reviews of all agent scopes and capability token definitions. Flag any scope that has not been exercised in 90 days as a candidate for removal. Automated scope-usage reporting from audit logs makes this tractable.
\nIdentity and Tokens
\nPolicy and HITL
\nObservability
\nThreats and Controls
\nTry the sample app: A reference implementation of agent-safe authentication by using SuperTokens, complete with scoped capability tokens, DPoP proof validation, HITL approval hooks, and a structured audit trail is available as a runnable repository. It demonstrates every pattern covered in this post in a single deployable stack.
\nBook 30-minute office hours: Teams designing agent authentication architectures from scratch can schedule a design review session to walk through token strategy, policy modeling, and HITL trigger configuration for their specific use case.
\nThe patterns described in this post, scoped capability tokens, sender-constrained transport, tool-server policy enforcement, and evidence-backed approvals, are the minimum viable security posture for any AI agent operating in a production environment with real data and real consequences.
","frontmatter":{"date":"March 22, 2026","title":"Authentication for AI Agents: Tokens, Tool Calls, and Human-in-the-Loop","cover":"auth-for-ai-agents.png","author":"Mostafa Ibrahim","description":"Secure AI agents with scoped tokens, DPoP, tool-level policies, and human approvals."},"fields":{"slug":"/auth-for-ai-agents/"}},"site":{"siteMetadata":{"title":"SuperTokens Blog"}}},"pageContext":{"id":"179a44ca-0f4c-58e3-865e-2a56629ae7f2","fields__slug":"/auth-for-ai-agents/","__params":{"fields__slug":"auth-for-ai-agents"}}}, "staticQueryHashes": []}