Notifications
Clear all
Topic starter
08/07/2026 7:02 pm
TL;DR: AI agents can leak credentials through prompt injection or indirect content ingestion, so credential brokering is emerging as the trust boundary that keeps secrets out of the agent while still letting it act, according to Infisical. The core shift is that security teams must govern agent access without assuming the agent itself is a safe place to hold credentials.
NHIMG editorial — based on content published by Infisical: Credential Brokering for AI Agents, Explained
Questions worth separating out
Q: How should security teams keep AI agents useful without letting them see secrets?
A: Use a credential broker or proxy so the agent can make authorised requests without ever handling the underlying tokens, API keys, or certificates.
Q: Why are AI agents harder to trust with credentials than traditional workloads?
A: AI agents are non-deterministic, so their tool use and outputs can change based on prompts, context, and external content.
Q: What breaks when an agent can read its own environment variables and tokens?
A: The trust boundary breaks because the agent can be induced to exfiltrate credentials through normal actions such as logging, responding to prompts, or building requests.
Practitioner guidance
- Move secrets out of the agent runtime Use a broker or proxy so the agent can call external services without reading underlying tokens, keys, or certificates.
- Treat prompt injection as a credential exposure risk Review every tool, external content source, and chat input that can influence an agent's behaviour.
- Keep broker endpoints private and isolated Place the broker on a private network, separate it from the agent host, and avoid shared-kernel co-location where possible.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- End-to-end request flow showing how the broker rewrites outbound HTTPS traffic before it reaches each upstream service
- Implementation detail on placeholder substitution for different auth styles, including bearer tokens, API keys, and query parameters
- Deployment guidance for running a private broker on a separate host with proxy-based routing such as HTTPS_PROXY
- Practical design notes on isolation, co-location, and transparent interface-agnostic broker behaviour
👉 Read Infisical's analysis of credential brokering for AI agents →
AI agent credential brokering: what changes for IAM teams?
Explore further
08/07/2026 7:25 pm
Credential visibility is the wrong trust model for AI agents. An agent that can read its own credentials can also be manipulated into disclosing them, because prompt injection and malicious content are now part of the attack surface. The governance problem is not only access, but secret possession. Identity teams should treat agent-visible secrets as already compromised from a control-design perspective.
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 (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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 should own credential brokering in an agent programme?
A: IAM, PAM, and secrets teams should own the control model, while platform teams implement the proxy and network path. The important point is governance ownership, not tool ownership. The organisation needs a clear policy for which credentials may be brokered, where the broker runs, and how request mediation is audited.
👉 Read our full editorial: Credential brokering for AI agents and the new trust boundary
