What breaks when an AI service follows redirects after validating only the first URL?

Why This Matters for Security Teams

Validating only the first URL gives a false sense of safety because the real request is not finished until every hop is evaluated. In server-side request forgery scenarios, a public endpoint can look harmless at intake, then redirect the client toward internal services, localhost listeners, or cloud metadata. That means the security decision is made on the wrong object: the initial URL instead of the actual destination.

This is why hop-by-hop controls matter more than a single allowlist check. Current guidance from NIST Cybersecurity Framework 2.0 emphasizes reducing attack paths and validating trust boundaries continuously, not only at the perimeter. For NHI-heavy environments, the lesson also connects to how attacker-controlled workflows abuse service identities after a request escapes the original policy boundary. NHIMG has documented how compromised NHIs accelerate abuse in real environments, including the LLMjacking research and the DeepSeek breach analysis.

In practice, many security teams encounter the failure only after an internal fetch reaches a target that was never approved in the original request review.

How It Works in Practice

The control gap appears when the HTTP client, SDK, or agent runtime automatically follows 30x redirects after the application has already approved the first hop. A common pattern is: the application checks that the first URL is public and syntactically safe, then the underlying client follows a redirect to a different host without reapplying policy. That is enough to defeat simple SSRF defenses.

The operational fix is to treat every redirect as a new authorization event. The request policy should inspect the next-hop destination, scheme, port, and resolved address before following it. If the redirect chain crosses trust boundaries, the safest default is to stop. This is especially important for autonomous AI services, where tool calls may originate from an agent that can chain requests faster than a human reviewer can notice. Guidance from the NIST Cybersecurity Framework 2.0 aligns with that approach by reinforcing continuous risk treatment rather than one-time validation.

• Disable automatic redirects for untrusted fetch paths.
• Validate each hop after DNS resolution and before connection.
• Block private, loopback, link-local, and metadata ranges at every hop.
• Apply allowlists to final destinations, not only the original URL string.
• Log redirect chains so incident responders can see the full path taken.

For AI and automation teams, this is not only a web security issue. It is also an identity issue because the redirected request may execute with a powerful service token, and that token becomes the real prize. NHIMG research on compromised NHI abuse in LLMjacking shows how quickly attackers exploit trusted machine identities once they can pivot a workload into a more privileged context. These controls tend to break down when a proxy, SDK wrapper, or outbound fetch library silently follows redirects across mixed trust zones because the application never sees the final destination before the connection is made.

Common Variations and Edge Cases

Tighter redirect controls often increase engineering overhead, so organisations have to balance usability against blast-radius reduction. That tradeoff is especially visible when APIs legitimately rely on redirects for file retrieval, third-party OAuth flows, or content delivery networks.

There is no universal standard for this yet, but current guidance suggests separate handling for trusted and untrusted fetch paths. For trusted integrations, redirect-following may be acceptable if the destination set is fixed and monitored. For untrusted user-supplied URLs, best practice is to block redirects entirely or enforce strict hop-by-hop policy checks.

Edge cases also appear in environments that resolve hostnames through internal DNS, service meshes, or sidecar proxies. A hostname that looks external can still resolve to internal infrastructure after the first hop, which is why string-based checks are insufficient. This is where agentic systems are particularly risky: an AI service can combine redirects, retries, and tool chaining in ways that make the final network path hard to predict. The broader identity and secrets risk is captured in NHIMG’s The State of Secrets in AppSec research, which shows how long-lived secrets and fragmented controls keep exposure windows open after a misroute.

When a workflow must follow redirects, the safer pattern is to move the trust decision into policy-as-code and require runtime checks for each destination before any privileged credential is sent.

Related resources from NHI Mgmt Group

• What are common vulnerabilities associated with service accounts in AI deployments?
• How should teams reduce the risk of exposed AI credentials being abused?
• What steps should security teams take to prevent Shadow AI risks?
• Why is visibility important in managing Shadow AI?