What should organisations do when AI tools may carry credentials in request paths?

Organisations should remove credentials from request paths, reduce reliance on query-based authentication, and constrain where agent traffic can be sent. If the proxy layer can see the credential, the proxy layer can potentially expose it, so request hygiene matters as much as model hygiene.

Why This Matters for Security Teams

When AI tools carry credentials in request paths, the issue is not just leakage, it is uncontrolled propagation. Any intermediary that can inspect, log, retry, cache, or transform the request may also expose the secret. That turns ordinary routing into a credential distribution problem, especially in agentic workflows where the caller can change destination, chain tools, or retry automatically.

The operational risk is visible in recent NHI research. The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or merely match their human IAM maturity, which helps explain why request-path credentials still appear in real systems. Security teams should treat this as a transport and boundary issue, not only a secrets-management issue. OWASP’s Non-Human Identity Top 10 reinforces that NHI exposure often happens through weak placement and over-permissive handling, not through a single broken login flow.

In practice, many security teams encounter the first sign of this problem only after logs, traces, or proxy captures have already exposed the credential.

How It Works in Practice

The safest pattern is to remove credentials from URLs and other request paths, then replace them with short-lived, out-of-band authentication that is issued for the specific workload and destination. That means using headers, mTLS-bound identities, or token exchange flows rather than query parameters or path tokens. For autonomous systems, the identity primitive should be the workload, not the request string. The NIST SP 800-63 Digital Identity Guidelines are human-centric, but the core principle still applies: the verifier should validate a trustworthy identity assertion, not rely on a bearer value that leaks through transport plumbing.

In NHI operations, this usually means combining workload identity, policy enforcement, and constrained routing. A practical design often includes:

• Request paths that contain only resource identifiers, never secrets.
• Ephemeral credentials issued just in time for a single task or short session.
• Proxy and gateway rules that strip or reject credential-like query parameters.
• Allowlists that limit which upstreams an AI agent can call.
• Audit controls that redact credentials before logs, traces, or replay tooling see them.

NHIMG research on the Ultimate Guide to NHIs draws a clear line between static and dynamic secrets, and that distinction matters here because dynamic secrets lose value faster when they are intercepted. This is also why request hygiene and secret hygiene must be designed together: if a proxy can see the credential, the proxy can potentially expose it, even when the application never logs it directly. Current guidance suggests that URL-based credential transport should be treated as a design defect, not an acceptable fallback.

These controls tend to break down in legacy integrations and third-party APIs that only accept credentials in query strings or path segments because the application cannot force safe transport semantics.

Common Variations and Edge Cases

Tighter request controls often increase integration overhead, requiring organisations to balance safer transport patterns against legacy compatibility. That tradeoff is real, especially where older SaaS endpoints, vendor gateways, or agent orchestration layers still expect secrets in the request URL.

Best practice is evolving, but the direction is consistent: isolate these exceptions, wrap them with compensating controls, and plan them out. For example, a gateway can rewrite a request so the calling agent never handles the downstream secret directly, or a broker can exchange one scoped token for another before forwarding. That approach aligns with the broader NHI guidance in the Guide to the Secret Sprawl Challenge, where the main problem is not just storage but uncontrolled spread across systems, logs, and operators.

One important edge case is autonomous agent traffic. Agents may retry, branch, or fan out in ways that humans do not predict, so a single exposed request path can be replayed across many services very quickly. The safe response is to constrain destinations, apply strict token scope, and revoke quickly on task completion. In environments with deep observability stacks, shared reverse proxies, or distributed tracing, organisations should assume that any secret placed in the request path can be copied into multiple telemetry systems before anyone notices.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• How should organisations use AI in access request approval without weakening control?