AI agents are the first enterprise software you deploy that you cannot fully trust — and right now, most organizations hand them the keys to production systems.
Every approach to AI agent credential security in use today has the same flaw. Whether you inject API keys through environment variables, mount secrets files, or pass OAuth tokens at runtime, the agent process can read the credential. And anything the agent can read, the agent can leak.
This isn’t a theoretical concern. It’s an architectural reality.
AI agents are untrusted workloads
Traditional software does exactly what the code says. If your microservice authenticates to a database, the logic is deterministic — reviewed, tested, deployed. You trust it because you wrote it.
AI agents don’t work that way. The core of the agent — the LLM — is probabilistic. It generates code on the fly. It interprets instructions from users, from tool outputs, and from content it retrieves. Any of those inputs can manipulate what the agent does next.
Three threat vectors make this real:
Prompt injection. An attacker embeds instructions in data the agent processes — a Jira ticket, a webpage, a document, an email. The agent follows those instructions, believing them to be legitimate. A prompt injection can instruct the agent to send credentials to an external endpoint, make unauthorized API calls, or exfiltrate data to a location the attacker controls. This isn’t speculation. Prompt injection has been demonstrated against every major agent framework.
Hallucination. The agent generates API calls that were never intended. It calls the wrong endpoint, passes unexpected parameters, or invokes tools in sequences that no developer designed. If the agent holds valid credentials, hallucinated actions are authenticated actions — they succeed against real systems with real consequences.
Untrusted code execution. Coding agents like Claude Code and Cursor generate and execute code that no human reviewed before runtime. That generated code runs in the same process — or the same environment — as your credentials. A single hallucinated fetch() call with Authorization: Bearer ${process.env.API_KEY} in the wrong direction and your credentials are gone.
The common thread: any credential the agent can access is a credential the agent can misuse. Not out of malice, but because you cannot guarantee what an AI agent will do with data it can reach.
Current approaches to AI agent credential security all have the same flaw
Every standard approach to securing agent credentials puts the secret inside the agent’s trust boundary:
Environment variables. API_KEY=sk_live_xxxxx sits in the process environment. The agent — and any code the agent generates — can read it with process.env.API_KEY . Prompt injection that triggers a curl to an external server with that key in the header is trivially achievable.
Mounted secrets. Kubernetes secrets, Docker secrets, .env files. The agent process can read the filesystem. Same exposure, different packaging.
Short-lived tokens. Better than static keys, but a token that’s valid for 60 minutes is still exfiltrable for 60 minutes. Prompt injection doesn’t need more than one request to steal a token.
Every one of these methods trusts the agent to handle credentials responsibly. That trust is misplaced when the agent is running probabilistic code that can be manipulated by external inputs.
A recent survey of AI agent deployments found that over a quarter of technical teams still rely on hardcoded credentials for agent-to-tool connections, and roughly 7% use no authentication at all. The average organization now manages 37 agents. Each one is an untrusted workload with access to production secrets. AI agent authentication today verifies the agent’s identity — but it does nothing to protect the backend credentials the agent carries.
The fix: never give the agent credentials at all
The right model for AI agent credential security doesn’t hand the agent a shorter-lived token or a more tightly scoped key. It removes credentials from the agent’s reach entirely.
Datawiza Agent Gateway does this by intercepting agent API traffic at the DNS layer — before requests ever leave your network. Your enterprise DNS resolves backend API hostnames (like crm.vendor.com or internal-api.corp.net ) to the gateway instead of directly to the service. The agent makes a standard HTTPS call, completely unaware that the gateway is in the path. The gateway validates the agent’s access token, injects the correct backend credential, and forwards to the real backend.
No agent code changes. No proxy configuration. No SDK. The agent just calls APIs the way it always does.
Here’s how it works, using an HR agent as an example. Your HR agent needs to query the HR system’s API to look up employee records. Today, that means giving the agent an API key to the HR system — a key that can read sensitive employee data.
With the gateway in the path:
What the agent holds: A credential that only works against the gateway — never a backend API key. Datawiza Agent Gateway supports two modes here, and most deployments mix them. Agents whose SDKs and runtimes support modern identity flows can carry a short-lived access token issued by your identity provider (like Microsoft Entra Agent ID or Okta), scoped to the gateway as its audience. Agents that only know how to put a static key in an HTTP header — which is the majority of AI agents, CLIs, and scripts in the wild today — are issued a gateway token instead: a drop-in replacement for a provider API key that the agent uses exactly the same way, but that is only accepted by the gateway inside your network. Either way, the agent identifies itself to the gateway, carries no backend API keys, and cannot access any backend system directly.
What the agent sends: A standard HTTPS request to the HR system API, with its access token attached.
What the gateway does: Terminates TLS. Validates the agent’s access token against your IdP — confirming this is the registered HR Agent, not an impersonator. Strips the agent’s access token. Looks up the API key for the HR system from an encrypted credential store. Injects it into the outbound request.
What the HR system receives: A properly authenticated request with a valid API key.
What the agent sees: The API response. Nothing else. No API key. No secret.
Why the agent’s credential is not the same as an API key
A fair question: if the agent still holds a credential — whether an access token or a gateway token — isn’t that still a secret that can be stolen?
Yes, but the risk is fundamentally different.
An access token scoped to the gateway proves who the agent is and authorizes it to call the gateway. That’s all it can do. It cannot be used to call the HR system, the CRM, or any backend directly — the audience is the gateway, not the backend. It can be revoked instantly by disabling the agent’s registration in your identity provider. And it’s useless anywhere except the gateway.
A backend API key grants direct access to production systems and data. It’s often long-lived — months, sometimes never expires. It’s not tied to the agent’s identity registration — it still works even if the agent is decommissioned. And it works from anywhere — an attacker can use it from any machine on the internet.
If prompt injection steals the agent’s access token, the attacker can impersonate that agent at the gateway. That’s bad but containable — the gateway enforces policy, rate limits requests, logs everything, and the token expires quickly. Revoke the agent’s identity in Entra ID or Okta and the token is dead.
If prompt injection steals a backend API key, the attacker has direct, long-lived access to your HR data, your CRM, or your source code from any machine. No gateway in the path. No audit log. No revocation until someone notices and manually rotates the key.
The goal isn’t zero tokens. It’s ensuring the only token the agent holds is the lowest-risk kind — a gateway-scoped access token that proves who it is, not a credential that unlocks backend systems.
The agent cannot exfiltrate what it cannot access. Prompt injection can manipulate the agent into making API calls — but those calls route through the gateway, which enforces policy on every request. The agent cannot be tricked into sending credentials to an attacker’s server, because the credentials never enter the agent’s process.
This is the same zero-trust principle that Cloudflare recently applied to their sandboxed agent environments: a trusted layer that handles credentials outside the untrusted workload’s boundary. The difference is that Datawiza Agent Gateway works with any agent on any infrastructure — you don’t need to run agents on a specific cloud platform, and the agent doesn’t need to know the gateway exists.
What this means for your security posture
Prompt injection becomes a contained risk. An attacker can still try to manipulate the agent through injected instructions. But the worst outcome is that the agent makes an unauthorized API call through the gateway — where policy enforcement, rate limiting, and audit logging catch it. The attacker cannot steal backend credentials because the agent doesn’t have any to steal.
Hallucinated API calls hit a policy wall. If the agent hallucinates a call to a backend it’s not authorized for, the gateway blocks it. No credential is injected for unauthorized destinations. The blast radius of a hallucination is limited to what the gateway’s policy allows.
Credential lifecycle is decoupled from agent lifecycle. Rotating an API key doesn’t require redeploying agents or updating environment variables across machines. Decommissioning an agent doesn’t require hunting down every API key it had access to. Revoke the agent’s identity in your IdP and it loses access to everything instantly.
Full audit trail from a single source. Every API call is logged with the agent’s identity, the destination service, the action taken, and a timestamp. You can answer “what did the HR agent call yesterday and what data did it access” from one place — not by correlating logs across dozens of agent runtimes.
Works with every backend your agents call. Your HR system uses API keys. Your CRM uses OAuth bearer tokens. Your internal database API uses a shared service key. An admin configures each backend once in the gateway. The agent sends the same kind of request every time — the gateway handles the credential differences.
See it in action
We built Datawiza Agent Gateway for enterprises that are deploying AI agents and realize they cannot trust those agents with production credentials. If the problems described in this post sound familiar — API keys in environment variables, no visibility into what agents are calling, credentials that outlive the agents that used them — we’d like to show you how the gateway solves AI agent credential security without changing a line of agent code.
The demo takes 30 minutes. We’ll walk through a live agent making API calls through the gateway, show you the credential injection happening transparently, and show the audit log that captures every request with the agent’s identity attached. You’ll see exactly how it works with your IdP and your backend services.
