Vercel eve agent security shows why zero-credential design matters

At a glance

What this is: Infisical shows that a Vercel eve agent can operate with zero credentials in its own process, using a vault to broker access only when requests leave the agent.

Why it matters: That matters because IAM teams now need to design agent access so secrets are never resident where prompt injection, misuse, or over-broad tool execution can steal them.

Context

Zero-credential design means the agent does useful work without carrying the live secret needed to complete the task. In this case, the issue is not whether the model can behave politely under instruction, but whether the identity architecture makes credential theft possible inside the agent process at all.

For IAM and NHI teams, the governance question is no longer only how much privilege an agent has. It is where the privilege lives, when it is attached, and whether the agent ever sees a reusable secret that can be copied, logged, or exfiltrated.

Key questions

Q: What breaks when AI agent access relies on long-lived secrets?

A: Long-lived secrets let AI agents carry persistent access far beyond the task they were created for. That increases theft risk, complicates offboarding, and makes it harder to prove scope at audit time. Secretless, short-lived access is safer because the credential exists only for the current task and runtime context.

Q: Why do AI agents need brokered credentials instead of scoped tokens?

A: Scoped tokens reduce blast radius, but they still leave a usable credential inside the agent process. Brokered credentials change the model by moving real authorisation to a vault or proxy that attaches the secret only after the request leaves the agent. That eliminates direct secret theft from the runtime while preserving task completion.

Q: How can security teams tell whether agent isolation is actually working?

A: If the agent can complete its task while every credential in its own environment is dummy data or absent, isolation is working at the right layer. If a prompt injection can still cause a working key to be printed, forwarded, or reused, the design has only sandbox isolation, not secret isolation. Test both boundaries separately.

Q: What should teams do when an agent needs access to GitHub, APIs, or model keys?

A: Give the agent a limited proxy identity, keep the real secret in a broker, and attach the credential only on the wire for approved destinations. That approach preserves the ability to search, read, or act while preventing the agent from ever seeing a reusable secret. It is the safest default for agentic systems.

Technical breakdown

Why brokered credentials change the agent trust model

A brokered model separates the agent’s reasoning process from the actual secret used to authenticate downstream actions. The agent submits a request, the proxy or vault attaches the real credential after the request has already left the agent process, and the target service receives a valid call without the agent ever holding the secret. That matters because prompt injection, poisoned context, or malicious instructions can only steal what is resident in the process or environment. If the secret is absent, the attack path collapses. This is not just masking or obfuscation. It is an identity boundary that removes the credential from the runtime blast radius.

Practical implication: move sensitive upstream credentials out of the agent runtime and into a brokered issuance path.

Why sandboxing alone does not solve secret exposure

Sandboxing reduces execution risk, but it does not eliminate credential risk if the agent still has live access tokens in its environment. A microVM, container, or isolated workspace can stop direct host compromise and limit filesystem reach, yet the secret remains stealable through a malicious instruction that persuades the model to print, forward, or misuse it. That distinction is critical for agentic systems because the dangerous action may be legitimate from the agent’s perspective. The control failure is not sandboxing itself. It is assuming execution isolation also guarantees secret isolation, which it does not.

Practical implication: treat sandboxing and secret brokering as separate controls, not substitutes.

How zero-credential design changes agent authorisation

In a zero-credential pattern, authorisation shifts from ambient secret possession to constrained proxy access. The agent authenticates to the broker with a limited identity that can request only approved downstream services, scopes, or actions. The broker then enforces the real credential boundary on the wire, which means the agent’s own environment can be emptied or filled with dummy values without blocking task completion. This is especially relevant when the agent has subagents, MCP-style tool connections, or multiple channels, because every extra execution path increases the chance that one process will leak what another process should never have seen.

Practical implication: define broker policy as the real access layer and keep agent-local tokens non-usable if they are exposed.

Threat narrative

Attacker objective: The attacker wants a valid downstream secret that lets them act as the agent against code, APIs, or connected services.

1. Entry occurs when an attacker gets malicious instructions into the agent’s context through a poisoned issue, fetched page, or message. The agent treats the instruction as ordinary task input rather than adversarial content.
2. Credential harvest is attempted by steering the agent toward printing, forwarding, or otherwise exposing the model key or GitHub token that lives in its runtime environment. The value becomes the target because it is directly reachable from the process.
3. Impact is limited when the runtime holds only dummy values and the real credentials sit in a vault outside the agent process. Without a reusable secret in memory or on disk, exfiltration produces no working access.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero-credential design is the cleanest answer to prompt-injection risk because it removes the target, not just the temptation. Access control for agents has too often been treated as a scoping problem when it is really a secret residency problem. If the agent never holds a reusable credential, malicious instructions cannot turn context into exfiltration. The practitioner conclusion is that agent identity should be brokered, not embedded.

Sandboxing is necessary, but it does not change the fact that a live secret inside the process is already exposed to the model. A container, microVM, or isolated workspace can constrain damage after execution, but it cannot stop the agent from reading or repeating what it can see. That makes secret placement a first-class control decision, not an implementation detail. The practitioner conclusion is to separate runtime isolation from credential isolation in design reviews.

Agent security now depends on where privilege is attached, not merely how narrow the privilege is. Scoping a token still leaves a token inside the agent if the agent receives one directly. Brokering moves authorisation to the edge of the request path and makes the secret invisible to the model, which is materially different from least privilege alone. The practitioner conclusion is to redesign access paths so the agent requests capability without ever possessing it.

Identity blast radius is the right concept for this architecture. The risk is no longer just how much access an agent has, but how far a compromise can travel if the agent process is the container for multiple keys, tools, and channels. When credentials are decoupled from the agent, compromise stays local to the task rather than becoming portable across services. The practitioner conclusion is to measure agent governance by blast radius, not by model quality.

AI agent authorisation needs lifecycle governance, not one-time setup. The proxy identity, downstream scopes, and approval boundaries all need their own joiner-mover-leaver logic because agent tasks, channels, and tool chains change over time. If the broker is treated as a static configuration artifact, privilege drift reappears at the control plane instead of the model layer. The practitioner conclusion is to recertify agent access as a living identity relationship.

From our research library:

• Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Zero-credential agents: the governance shift is from secret possession to secret brokering. Once the agent no longer holds a live key, prompt injection loses its most obvious exfiltration target, and the control problem moves to request-time authorisation rather than runtime containment.

The practical lesson for IAM and NHI programmes is that approval gates, scoped tokens, and sandboxes are no longer sufficient on their own. Access review processes assume a credential exists long enough to be reviewed, but brokered agent access is now a flow problem, so governance has to focus on issuance paths, proxy scopes, and downstream entitlements.

For practitioners

• Broker downstream credentials out of the agent process Keep model API keys, GitHub tokens, and similar secrets in a vault or proxy so the agent only receives non-usable placeholders or wire-time injection.
• Separate sandboxing from secret isolation Use containers or microVMs for execution containment, but do not assume those environments prevent credential exposure if the agent still reads live secrets.
• Minimise the agent-visible identity surface Give the agent a narrow proxy identity that can request only the approved upstream services it needs, not direct reusable access to those services.
• Design for prompt-injection resistance Treat every tool output, file read, and inbound message as a potential instruction channel, and make sure no one-step exfiltration path reaches a real secret.
• Recertify agent access as a lifecycle object Review broker scopes, tool entitlements, and approval gates on a schedule so agent access does not drift as tasks, subagents, and channels expand.

Key takeaways

• The core risk is not that an agent can think badly, but that a live secret inside its runtime can be harvested through ordinary task inputs and outputs.
• Infisical’s example shows that a Vercel eve agent can still perform useful work when the real model and GitHub credentials live outside the process.
• For IAM teams, the control point moves from token scoping alone to brokered issuance, secret removal from the runtime, and lifecycle review of the proxy identity.

Key terms

• Zero-credential agent: An AI agent that can complete work without holding a reusable secret in its own runtime. The real credential is kept in a broker or vault and attached only when the request leaves the agent, which sharply reduces secret-exfiltration risk.
• Credential Broker: A credential broker is a control layer that releases credentials, tokens, or federated access only after verifying the requester and the request context. It reduces secret copying by shifting access from static distribution to point-of-use delivery, which improves auditability and narrows exposure windows.
• Secret Residency: Secret residency is where a credential lives during normal use, such as a file, memory, vault, or environment variable. The key governance question is not only whether a secret is protected, but whether it is resident in a place that modern tooling, including AI coding agents, can observe or transmit.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.