Agent Identity, Authorization, and Secrets Management

The starting point of identity and access control is a seemingly simple but easy-to-skip question: why can't a natural language sentence like “I represent the user” open a door like an access card?

An access card can open a door because it carries verifiable cryptographic credentials: it is bound to a subject, specifies the areas that can be entered, and has an expiration date. The sentence “I represent the user” has none of these properties. The model's job is to interpret content and propose “what to do next”; its output is a candidate action. The identity system's job is to use login sessions, certificates, or workload identity to prove “who this request actually comes from.” The authorization system's job is to determine, based on policy, “whether this subject can now perform this action on this object.” These are three independent steps, each answering a different question: intent answers “what do you want to do,” identity answers “who are you,” and authorization answers “what are you allowed to do.”

Natural language cannot serve as authorization evidence because it can be forged, relayed, repeated by others, and directly rewritten by Prompt Injection. A single sentence contains no cryptographically meaningful subject, no clearly specified audience, and no expiration date: it can neither prove who the speaker is nor restrict which resources the sentence can act on or within what time frame it takes effect. Therefore, treating model-generated text as an access credential is like treating a note that anyone can alter as a key.

The most common dangerous leap happens here: from “the user wants to fix an issue,” one directly infers that “the Agent can read all repositories,” and then further infers that “it can make repositories public and publish.” These three propositions belong to three different sets—business goal is “what the user wants to achieve,” technical capability is “what the system can do,” and this authorization is “what this request is allowed to do.” There is no logical containment relationship among them. “Wanting to fix an issue” describes the business goal; “reading all repositories” is a technical capability far beyond what that goal requires; “making repositories public and publishing” is a high-risk action with external consequences that must be explicitly allowed in the authorization set before it can be executed. The correct approach is to intersect these three sets one after another, rather than assuming they cover each other by default.

The value of an identity and access control system lies precisely in separating the model's intent from real-world execution permissions. Its inputs are: user goal, verifiable subject, candidate action, target resource, and context; its outputs are only three: allow, deny, or pause. The system first authenticates “who it is,” then authorizes “what it can do,” and finally intersects the sets for this delegation to obtain the actions actually allowed for this request. Natural language in this chain can only propose candidates and can never become the access credential itself.

When a request has to traverse multiple services, the real question is no longer "Is this a legitimate request?" but "After layer upon layer of forwarding, can the chain of who represents whom still be traced?"

To draw this chain clearly, it is necessary to first distinguish the four types of subjects involved in a request: the end human user, the AI Agent session that carries the user's intent, the execution workload that actually makes network calls and accesses resources, and the resource server that holds the resources and makes the final decision. These four are not equivalent; as requests pass between them, each step involves a transfer or constraint of identity. Figure 1 explicitly expresses this relationship using two chains: the delegation chain explains 'whom this action represents'—the user delegates intent to the AI Agent session, and the session delegates execution tasks to the workload; the execution chain explains 'who actually accessed the resource'—the one actually touching the resource server is the execution workload, not the user who originally spoke. The two chains point to different subjects; confusing them leads to errors in authorization decisions.

The necessity of this distinction is most starkly illustrated by the common practice of shared bot accounts. Many systems have all AI Agents share a single technical account named "bot" to call APIs. On the surface, requests pass authentication, but in reality this erases both chains at the same time: the logs only contain "bot successfully called API", and no one can explain which user initiated this call, which task session delegated it, or which workload executed it. If a shared account has a problem, permission revocation can only be done as a blanket block, not precise revocation for a specific user; when an incident occurs, attribution to a specific responsible person is impossible; and for safety, shared accounts are often granted overly broad permissions, violating the principle of least privilege. Therefore, shared bot accounts are legitimate at the authentication level but unusable at the audit level.

An auditable log must be able to answer six questions: which user, through which task session, by which workload, calling which tool, accessing which version of which resource, and what the result was. Recording only "bot successfully called API" has no audit value because it lacks the critical links in the entire subject chain.

The input to this subject chain is the four types of subjects—user, AI Agent session, execution workload, and resource service—and the output is a traceable delegation chain and audit chain. Its operating sequence is: the user first delegates intent to the session; the execution gateway exchanges narrower-scoped credentials between the session and the workload, compressing "all the permissions the user has" into "only the permissions this task truly needs"; the resource service receives the narrower credential and makes the final decision; finally, the complete path from subject to result is written to the log. The reason shared bot accounts are excluded from this design is that they represent only a technical identity, cannot explain who represents whom, and cannot support precise revocation.

Authentication, authorization, delegation, and audit are often conflated as synonyms, but each answers an independent question, and when any one is missing it leaves a vulnerability of a fundamentally different nature.

Authentication answers “Who are you?” It confirms the requesting subject through evidence such as user sessions and execution service workload identities; when missing, the system cannot confirm who the request actually comes from. Authorization answers “What can you do?” It judges, based on policy, whether an authenticated subject can perform a specific action on a specific object, such as read-only issues, write branches, and deny public repositories; when missing, a subject that has already been authenticated can perform operations it should not have performed. Delegation answers “Whom do you represent, and why can you do this now?” It limits the service to act according to which user-approved task, on which repository, and within what validity period; when missing, the service's own permissions may be mistaken for user consent, and the service can use its own identity to impersonate user consent. Audit answers “What actually happened?” It records session ID, action, resource, policy decision, and result; when missing, even if an incident occurs, it is impossible to attribute, investigate, or precisely revoke for a specific subject.

In the running case, the evidence for these four is different: the evidence for authentication is user sessions and execution service workload identities; the evidence for authorization is policies such as “read-only issues, write branches, deny public repositories”; the evidence for delegation is “user-approved task, repository A, validity period”; the evidence for audit is “session ID, action, resource, policy decision, result”. The four gather evidence independently, which shows that they cannot replace one another.

There are two most common substitution misconceptions to correct. First, successful authentication is only an input to the authorization decision, not a credential to “access all resources”—confirming who you are never means confirming what you can do to each resource. Second, audit cannot replace prevention: the fact that a leak can be found in logs afterward does not mean a blocking mechanism stopped it before it occurred. Audit is a retrospective capability, prevention is an interception capability; no matter how complete the former is, it cannot compensate for the absence of the latter.

Taken together, the inputs and outputs of these four are clear: authentication takes subject evidence as input and outputs an authentication result; authorization takes policy and subject as input and outputs an authorization decision; delegation takes a task delegation as input and outputs a limited delegation scope; audit takes events that occurred as input and outputs traceable records. The four are complementary but cannot replace each other: successful authentication does not mean access to all resources, and after-the-fact audit cannot replace prior blocking.

"What an Agent can do" cannot be answered with a broad role name like "administrator" or "write permission", because a role name is just a rough label that obscures the boundaries that different layers each tighten. Truly executable authorization should be a set that can be intersected layer by layer and directly determined by a computer.

Effective permission E is defined as an intersection:

E = User delegation ∩ Agent policy ∩ Tool policy ∩ Resource policy ∩ Context allowed set

The constraint rule of this formula is: each layer can only narrow, not expand, the upstream delegation. The user delegation gives the upper bound allowed for this task; the Agent policy, tool policy, and resource policy can only further restrict within this upper bound; no layer has the authority to arbitrarily enlarge the authorization from a higher layer. The context allowed set incorporates dynamic conditions into the calculation, including session risk, target repository, target branch, time window, network destination, data sensitivity level, and the manual confirmation state of "whether someone has confirmed".

Applying this intersection to concrete actions shows five typical results. Read issue of repository A: user explicitly allows, resource set locked to A, action locked to read, and delegation not expired; all three layers are satisfied, result is allow. Create a new fix branch in repository A: this is required for preparing a patch; policy gives write:branch and prohibits writing to main, which falls within the intersection; result is allow. Read repository B: user explicitly denies, resource B is not in the resource set; result is deny. Make repository A public: this delegation has no public operation at all, and admin permission does not exist; result is deny. Publish fix: policy requires asking the user first, but this time confirmation is missing; result is pause—not allow or deny, but stop and wait for additional confirmation.

This intersection model also implies a default deny principle. Any resource that cannot be uniquely resolved, any parameter added by the model on its own, or any target domain derived from untrusted content must not be "guessed as a reasonable value" and then executed. The reason is that a parameter change changes the authorization target: for the same action, if the target resource changes from A to B, it leaves the original intersection and must be re-intersected. Therefore, when the intersection is empty or the object cannot be uniquely resolved, the default result is deny; the model must never fill in a seemingly reasonable default value for the system.

The inputs to the entire computation are the user delegation, Agent policy, tool policy, resource policy, and current context; the output is the set of actions that fall within the intersection of these sets. Each layer can only narrow the upstream scope; once a parameter or resource changes, the intersection must be recomputed; when the intersection is empty or the object cannot be uniquely resolved, the default is deny.

A delegation, from the user’s click to confirm through the resource server actually executing it, does the same thing at every step: prevent permissions from being amplified as they flow. Using “fix issue in repository A” as an example, you can trace this chain in chronological order.

The first step is to establish the task. After logging in, the user selects repository A, explicitly authorizes “read issue, write new branch,” and sets an expiration of 20 minutes. The service records an immutable task ID for this task. This ID is the common anchor for all subsequent checks; the delegation scope and time limit are fixed from this point onward.

The second step is model proposal. The AI Agent outputs a structured action, create_branch(repo=A, name=fix-42). Note that this output itself carries no secret; it is only a candidate action and has not yet obtained execution eligibility.

The third step is policy checking. The gateway checks the user delegation, action, resource, session risk, and remaining validity together: whether the action falls within the delegation scope, whether the target repository matches, whether the session risk is acceptable, and whether the validity period is still current. If any of these is not satisfied, the request ends here.

The fourth step is credential exchange. Based on this, the gateway obtains a short-lived token that is only for the code hosting API, contains only the single permission scope repo:A:branch-write, and expires in 5 minutes. The token’s scope is minimized and does not inherit the user’s full permissions.

The fifth step is tool execution. Trusted code injects the token only at the moment the request is actually sent, rather than letting the token reside long-term in the model or session context. After receiving it, the resource server independently checks again: whether the signature is valid, who issued it, whether the audience matches, whether the scope covers the action, whether it has expired, and whether the repository is correct.

The sixth step is record and discard. Logs store only the token fingerprint rather than the token value, and also record the policy version and resource operation result. The token remains in the execution layer; the model can only see the redacted result and never comes into contact with the token itself.

The value of this mechanism can be quantified through blast-radius calculation. Suppose a shared administrator secret is leaked; the attacker could access 200 repositories with long-term validity. In contrast, the task token covers only 1 repository, 1 type of action, and 5 minutes. The permission resource surface shrinks from 200 to 1, and the duration window shrinks from “until the secret is manually rotated” to 5 minutes. This does not reduce leakage risk to zero—the token can still be stolen—but it turns the worst-case loss into a bounded quantity: the worst case shrinks from “indefinite access to 200 repositories” to “branch-write capability for 1 repository within 5 minutes.”

The inputs to the entire chain are the task delegation for repository A, the structured branch-creation action, and the session risk; the outputs are a five-minute token scoped only to the target API, repository, and action, plus the audit result. After the gateway validates and exchanges the credential, the token is injected at the last hop during execution, and the resource service checks again. A short-lived narrow token reduces the blast radius; it neither eliminates leakage risk nor authorizes out-of-scope actions such as publishing.

Why can a validly signed OAuth or JWT token still be rejected by the resource server? Because signature verification answers only one question: whether the token content has been tampered with by an unknown third party. It does not answer whether the token is applicable to the current request. A valid signature is only a prerequisite; the resource server must still check item by item whether the context between the token and the current request matches, and reject any mismatch.

The first is issuer: confirm that the token comes from a trusted authorization server. If you verify only the signature and not the issuer, an attacker can create their own issuer and use a valid token they signed to impersonate the authorization. The second is audience: confirm that the token is actually issued to this API. If you pass a token issued to Service A to Service B, the signature is still valid, but the audience does not match and it must be rejected. The third is scope: confirm that the current action falls within the permitted set. Taking a read token to write to main, the signature is unchanged, the action is out of bounds, and it is also rejected. The fourth is resource or tenant: confirm that the operation target belongs to this delegation. A token issued for repository A used to access repository B has a mismatched object and is rejected. The fifth is time and revocation: confirm that the token has expired or been revoked. Replaying a token left by an old task, even if the content is unchanged, will be rejected due to expiration or revocation. The sixth is sender or session binding: confirm that the token has not been stolen by another workload. Stealing an unbound bearer token and calling from a different location is theft and should be rejected.

These six checks respectively prevent six categories of problems: accepting an attacker-created issuer, passing A's token to B, using a read token to write to main, using a repository A token to access repository B, replaying old tokens, and stealing a bearer token to call from a different location.

This leads to an important prohibition: token passthrough. Passing an upstream user's token unchanged to an unknown downstream service simultaneously breaks the audience boundary, leaks capabilities, and creates a 'confused deputy' — the downstream service may use the upstream token to access resources it should not access, and the resource server will mistakenly believe this is the user making a direct request. When cross-service access is needed, use explicit token exchange, or let the downstream service independently obtain its own authorization, so that each resource server receives only credentials issued to itself, not the upstream's original token.

The inputs to token validation are signature, issuer, audience, scope, resource, time, and sender binding; the output is only accept or reject. The signature only proves that the content has not been tampered with by unknown parties, not its applicability; an upstream token also cannot be passed through unchanged to an unknown downstream.

Since the model will eventually call APIs, putting the key directly into the system prompt seems like the easiest option. But the reason this shortcut is not viable is not about convenience; it is that once a key enters the model context, it falls into a range the system can no longer control.

In the model's input-output pipeline, prompts, tool results, error stacks, and retrieved memory may all be output, logged, compressed, or affected by prompt injection. Once a key becomes a token in the context, the system can hardly guarantee that it will not appear in answer text, will not be written into logs, or will not be copied by the model into another tool's parameters. That is, the moment a key enters the context, confidentiality is no longer assured.

The correct approach is to remove keys entirely from the model's visible world. Keys are stored in a dedicated secrets manager; the execution gateway reads them on demand using workload identity; trusted code injects the key at the last hop of the network request; the model only ever sees tool schemas and redacted responses, never the credentials themselves. Logging is likewise isolated: only credential IDs, versions, and fingerprints are stored, never values. Credentials must also be isolated by environment, tenant, tool, and task, and not use a single master key everywhere. Secrets management must also support rotation, revocation, monitoring for abnormal frequency and abnormal locations, and automatic expiration. Error messages must also be cleansed, removing Authorization headers, cookies, signed URLs, and connection strings that could leak.

But two levels must be distinguished. "Hiding the key" only addresses confidentiality; it ensures that the value is not leaked. Even if the value is never leaked, if the execution gateway itself is too broad, the model can still use the gateway's permissions to perform out-of-scope actions—for example, if the gateway has write permissions far beyond what this task needs, the model can trigger operations that should not happen under a legitimate credential injection flow. Therefore, secrets management must coexist with action authorization: the former decides that "credentials are not leaked," and the latter decides that "even if credentials are usable, they can only do things within scope." Neither is dispensable.

The inputs to secrets management are key identifiers, workload identity, target tools, and least-privilege action permissions; the output is the credential injected at the last hop by a trusted executor. The model only sees schemas and redacted results; logs only record fingerprints and versions. Secrets not entering the context can reduce the risk of copying and leakage; but an overly broad execution gateway can still be borrowed by the model to perform out-of-scope actions, and this layer must be backstopped by action authorization.

When an untrusted issue comment successfully induces the model to propose “access repository B, make the repository public, publish immediately,” which independent defenses remain in the security system? The answer is: even if the model is completely manipulated, there is still an entire execution chain behind it that blocks it layer by layer.

The first line of defense lies between model output and actual delegation. Model output is only a candidate action proposed by the Agent session, not a user-signed confirmed delegation; it has no execution authority in itself. The second line of defense is at the execution gateway: the gateway breaks down the candidate action into four fields—subject, action, resource, and context—and evaluates them by substituting them into the permission intersection. The third line of defense is the intersection computation itself: repository B is not in the delegated resource set and the admin action is not in the intersection, so it is rejected immediately; the publish action lacks this confirmation, so the result is not allow but pause—the system stops and waits, rather than guessing a reasonable value for the model. The fourth line of defense is at the credential layer: even if an action is approved, it only obtains short-lived, narrow-audience, narrow-scope credentials, and the resource server verifies again. The fifth line of defense is at the secrets layer: keys never enter the model, the attack text cannot directly copy credentials, and the audit chain supports post-incident attribution and precise revocation.

Taken together, the security goal has never been “the model is never deceived.” The model can be induced by untrusted content; this is the nature of language models and cannot be eradicated through identity and access control. A more realistic goal is: even if the model is completely induced by untrusted content, it still cannot cross the execution layer’s five boundaries—resource, action, audience, time, and confirmation. The model can “think incorrectly,” but incorrect thinking cannot become unauthorized execution.

The inputs to the prompt injection defense are manipulated candidate actions, user delegation, policy intersection, and resource-side checks. The outputs are only three types: unauthorized actions are rejected, actions requiring confirmation are paused, and in-scope actions are executed with narrow permissions. What it can guarantee is that the execution layer is not penetrated by the induced result. At the same time, it is necessary to recognize the boundary of this defense: it only covers policies that have already been configured; if the policy itself is written incorrectly—for example, the resource set is configured too broadly, or a high-risk action is omitted—then the execution layer will faithfully allow it according to the wrong policy. Therefore, these boundaries can only constrain “configured” permissions; incorrect policies themselves must be discovered and corrected through testing and auditing.