Designing authentication and authorization for AI agents — incorporating permissions and delegation into custom projects

"What permissions is this AI agent running under?"—Getting asked this by a client's security team leaves many at a loss for words. Looking into it reveals that the agent integrated into an internal tool was simply using the operator's personal admin API key. Opening the audit logs shows only the operator's ID, making it impossible to distinguish when and which operations were performed by human hands versus automated agent executions. Even if traces of impersonation exist, they cannot be isolated, and the agent continues running with excessive privileges. This scenario is quietly proliferating when integrating agent capabilities in custom development.

The root of the problem lies in forcing agents into identity and service authentication frameworks built under the assumption of humans. Agents do not log in on screen each time like a human, nor do they run silently with fixed responsibilities like traditional batch jobs. They make decisions on behalf of users, invoke other tools or agents, and exercise further permissions down the line. This property of "acting chained as someone's delegate" clashes with existing access control models. InfoQ's June 2026 report, AI Agent Identity and Permission Challenges (InfoQ), begins with this exact realization—that agents do not fit into identity models made for either humans or services—and details how Uber and Auth0 are redesigning their models. Using those directions as a guide, this article translates authentication and authorization design into practice from the standpoint of implementing and maintaining agents in custom development.

Why "Using the Same Key as the Operator" Becomes a Liability

Handing an operator's API key or admin permissions directly to an agent is convenient initially and works right away. The problem is that as operations mature, the following three consequences become severe:

First, excessive privileges. Human operators often hold broad permissions "just in case," and the agent inherits them entirely. Even when a task merely requires reading a specific database table, it can perform writes, deletions, and administrative actions on external systems. If the agent is manipulated through prompt injection or goes off course due to unexpected input, the blast radius expands to match those broad privileges. Auth0 terms this "excessive agency" and emphasizes tightening access starting from the Principle of Least Privilege (PoLP) (Mitigate Excessive Agency in AI Agents (Auth0)).

Second, inability to audit. Because it runs under the operator's ID, logs record only the operator's name. Investigating an incident or data leak after the fact leaves no structured record of whether an action was performed by a human or automated by an agent, or which user request initiated the run. In custom development, this "inability to trace the execution path" translates directly into a lack of accountability.

Third, risks of impersonation and credential reuse. Once leaked, long-lived API keys or shared tokens can be used by anyone, indefinitely. If the same token is reused across multiple agents, a token stolen via one path will succeed across another, making it impossible to determine where the breach originated.

In summary, fitting agents into existing frameworks breaks down as follows:

The third approach—treating them as Non-Human Identities (NHIs)—is the direction both Uber and Auth0 are pursuing. Giving agents unique identities and task-scoped permissions rather than human hand-me-downs or shared keys is the fundamental prerequisite of this architecture.

Granting Agents a "Unique Identity" and "Minimal Scope"

Rather than introducing tools, the very first step is to register the agent as an independent entity. Issue a unique ID per agent (or per agent role) and manage the permissions associated with it entirely separately from human permissions.

From there, restrict permissions per task. Rather than "this agent can do anything," narrow it to: "this agent can perform only these specific operations on these specific resources for this specific user's request." In OAuth terms, instead of issuing broad scopes all at once, fine-grained scopes matching the task are issued only when needed. Auth0 describes this as "scoping tools with task-based authorization rather than broad API access," recommending that agents hold their own scoped credentials rather than inheriting tokens from the user (Access Control in the Era of AI Agents (Auth0)).

Representing scope design roughly in pseudocode looks like this. Instead of passing broad roles in a single stroke, explicitly enumerate what can be read, what can be written, and which external APIs can be invoked for each agent role.

# エージェントの役割定義（最小権限の例）
agent:
  id: agent-invoice-summarizer        # 人間とは別系統の固有ID
  scopes:
    - invoices:read                   # 請求データの読み取りのみ
    - reports:write                   # レポート出力先への書き込みのみ
  forbidden:
    - invoices:delete                 # 削除は決して許可しない
    - admin:*                         # 管理操作は範囲外
  human_in_the_loop:
    - payments:execute                # 支払い実行は人間の承認が必須

The crucial element here is explicitly defining forbidden and human_in_the_loop. While following the principle that "anything not on the allowlist is forbidden," irreversible operations such as payments, deletions, and external transmissions must require human approval, even if technically permissible within the scope. Auth0 implements this human-in-the-loop approval via Client-Initiated Backchannel Authentication (CIBA), issuing an operation-scoped token only upon approval; if rejected, no token exists and the tool cannot execute. This cleanly separates giving agents the "freedom to think" from strictly gating their "permission to execute."

This philosophy of avoiding permanent broad permissions is not unique to agents. It directly mirrors replacing permanent SSH access to production servers with auditable job executions, continuing the governance principle of eliminating personal, static access explored in our article on eliminating static SSH in favor of job execution.

Representing "On Whose Behalf It Acts" via Delegation

The complexity of agents stems from the fact that they almost always act on someone else's behalf. When an agent receives a request from User A, it invokes other tools or subagents, which then execute further operations downstream. If the context of "Agent B is executing this originating from User A's request" is lost when finally accessing the resource, both authorization decisions and audit logging collapse.

The mechanism to represent this is delegation (on-behalf-of). As an open standard, OAuth 2.0 Token Exchange (RFC 8693) handles this delegation directly. It differentiates the original subject (User A) from the acting entity (Agent B) within the token. The act claim indicates who is acting on whose behalf, while the may_act claim defines who is permitted to act on behalf of that subject.

# RFC 8693 のトークン交換のイメージ（委任の表現）
{
  "sub": "user-a",                 # 本来の主体（依頼した利用者）
  "act": {                         # 代理で動いている実行主体
    "sub": "agent-invoice-summarizer"
  },
  "scope": "invoices:read reports:write",
  "aud": "billing-api",            # このトークンが通る相手を限定
  "exp": 1750300000                # 短い有効期限（数分〜十数分）
}

Uber's published architecture expands this concept to multi-hop agent orchestration. According to their blog post Solving the Identity Crisis for AI Agents (Uber) and the InfoQ report mentioned earlier, Uber uses a Security Token Service (STS) as a trust broker to issue short-lived JWTs at every hop of an agent workflow. Each token is scoped to its destination and short-lived to resist replay attacks. Crucially, it embeds an attested actor chain running from the originating human through intermediate agents, rather than just the immediate caller. This allows downstream resource gateways to evaluate authorization by examining both who originated the request and which agent is currently executing it. At Uber, an MCP (Model Context Protocol) gateway handles this verification and authorization, reportedly processing around 60,000 task executions per week at the time of reporting. While not directly portable to small-and-medium client projects at that scale, the principle of embedding the delegation chain into tokens in an auditable manner applies regardless of project size.

Standardization discussions for agent-specific delegation are also underway within the IETF, with draft OAuth extensions submitted for AI agents obtaining tokens on behalf of users. However, as of June 2026, these remain unfinalized drafts, so establishing designs on proven RFC 8693 and OAuth 2.1 foundations while monitoring draft developments is the practical approach. When agents invoke external APIs, the authorization server concepts covered in our article on OAuth 2.1 authentication for MCP servers serve as the direct baseline for delegation design.

Operationalizing Short-Lived Tokens and "Agent-Dedicated Credentials"

Even with delegation represented, governance breaks down if token lifetimes and storage are handled sloppily. The design rests on two pillars: keeping tokens short-lived, and never exposing raw credentials to the agent body.

Short-lived tokens narrow the window of vulnerability if leaked. While a compromised long-lived API key can be exploited indefinitely, a token expiring in minutes limits exposure time and impedes replay attacks. This is why Uber issues short-lived JWTs at every hop. In custom development, rather than treating this merely as tuning a TTL value, architect the full pathway for automated refresh upon expiration and revocation. If an agent goes rogue, lacking a kill switch to immediately revoke its ID and invalidate all active tokens undermines both least privilege and short-lived tokens.

To avoid giving raw credentials to the agent, placing a token storage and exchange layer outside the agent—similar to Auth0's Token Vault—provides a valuable model (Auth0 Token Vault (Auth0)). When an agent invokes an external service (such as enterprise SaaS) on behalf of a user, the agent does not retain the external service's refresh token. At runtime, it requests a token from this layer for the specific operation and user, receiving a user-bound, non-reusable access token. This prevents raw credentials from leaking into LLM contexts or client-side code.

Audit logging delivers true value only when tying these components together. At a minimum, capture the following three items in a structured format:

{
  "timestamp": "2026-06-19T10:23:11Z",
  "principal": "user-a",            // 起点の利用者
  "actor": "agent-invoice-summarizer", // 実行したエージェント
  "actor_chain": ["agent-orchestrator", "agent-invoice-summarizer"],
  "action": "invoices:read",
  "resource": "billing-api/invoices/2026-06",
  "decision": "allow",              // 認可の結果
  "token_id": "jti-7f3a...",        // 失効・追跡用のトークン識別子
  "human_approval": null            // 人間承認が要る操作なら承認者を記録
}

The key is recording principal (who requested it) and actor (who executed it) in separate fields. The opening dilemma where humans and agents could not be distinguished in logs occurred precisely because these two were conflated. Separating them allows you to present the client's security team with a clear, retrospective breakdown of who initiated the request, which agent acted on it, when, and what it did.

Pitfalls When Integrating Agents in Custom Development

In an internal business system custom development project supported by GleamHub (for a wholesale business, name withheld), the existing agent implementation handed to us directly used the operational manager's admin token. While working without issues in demos, a security audit flagged it: "Agent operations and human operations appear identical in logs, representing excessive privilege," stalling the production rollout.

Rather than a total rewrite, we chose a phased migration. First, we assigned the agent a unique ID, severed the inheritance of admin privileges, and issued only the scopes required for each task. Next, instead of using the operator's key directly, external SaaS calls were transitioned to retrieve user-bound tokens at runtime, removing raw credentials from the agent body. Finally, we inserted human approval steps exclusively for payments and data deletions, recording principal and actor separately in logs. We did not deploy an extravagant platform overhaul; we simply re-implemented human-centric governance with the rigor required when the actor becomes a machine. Consequently, the audit findings were resolved and production rollout resumed.

The most valuable lesson from this project was that retrofitting authentication and authorization after completing agent implementation is expensive. Crafting prompts and tool integrations first and trying to constrict permissions later requires stripping away broad privileges the agent implicitly relied upon, making it impossible to predict what might break during regression testing. Defining permissions upfront—clarifying on whose behalf the agent acts, what it can do, and to what extent—and aligning implementation to that spec proves faster in the end.

Another pitfall is focusing solely on the individual agent. In practice, if you lack visibility into which departments run which agents and for what purpose, loopholes remain regardless of how tightly individual agents are secured. Establishing organizational visibility over active agents directly mirrors the "visibility before prohibition" principle from our article on cloud AI governance and shadow AI, with authentication and authorization in this article representing the layer immediately beneath it.

Where to begin

Integrating agents into business workflows is an inevitable shift. The problem lies in operating them while shoehorning them into identity frameworks built for humans or services. The guiding principles are simple: grant agents unique identities, express on whose behalf they act via delegation, restrict permissions to tasks, keep tokens short-lived, and record humans and agents separately. Large-scale implementations like Uber and Auth0 differ in scale, but point toward these exact principles.

As a first step, we recommend tracing which IDs and permissions currently power active agents across your organization or vendors. If you find even a single path reusing an operator's personal key, that is where work should begin. From there, prioritizing whether to issue unique IDs or minimize scopes based on the irreversibility of operations will clarify your execution path.

If you are evaluating how to weave agent authentication and authorization into existing custom systems, or need to overhaul the permission design of an inherited implementation, reach out via the GleamHub contact form. After reviewing your current agent architecture and permission flows, we will collaborate with you to reconstruct your delegation, scoping, and audit logging.

Sources

• AI Agent Identity and Permission Challenges: How Uber and Auth0 Are Rethinking Access Control － InfoQ
• Solving the Identity Crisis for AI Agents － Uber Blog
• Access Control in the Era of AI Agents － Auth0 Blog
• Mitigate Excessive Agency in AI Agents with Zero Trust Security － Auth0 Blog
• Auth0 Token Vault: Secure Token Exchange for AI Agents － Auth0 Blog
• RFC 8693: OAuth 2.0 Token Exchange － RFC Editor