Credentials, Scopes, and Least Privilege

Every privileged call should trace back along a chain. A principal: the human, service, or organization whose authority is being delegated. An identity: a verifiable runtime or agent identity attached to the request. A scope, naming allowed resources, actions, destinations, and a time window. A credential broker, issuing or exchanging short-lived tokens after policy checks. And an audit trail, recording which principal, task, tool, and approval caused an effect. The broker and the trail are where ownership has to split, and the tests with it.

The last link is not a matter of house style. What an audit record has to contain was written down in 2020, as control AU-3 of NIST SP 800-53 Rev. 5. Five fields are the easy ones: what type of event occurred, when, where, the source of the event, and the outcome. Then a sixth, the "Identity of any individuals, subjects, or objects/entities associated with the event."

So the question to ask of an agent runtime is not whether it logs. It is whether all six fields can be filled in for a privileged tool call. Five of them a shared account answers well enough. The identity field it silently blanks, because every run produces the same answer.

Authentication establishes who or what is calling. Authorization determines which resources and actions are allowed. An agent runtime should exercise delegated authority through short-lived, task-scoped credentials rather than broad developer or service accounts.

This is not an emerging best practice for agents. It is an existing numbered control, and its wording already anticipates a non-human caller. Least privilege is control AC-6 of NIST SP 800-53 Rev. 5: "Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks." The parenthesis is the whole of the argument for agents. A process acting on behalf of a user is exactly what an agent runtime is. AC-6's discussion requires such processes to operate at privilege levels no higher than necessary. An agent handed a broad service account is not in a grey area of a control written for humans. It is out of compliance with a control written in 2020 that names its case.

The model should not receive raw secrets. Tools can hold credentials behind a policy boundary and expose only permitted operations.

The victim does one ordinary thing. They upload a document and ask for a summary. The document carries an invisible prompt-injection payload, set in 1px white font. The injected instructions tell ChatGPT to search the connected Google Drive for API keys, and to place them in the URL parameters of a markdown image hosted on Azure Blob storage. Rendering the image sends the keys to the attacker. The user clicks nothing.

That chain is AgentFlayer, a zero-click exfiltration attack on ChatGPT Connectors. Zenity Labs demonstrated it at Black Hat USA 2025 and published it on 6 August 2025. The researcher, Tamir Ishay Sharbat, puts the setup plainly: "So as attackers all we need to do is poison a document with an invisible prompt injection payload (as seen in the image below) and wait for someone to upload it into ChatGPT."

Read it against the chain in the first section. Nothing in this attack defeats authentication. The identity was genuine. The connector scope was genuinely granted. The credential behaved exactly as issued. What the attack exploited is the gap between the scope the connector held and the scope the summarization task needed: the whole of a connected Drive, against one document the user had just uploaded.

What an attacker gets when the model is confused depends on which credential the runtime handed over. There are three to choose between.

A shared service credential is one broad account reused across many runs: simple to integrate, large blast radius, weak attribution. A user-delegated credential has the runtime act inside the current user's permission set. Ownership is aligned, and it is the arrangement OWASP asks for when it requires actions to run in that specific user's context. It still needs consent and expiry, and it can still be overbroad. The AgentFlayer victim's Drive connector was delegated, and it held far more than a summary needed. A task-scoped capability is a short-lived token permitting one bounded operation: least privilege in the AC-6 sense, strong attribution, more infrastructure to build.

The difference shows up afterwards, in the record the call leaves behind. AU-3's identity field is the test. A shared service credential makes every call look identical, so nothing can be pinned to anyone. A delegated or task-scoped one lets a trace attribute every privileged action to a principal and task. And if the credential was pasted into the prompt at any point, the distinction stops mattering. The runtime is no longer the thing deciding what may be used.

Threat-model a single privileged tool. Ask what a confused deputy could reach through it, and how far. Work the chain in order: identify principals, separating end user, runtime, tool service, and resource owner; enumerate permissions across read, write, send, delete, approve, and administer; reduce scopes, binding access to named resources, destinations, amounts, and expiry; protect secrets, using brokers or backend integrations instead of model-visible credentials; and exercise revocation against expiry, user logout, policy change, and incident shutdown.

Two answers matter more than the rest. First, list every place the tool's credential is handled, and treat any prompt, system message or retrieved document on that list as a finding in itself. Second, check whether the record the call leaves behind names both the principal the work was done for and the task it belonged to. That is AU-3's identity field, filled in.

The revocation step has a worked example with dates on it. A threat actor obtained access to a Heroku database on 7 April 2022 and downloaded stored customer GitHub integration OAuth tokens; Heroku's own incident review supplies that date. GitHub Security opened its investigation five days later. Mike Hanley published the finding on 15 April 2022: "On April 12, GitHub Security began an investigation that uncovered evidence that an attacker abused stolen OAuth user tokens issued to two third-party OAuth integrators, Heroku and Travis-CI, to download data from dozens of organizations, including npm."

Count the days, then read the response. On 15 April 2022 Heroku revoked all existing tokens from the Heroku Dashboard GitHub integration and blocked new ones from being created. Mass revocation was the only move available. The tokens were long-lived, stored, and not scoped to any task that had since ended. That is what the revocation step asks a team to rehearse before it is needed: not whether revocation exists, but how much has to go at once when it is used in anger.

Credential design should assume the model can be confused by untrusted content. The goal is to limit what a confused deputy can cause. The confused deputy is not a figure of speech. Norm Hardy named it in 1988, and the incident he describes is older than the paper: he dates it to "about eleven years ago" at Tymshare, that is, around 1977.

A FORTRAN compiler sat in directory SYSX and was invoked as "RUN (SYSX)FORT". It had been marked with homefiles license so that it could write its statistics file, (SYSX)STAT. A user supplied (SYSX)BILL — the billing information file, in the same directory — as the name of the file to receive debugging output. The operating system allowed the write, because the compiler held the license. The billing information was lost.

Hardy's diagnosis is the sentence this whole lesson is a gloss on: "The fundamental problem is that the compiler runs with authority stemming from two sources." One source was the user's request. The other was the compiler's own standing license. Nothing in the call distinguished them.

An agent with a broad service credential is that compiler. The user's words supply the destination, the standing credential supplies the authority, and the system cannot tell which of the two it is obeying. Hardy's remedy is the third column of the comparison above: a capability that both designates the resource and authorizes the write, so that a request without the capability cannot name a target it was not given.

Two rules follow. A secret in model context is already outside the security boundary, so credentials belong to the runtime that makes the call and never to the text the model reads. And every grant should leave a record specific enough to name the principal it acted for and the task it served — AU-3's identity field is the minimum, not the aspiration. A permission nobody can attribute is a permission nobody can withdraw.