Vercel eve agent security shows why zero-credential design matters

At a glance

What this is: This is a practitioner analysis of securing a Vercel eve AI agent by removing live credentials from the agent process and brokering access through a vault.

Why it matters: It matters because IAM, NHI, and AI governance teams need identity patterns that limit credential exposure even when agents can call tools, delegate work, and operate across channels.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Infisical's analysis of securing a Vercel eve agent with zero credentials

Context

AI agent security is increasingly an identity problem, not just an application design problem. When an agent can read files, call tools, and reach external services, the key question becomes where its credentials live and who can actually use them.

The common failure mode is simple: the agent process holds real secrets in its own environment, so a prompt injection or malicious instruction can try to extract them. A zero-credential design changes that assumption by keeping live secrets outside the runtime and issuing them only when a request is proxied.

This article is about a practical way to reduce that exposure in a Vercel eve deployment, using Agent Vault as the credential broker. That starting position is typical for teams building useful agents before they have mature governance around identity, access, and tool delegation.

Key questions

Q: How should security teams implement short-lived credentials for AI agents?

A: Start by issuing the smallest workable token lifetime for each agent class, then verify that revocation, refresh, and logging operate across every system the agent can touch. The goal is to reduce blast radius without creating fragile workflows that fail under normal production conditions.

Q: Why do AI agents create a bigger secret exposure problem than ordinary automation?

A: AI agents can read untrusted content, interpret instructions at runtime, and decide which tools to call, which makes injected text more dangerous when live secrets sit beside the model. Ordinary automation usually follows fixed paths, but an agent can be steered into revealing whatever credentials its process can reach. That makes secret placement a core governance issue.

Q: What breaks when an agent process stores model and GitHub tokens in its environment?

A: The agent becomes a credential holder instead of a controlled actor, so any prompt injection, malicious issue, or poisoned webpage can try to extract reusable access. Even if the token is scoped, the leak itself still happens, and the attacker can reuse the credential outside the original session. The safer pattern is to remove the secret from the runtime entirely.

Q: Who is accountable when an AI agent in a pipeline leaks credentials and enables code push access?

A: Accountability sits with the team that designed the workflow permissions and the controls around it, not with the model. The issue is governance over delegated execution, secret persistence, and workflow pivot rights. Frameworks such as the OWASP Agentic AI Top 10 and NIST CSF help map that accountability to access control, logging, and recovery duties.

Technical breakdown

How eve structures agent identity, tools, and delegation

eve treats an agent as a directory tree rather than a single opaque service. The structure separates instructions, tools, skills, connections, subagents, channels, and schedules, which makes the runtime easier to inspect but does not by itself solve access control. The identity question is not whether the agent can call tools, but whether the credentials behind those tools are embedded in the process or mediated elsewhere. That distinction matters because tool access and credential possession are not the same thing.

Practical implication: Treat the directory structure as an organisational pattern, not a security boundary, and move credential handling out of the agent process.

Why credential brokering changes the attack surface

Credential brokering separates the actor from the secret. The agent sends a request with a placeholder or broker token, then the vault injects the real credential only when the outbound request reaches the target service. That means the agent never needs persistent access to the underlying GitHub token or model key, which sharply reduces what a prompt injection can steal from memory, logs, or environment variables. This is a classic NHI control pattern applied to agent runtime access.

Practical implication: Use a proxy or vault so the agent can invoke services without ever storing reusable secrets in its own runtime.

Why sandboxing does not replace secret isolation

A sandbox constrains execution location, not credential value. Running in a microVM, Docker container, or fallback shell may reduce lateral movement, but if the agent process still carries valid secrets, a successful injection can still aim at those values. The article also notes that local fallback modes can differ silently from production, which creates a false sense of equivalence in testing. Security teams need to separate execution containment from credential containment.

Practical implication: Validate both runtime isolation and secret placement, especially when local development can drift from production sandboxing.

Threat narrative

Attacker objective: The attacker wants to trick the agent into revealing or exporting credentials that unlock downstream services and private data.

1. Entry begins when the agent reads untrusted content such as a GitHub issue, web page, or Slack message that contains injected instructions aimed at credential theft.
2. Escalation occurs if the agent already has live secrets in its own environment, because those credentials can be requested, echoed, or forwarded from within the session.
3. Impact is the exposure of model keys or GitHub tokens that can be reused outside the original agent context, expanding access beyond the intended task.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero-credential agent design is a governance pattern, not just a hardening tactic. The article shows that an eve agent can perform useful work while holding only placeholder values in its own process, with the real credential injected by a broker at request time. That changes the identity control model because the agent no longer possesses the secrets it needs to operate, which is the point of the design. Practitioners should treat this as an NHI governance pattern for AI agents, not as an implementation detail.

Prompt injection becomes less valuable when the agent never owns the credential. The article's core security logic is that an injected instruction can only steal what the runtime already has. If the live credential never exists in the agent process, the attacker loses the easiest exfiltration path and must pivot to the broker or target service instead. That is a meaningful reduction in attack surface, especially for support agents that read external content as part of normal operation.

Identity blast radius is the right concept for agent credentials. The important question is not whether a token is read-only or repo-scoped, but how far a compromised agent can reach before identity control stops it. A dummy token plus vault mediation creates a much smaller blast radius than embedding secrets directly in the runtime. For IAM and NHI teams, the lesson is that credential location is a governance decision with direct breach impact.

Runtime sandboxing and secret brokering solve different problems. The article is careful to show that isolated execution does not eliminate credential exposure if the agent still holds live secrets. That distinction matters because many teams conflate containerisation with identity control. The practitioner implication is clear: trust containment for code, but enforce brokering for secrets.

AI agent governance should converge on the same lifecycle discipline used for other NHIs. The agent's credentials, channels, and delegated tools all need provisioning, review, and offboarding logic, even if the runtime itself is ephemeral. That is where NHI governance meets agentic AI: the actor may be more dynamic, but the identity lifecycle still has to be explicit. Teams should manage agent access as a governed identity, not as a developer convenience.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The broader implication is that governance must move from agent intent to agent evidence, which is why OWASP NHI Top 10 becomes relevant as these deployments scale.

What this signals

The governance pattern here is converging on identity blast radius, meaning the real control question is how much damage an agent can do if its prompt path is manipulated. With 80% of organisations already reporting out-of-scope agent behaviour, per AI Agents: The New Attack Surface report, teams should assume the runtime will eventually be influenced and design for containment first.

This is also where the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework become operational, because the issue is not only model misuse but identity misuse through delegated tools and brokered access. Security programmes that treat agent credentials as ordinary secrets will keep missing the control boundary.

For IAM and NHI teams, the next planning step is to inventory where agents currently hold direct credentials, where they rely on a broker, and where local testing may be masking production behaviour. That inventory is the basis for a defensible rollout path rather than a series of one-off fixes.

For practitioners

• Move real secrets out of the agent runtime Replace in-process API keys and tokens with brokered access so the agent only sees placeholder values or short-lived delegation handles. This reduces what prompt injection can steal from memory, logs, or environment files.
• Separate sandboxing from credential control Review whether your agent can still reach live credentials even when it runs in a microVM, container, or local fallback shell. Execution isolation is useful, but it does not prevent secret exfiltration if the secret is already present.
• Scope upstream tokens to the smallest viable task If a brokered token or service credential must exist, limit it to a single repository, read-only access, or a narrow service set. Scoping does not remove leak risk, but it reduces the blast radius if a control fails.
• Audit fallback development modes before production rollout Check whether local development silently drops from container isolation to lighter sandbox modes. Teams should verify that the security assumptions in testing match the production runtime before treating the setup as a control baseline.

Key takeaways

• The main lesson is that an AI agent can be useful without being trusted with live credentials.
• The evidence points to a broad governance gap, with out-of-scope agent behaviour already common across deployments.
• The practical response is to broker secrets, reduce blast radius, and manage agent access as a lifecycle-governed identity.

Key terms

• Credential Brokering: Credential brokering is the process of using a trusted identity proof to issue a separate credential for a target system that cannot accept the original identity natively. It is useful for compatibility, but it also becomes a control point for scope, duration, logging, and revocation.
• Identity blast radius: Identity blast radius is the amount of access or damage an identity can cause if it is compromised, manipulated, or misused. For AI agents and other NHIs, the critical issue is not just whether a token leaks, but how far that token can reach across tools, services, and data.
• Zero-credential design: Zero-credential design means an agent or service operates without reusable secrets inside its own runtime. The system may still authenticate through a broker or proxy, but the actor never directly stores the credentials it uses, which sharply reduces the value of prompt injection and runtime compromise.
• Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact eve folder structure used to organise tools, skills, connections, subagents, channels, and schedules
• Implementation notes for the Agent Vault proxy setup that keeps real credentials out of the agent process
• The local and production sandbox behaviour differences that can change your security assumptions
• The specific GitHub connection and support-agent workflow used in the demo

👉 The full Infisical post covers the eve architecture, Agent Vault setup, and the credential handling demo in detail.

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.