A Permitted Tool URL Can Redirect Elsewhere

Review AI tool redirects before a new request leaves the runner. Use a worked worksheet covering destination, connection, credentials and observable denial.

The first destination does not authorize the next one

An AI assistant asks a lookup tool to retrieve a partner's service status. The runner permits the partner URL, sends the request and receives a redirect. If its HTTP adapter follows automatically, the next destination can receive traffic before the runner makes another authorization decision. A tool that appears read-only can therefore become an unintended route into another service or a channel for disclosing request data.

Consider a fictional integration called Partner Status. Its configured operation reads a status record from partner.example over HTTPS. A response points somewhere else. The product team may expect a harmless move to a new status path, while the implementation treats every redirect as permission to continue. Those are different contracts. Permission to read one configured resource does not grant permission to contact whatever resource it names next.

The scenario and worksheet below are proposed teaching examples. They are not an Ampity customer incident, penetration-test result or certified security configuration. The intended reader is the engineer who owns a server-side AI tool runner, including the HTTP library and network route it actually uses. A browser restriction alone cannot establish what that backend runner does.

Decide whether this tool needs redirects at all

Start with the integration's operating requirements. If the provider has a stable endpoint and no documented redirect requirement, reject redirects and report that the configured endpoint needs review. Avoid adding a general-purpose redirect engine to accommodate a temporary configuration mistake. An operations owner can update the approved endpoint through the normal change process after verifying the new destination.

OWASP's SSRF prevention guidance recommends disabling automatic redirects to prevent validation bypass. It also covers explicit destination allowlists, address checks for IPv4 and IPv6, and connection-time enforcement. Hostname checks alone leave a gap if the client subsequently connects using an unchecked DNS result. Treat disagreement between parsers as a rejection, and constrain network egress as another layer of protection.

When redirects are a genuine requirement, propose a small destination contract for this operation. Name the permitted origins and resource paths, permitted methods, allowed data and redirect limit. Have the integration owner explain why each transition is needed. A migration from one approved endpoint to another can be an explicit relationship rather than a wildcard that accepts every destination a vendor might return.

MDN's explanation of Response.redirected warns that inspecting the flag after receiving the response is too late to prevent an unintended redirected request. Its Fetch example rejects redirects when the request starts. For a server-side implementation, verify the corresponding option in the exact deployed client. A similarly named setting in another library is insufficient evidence.

Review the proposed request before dispatching it

For the fictional lookup, give the runner a configured endpoint identifier instead of asking the model to compose arbitrary URLs. The runner owns the URL construction and narrowly scoped request fields. This reduces the amount of untrusted input that reaches the transport. It still needs to inspect a redirect returned by an otherwise permitted server.

Our proposed review record contains the current operation, source endpoint, candidate destination, candidate method, payload classification, credential audience and policy revision. Evaluate that candidate before any next-hop dispatch. A relative redirect needs an unambiguous base: the endpoint that returned this response. The reviewer should see the resulting destination, rather than a fragment whose meaning depends on a hidden earlier request.

Use the parser employed by the dispatch path, and document which normalized components the policy evaluates. For this example, a hostname substring check is unacceptable. partner.example.attacker.example must not inherit the permission associated with partner.example. An unexpected port or a different path on the same host should also fail the declared operation contract. Whether a path is valid depends on the application's resource semantics, not merely the host's reputation.

Keep the redirect counter and deadline attached to the original operation. A retry must not start a fresh chain with a fresh budget, and a repeated pair of destinations should terminate the attempt. The cap is an application choice that needs a documented reason. Reaching it should produce a visible incomplete lookup, not a fabricated service-status answer. The assistant can explain that the source could not be retrieved under the configured policy.

Bind the allowed address to the connection that uses it

Ask the transport owner to show where name resolution occurs and which address reaches the socket. The answer may involve a proxy, connection pool or retry adapter that the tool wrapper does not control. If the wrapper validates one address but delegates hostname resolution again to an unrestricted layer, the validation record cannot prove which destination received the request.

The curl manual's resolve option illustrates a transport mechanism that supplies an address for a particular host and port. Its temporary-entry variant can expire and return to ordinary resolution. That behavior is a reason to inspect configuration details, not to assume that adding a pin once protects every later connection. This article does not prescribe a curl command as a complete runner implementation.

For our proposed contract, the network team must account for every address the adapter can select, including retries and alternate address families. Preserve the intended hostname for HTTP and TLS identity checks when connecting to an approved address; disabling certificate verification to make an IP connection succeed would undermine that identity check. An unknown or empty resolution result should stop dispatch rather than select an unreviewed fallback.

Record where a proxy performs its own resolution. A client-side address decision cannot establish a proxy's ultimate destination without corresponding enforcement or evidence there. Reused connections need an identifiable peer and a policy compatible with their reuse. If the team cannot observe these details in its runtime, document that verification gap and keep the tool restricted while the transport owner resolves it.

Account for methods, bodies and credentials separately

The WHATWG Fetch redirect algorithm rewrites POST to GET for 301 and 302, and non-GET/HEAD methods to GET for 303, removing the body. The same rewrite rule does not apply to 307 or 308. It removes Authorization on a cross-origin transition. Browser manual mode exposes a filtered redirect response, so it is not a general recipe for reading Location and building a server-side policy engine. These are Fetch semantics, not a promise about every HTTP client or custom header.

In the fictional integration, status retrieval remains GET-only and carries no customer document. A separate upload operation would need its own authority. The fact that an upload began at a permitted host would not authorize resending its body elsewhere after a redirect. Nor should a changed method silently convert an approved operation into a different business action.

Inventory what the runner adds automatically: provider tokens, application headers, session state and any request data embedded in the URL. Removing one named authorization header does not prove that every sensitive field has been withheld. The proposed credential rule is operation-specific: construct the next request from an explicit permitted set, and require a known audience for every credential attached to it. Do not forward the previous request wholesale.

When redirect handling changes, review the caller's behavior too. An assistant may retry a blocked upload or offer to change the URL. Its error contract should preserve the operation identifier, say that no authorized continuation was established and avoid suggesting that a user can bypass the policy by rephrasing a prompt. Keep any uncertain effect from the first request separate from the decision to stop later hops.

Test five transitions with an independent worksheet

Specify the expected outcomes before running the adapter. The worksheet assumes a GET-only status operation, one permitted origin, an approved status-path set and a declared network destination set. All destinations and transport responses are inert fixtures. Do not probe internal services, metadata endpoints or real third parties to make a teaching example look realistic.

| Fixture | Expected decision | Observation required | | --- | --- | --- | | Relative redirect to an approved status path | Allow only after the resulting request passes the declared GET policy. | Exactly one approved continuation; recorded destination and peer match the fixture. | | Same origin, forbidden resource path | Deny before next-hop dispatch. | No transport attempt for the forbidden path. | | Redirect to an unapproved origin | Deny before next-hop dispatch. | No transport attempt to the unapproved origin, with or without credentials. | | Permitted hostname resolves outside the declared network set | Deny before connection to that address. | No connection attempt to the forbidden resolved address, including fallback. | | Upload redirect would resend a body to another origin | Deny; this lookup contract authorizes no upload continuation. | No body or credential delivery to the candidate destination. |

The last row deliberately supplies an operation outside this lookup's contract. It checks that a permissive adapter cannot turn the lookup policy into an upload policy. It does not test whether an independently authorized upload workflow is correct. Keep that workflow's expectations in a separate manifest so an exception there cannot weaken the status tool.

Add malformed locations, redirect loops, exceeded budgets, empty resolution results and changing address candidates to the surrounding suite. Include a deliberately broken adapter that follows before authorization. The observer must detect its forbidden attempt even if the adapter later returns a blocked result. If that negative control passes unnoticed, fix the observer before relying on a clean run.

Require evidence from the transport, not only the chat response

An assistant saying “blocked” does not establish that the network request was blocked. Capture attempted dispatches and connection selections through an independent fixture transport, then reconcile them with the predetermined worksheet. The allowed fixture should demonstrate a functioning observer as well: absence of every attempt can mean the test never exercised the runner.

For an actual controlled integration review, agree a sanitized record containing operation identity, policy revision, hop ordinal, decision, destination identity and the corresponding transport observation. Avoid logging full signed URLs, customer payloads or secret header values. Store a reason code and a reference to restricted evidence where troubleshooting needs more detail. Decide retention and access with the system owner rather than treating tool traces as harmless debug output.

The product owner should also inspect the final visible behavior. A failed lookup must not be presented as a successful status check, and retried calls must preserve the same authority boundary. Review the tool's request construction and dispatch path together with MCP tool descriptions and permission, then distinguish source content from action authority using retrieved instructions and user permission.

If you need help reviewing a deployed runner, our agentic workflow engineering and backend systems and API work are relevant starting points. Share the operation contract, transport configuration and sanitized attempt record if you choose to contact us. Reading this guidance does not require submitting your email or connecting a live system.