Use a credential broker or proxy so the agent can make authorised requests without ever handling the underlying tokens, API keys, or certificates. The agent should submit a request, and the broker should attach credentials on the outbound path. That keeps secret custody outside the agent runtime and reduces exfiltration risk from prompt injection or malicious content.
Why the broker pattern is the right control boundary for AI agents
The key design choice is to separate decision-making from credential custody. Let the agent decide what it needs to do, but keep the credentialed action in a broker, proxy, or gateway that performs the outbound call on the agent’s behalf. That way, the agent remains useful for planning and orchestration without ever seeing the secret material that could be copied, leaked, or reused.
This is especially important when the agent can be influenced by untrusted text, prompts, documents, or tool outputs. If the runtime can never read the underlying token or key, prompt injection has far less room to turn a harmless task into secret exfiltration or unauthorised downstream use.
For teams building agent workflows, the broker should be treated as the trust boundary, not the model. The broker is where policy enforcement, audience restriction, expiry, and request shaping belong, because that is the point where the request can still be evaluated before any credential is attached.
What good request mediation looks like in practice
A useful broker pattern does more than hide a string value. It should attach credentials only after checking that the request is allowed, scoped, and attributable. That usually means the agent submits an intent, the broker translates that intent into a bounded API call, and the downstream system sees a credentialed request from a controlled service path rather than from the model runtime itself.
That design also makes it easier to distinguish between the agent’s intent and the actual action taken. If the agent asks for something broad, the broker can narrow it to the minimum operation needed, reject disallowed targets, or require an additional approval step for sensitive actions. This matters because the most dangerous failure mode is not just secret exposure, but secret-bearing action at a broader scope than the task justified.
When possible, combine the broker with short-lived credentials and audience-restricted tokens so even a misrouted request has limited value if intercepted or replayed. For implementation guidance on authentication, secret handling, and session-bound controls, teams often pair broker design with the OWASP Cheat Sheet Series, then adapt those patterns to the agent workflow rather than to a human browser session.
Where teams usually get this wrong
The common mistake is to give the agent a secret “just for convenience” and assume sandboxing is enough. In practice, once the runtime can read the secret, any prompt, tool response, log, crash dump, or memory snapshot becomes a potential leakage path. The same is true for long-lived tokens that are copied into config files or environment variables and then reused across too many tasks.
Another failure mode is over-trusting the agent’s apparent autonomy. If the model can decide to invoke tools but the same context also contains credentials, then a single successful manipulation can turn a reasoning error into a real security event. A broker reduces that blast radius by ensuring the model never becomes the storage location or transport path for secrets in the first place.
Use this pattern as a forcing function to clean up access design. If a workflow cannot function without exposing a reusable secret to the agent, that is usually a sign the integration is too broad, the permission scope is too large, or the system needs a different service boundary rather than a stronger prompt.
Risk and Threat Considerations
Secret exposure turns an AI agent from a constrained assistant into a credential-handling conduit. Once a token, API key, or certificate is visible inside the agent runtime, untrusted content can sometimes influence the agent to reveal, reuse, or forward that material, and the resulting access may extend far beyond the original task.
Failure mechanism: The agent receives or retains secret material in-context, then prompt injection, malicious tool output, or simple misconfiguration causes the secret to be logged, echoed, cached, or used outside its intended scope.
Impact: An attacker or careless workflow can gain downstream access through the stolen credential, create unauthorised API calls, or persist access until the secret is rotated and every dependent path is reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Broker patterns prevent secrets from entering agent runtime. |
| NHI-04 — Insecure Authentication | The question is about safe request authorization without exposing secrets. | |
| NHI-07 — Long-Lived Secrets | Long-lived credentials are the core exposure the broker pattern avoids. | |
| Recommendation — Keep credentials out of agent context and attach them only in a controlled mediation layer. Use brokered, short-lived auth so the agent never handles reusable credentials. Replace reusable secrets with short-lived, task-scoped credentials wherever possible. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents with visible secrets can overreach their intended authority. |
| ASI02 — Tool Misuse | A broker constrains how tools are invoked and what credentials they can use. | |
| Recommendation — Enforce per-action authorisation and keep secret-bearing authority outside the agent runtime. Route tool calls through a policy-enforcing broker that shapes and limits each request. | ||
Practitioner Guidance
What to verify: Confirm that the agent never receives raw secrets in prompts, memory, logs, or tool output, and that every credential is attached only by a controlled broker on the outbound path. If you cannot prove that boundary, you do not yet have a safe agent integration.
Decision rule: If the agent must handle a long-lived credential to complete the task, redesign the workflow before rollout. Use short-lived, task-scoped access and require the broker to enforce the smallest possible permission set for each request.
Practitioner takeaway: The goal is not to make the model less capable, but to make secret custody independent of model behaviour so usefulness and containment can coexist.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org