An AI agent that holds a credential can be made to spend it. With ZIFFER, the agent holds no credential. It proposes an action instead. Your policy grants, holds or refuses the proposal. Your own code performs a granted action with your own credential, after it verifies a signed receipt. A hijacked agent can still propose anything. It holds nothing that causes an effect.
The rest of this page is the argument for that design. A credential is authority, not identity. The standard protections make a credential harder to steal, and none of them stops the legitimate holder from being misled. Both facts point to the same answer: take the credential out of the agent.
What counts as a credential for an AI agent?
A 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 converts the agent's text output into an effect on a real system. In practice the less obvious cases matter more:
- 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.
The test is simple. 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?
Identity says which party is calling. Authority says the call will be honoured. Most credentials are bearer credentials, so holding one is enough. 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 weaken that property. Certificate-bound tokens tie a token to the client certificate used to obtain it (RFC 8705). 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. The target system sees a normal authenticated request from a component it trusts.
OWASP describes the same shape as excessive agency. It recommends limiting the functions, the permissions and the autonomy an agent holds (LLM06:2025). Saltzer and Schroeder had already stated the 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 fixed either.
Do ephemeral credentials or a credential broker fix it?
They reduce the damage. They do not change who decides.
| 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 |
| Ephemeral, 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 |
| Credential brokering 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 does not remove 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 management 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. That is the problem agent authorization exists to answer.
How does ZIFFER keep the credential away from the agent?
It moves the credential to a component the agent does not control. The agent sends a typed proposal: one action, its target and its arguments. The only key the agent carries is a ZIFFER key that can ask and cannot act. ZIFFER grades the proposal against the policy you signed, as LOW, MEDIUM or HIGH. A granted action gets a signed receipt. An action nobody should take alone is held for a quorum: the number of named approvers your policy sets, each signing the exact bytes that will run. An action no rule covers is refused. A refusal, or a hold that expires unsigned, leaves a decision record and no receipt.
ZIFFER itself holds no credential and executes nothing. The executor on your side verifies the receipt, then calls the tool with your credential. 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. The reason a text-level attack cannot be filtered away is in prompt injection in AI agents.
What can your agents do today?
Start with an inventory. The ZIFFER scanner lists every tool a model can call, in your code and in the AI tools installed on your machine. It marks the ones that cannot be undone and drafts a policy from what it found. It sends nothing anywhere and needs no account. Read what the scan reads before you trust a clean result. Then run it from your project folder:
npx @ziffer-io/scan