Notifications
Clear all
Topic starter
12/07/2026 12:20 pm
TL;DR: An eve-based AI agent can do real work while holding no live secrets, according to Infisical, using Agent Vault to broker model and GitHub credentials after requests leave the agent process. The pattern matters because it reduces prompt-injection blast radius, but it also exposes how fragile agent credential handling remains when secrets live inside the runtime.
NHIMG editorial — based on content published by Infisical: How We Secured a Vercel eve Agent by Giving It Zero Credentials
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Infisical's analysis of securing a Vercel eve agent with zero credentials →
Vercel eve and zero-credential agents: what IAM teams need to know?
Explore further
12/07/2026 12:34 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Vercel eve agent security shows why zero-credential design matters
