The most dangerous secret in an AI agent runtime may be the one nobody deliberately gave the agent.
A hypothetical example: a support agent runs inside a container with access to a ticketing system, a database, and an internal API. The platform injects several credentials through environment variables because that is how the existing services authenticate.
The agent only needs one read-only token to resolve tickets.
But the runtime exposes every environment variable to the process. A prompt injection hidden in a customer attachment instructs the agent to inspect its environment and send configuration data to an external endpoint using an available tool.
No database exploit is required. No administrator account needs to be compromised. The agent simply turns broad runtime access into delegated authority.
This is the control many teams miss:
A secret should not be available merely because the process could technically use it.
Inspect the runtime, not just the prompt
Security reviews often focus on what the agent is allowed to say or which tools it can call. Those controls matter, but they do not answer a more basic question:
What sensitive material can the agent reach before policy is evaluated?
For every agent runtime, a buyer or platform team should inspect:
- Which secrets are mounted into the process?
- Can the agent read environment variables, local files, metadata services, or shared volumes?
- Are credentials scoped to one task, or reused across multiple tools?
- Can the agent request a credential dynamically, with an explicit policy check?
- Does a tool receive the secret itself, or only the minimum operation it needs?
The safer pattern is to keep secrets outside the agent’s working context wherever possible.
Instead of giving an agent a database password, expose a narrowly defined operation such as “retrieve the order status for this authenticated customer.” Instead of placing a cloud token in the environment, use a broker that checks the agent identity, requested action, target resource, and session context before issuing short-lived access.
That changes the failure mode.
A manipulated agent may still attempt an unauthorized action, but it no longer automatically gains the material needed to widen the attack. The control point sits between intent and access, where it can be logged, denied, or routed for human approval.
This is also a governance decision, not only an infrastructure decision. If a team cannot explain which agent can obtain which secret, under what conditions, and for what operation, it does not yet have bounded delegation.
The practical test is simple:
Remove every secret the agent does not need to complete its next action. Then make access to the rest conditional, temporary, and observable.
