An AI agent credential is a secret the agent can present to make something happen: an API key, an access token, a private key, a database password, a session cookie. It is what converts the agent's text output into an effect on a real system. That makes a credential authority rather than identity. Identity says which party is calling. Authority says the call will be honoured. An agent that holds a credential is entitled to every action that credential covers, at any moment, for any reason, including a reason an attacker supplied.
What counts as a credential here?
Anything a system accepts as sufficient. The obvious cases are keys and tokens. The less obvious ones matter more in practice:
- A browser session the agent drives, already logged in as a human.
- A tool or plugin that holds the key on the agent's behalf and will call the API whenever the agent asks.
- A CI token, a cloud role assumed by the process the agent runs inside, or an instance credential the agent can read from a metadata service.
- A signed URL, a webhook secret, an SSH key on the same disk.
If the agent can cause an effect without any further decision, something in its reach is a credential, whether or not anyone called it one.
Why is a credential authority rather than identity?
Because most credentials are bearer credentials. The OAuth specification states the property plainly: "any party in possession of a bearer token (a 'bearer') can use it to get access to the associated resources (without demonstrating possession of a cryptographic key)" (RFC 6750, section 1.2). The token does not know who is holding it, and the resource server cannot tell.
Two families of standard exist to weaken that property. Certificate-bound tokens tie a token to the client certificate used to obtain it (RFC 8705), and DPoP binds a token to a key the client proves it holds on every request (RFC 9449). Both defeat a stolen token used from somewhere else. Neither helps when the legitimate holder is the problem, because the agent still holds the bound key and still makes the request itself. Sender constraint answers theft. It does not answer misuse.
What does an attacker get from an agent that holds credentials?
Everything the credential covers, without an exploit. A prompt injection is text: content the model reads and treats as instruction (MITRE ATLAS AML.T0051). If the injected instruction reaches an agent holding a key, the attacker does not need to escalate, pivot or bypass anything. The agent makes the call, with its own authority, and the target system sees a normal authenticated request from a component it trusts.
OWASP describes the same shape as excessive agency and recommends limiting the functions, the permissions and the autonomy an agent holds (LLM06:2025). Saltzer and Schroeder had already stated the underlying principle: least privilege, where "every program and every user of the system should operate using the least set of privileges necessary to complete the job" (Saltzer and Schroeder, section I.A). The hard part is that an agent's job is not fixed, so its necessary privilege set is not either.
What do the usual mitigations actually do?
| Measure | Real effect | What it still allows |
|---|---|---|
| Scoped keys, one per system | Caps the reachable surface per key | Every action inside the scope, including the destructive ones |
| Short-lived tokens | Shortens the window a leaked token is useful (SP 800-57 Part 1, cryptoperiods) | The live agent has a valid token at all times, by design |
| A vault or secrets manager | Removes secrets from source and disk, centralises rotation | The agent still fetches and holds the secret at runtime |
| A credential broker or just-in-time issuance | Narrows the grant to a task and a window | The broker answers the agent, so a misled agent asks and receives |
| An egress proxy or allowlist | Restricts destinations and endpoints | The permitted endpoint is usually the one worth abusing |
| Read-only by default | Removes write paths entirely | Exfiltration, which needs only reads plus one outbound channel |
Each of these is worth doing. None of them changes the fact that the deciding component is the agent. Vaulting a key is not removing it: it moves where the key rests, not who spends it (NIST SP 800-53 Rev. 5, IA-5 and AC-6).
Where does credential hygiene fail in agent systems?
- Human accounts lent to automation. An agent driving a logged-in browser or reusing an employee's session inherits a person's entitlements and makes attribution impossible.
- Ambient credentials. Cloud instance roles and environment variables are readable by anything in the process, including a tool the agent was talked into running.
- Scope creep during integration. Permissions are widened to unblock a demo and never narrowed, because nothing fails when they stay wide.
- Rotation without revocation. A new key is issued and the old one keeps working.
- Logs and traces. Prompts, tool outputs and error traces are stored in systems with a wider readership than the secret had.
- The agent as a deputy. A component that will act for whoever asks it converts a text-level compromise into a privileged action, which is the problem agent authorization exists to answer.
How does ZIFFER keep the credential away from the agent?
ZIFFER moves the credential to a component the agent does not control. The agent proposes; the executor on your side verifies a signed receipt and only then acts with your credential, so a compromised agent can compose any proposal it likes and still holds nothing that causes an effect. The zone drawing and the boundary it hangs on are in how it fits your stack, which also states the condition: this covers an agent only where that agent holds no credential of its own. An agent with an API key in a config file is outside the wall until the key is revoked. What happens to the actions nobody should take alone is covered in human oversight for AI agents, and the reason a text-level attack cannot be filtered away is in prompt injection in AI agents.