A workflow sends an HTTP request during a demo. It reaches the intended API, returns a useful result, and the team says outbound URLs are validated. The demonstration answers whether the happy path works. It does not answer who can choose the destination, what happens after a redirect, or which internal services the server could reach on a different request.
Those are architecture questions, not edge cases to defer until a penetration test. An AI workflow can combine untrusted input, model-generated suggestions, credentials, and server-side network access in one flow. The model is not the security boundary. The boundary is the code and infrastructure that decide which capability a proposed action actually receives.
Here is a review method for that boundary. It uses TopFlow's HTTP-request path as a concrete example, but the decision record applies to any agent or workflow platform that can reach another system.
Map the capability, not just the components
Architecture diagrams often label boxes: model, workflow engine, API, database. Add arrows that answer four harder questions before approving a use case:
- Who supplies the instruction? A developer-owned route, a saved workflow, a user-entered URL, and text proposed by a model have different trust levels. Record where each value came from. A trusted internal call should not become a blanket exemption for a URL a user can edit.
- Who executes it? A server-side request uses the server's network position, not the browser's. Ask which credentials it sends and which private services that server can reach. A harmless-looking workflow node can become a network capability.
- Where can it go? Check the first destination, redirects, name resolution, and any proxy or network policy. A hostname that looks public is not proof of the IP address ultimately contacted. A guard applied before the first request says nothing by itself about later hops.
- What happens with the result? A fetched document may contain data, instructions, or both. Decide whether it can affect a report, trigger another request, or authorize an outward action. Keep source facts and model proposals separate; the untrusted-output review covers that downstream decision in more detail.
This map is deliberately about authority. It works whether the workflow is a vulnerability scanner, a customer-support agent, or an internal research tool. The OSV scanner is one TopFlow use case, not the boundary's definition.
A URL guard is a layer, not an egress policy
TopFlow's technical article on server-side request forgery (SSRF) describes a guard on user-supplied outbound HTTP. In the reviewed engine path, a user-provided absolute URL is checked before fetch; engine-generated relative app routes follow a separate trusted path. The guard rejects non-HTTP(S) schemes and several blocked hostname and literal-IP forms, including loopback, private ranges, and cloud metadata destinations.
That is an implemented boundary with a useful scope. It is not a general statement that every network destination is safe. The guard does not resolve DNS before the request. The engine also calls fetch without disabling redirects or rechecking a redirected destination.
A request that passes the initial URL check can therefore take a path the guard has not assessed. These are residual risks to put on the architecture record, not footnotes to hide behind a feature label.
An older repository version of the article described the defenses before the reviewed engine path in that snapshot had this guard. The guard file entered the repository in June 2026. That history is why I ask for the enforcing path and release version, not just a blog post that says a control exists. A technical article can explain intent; the runtime path must substantiate the claim.
There is a useful testing lesson here too. A past guard missed an IPv4-mapped IPv6 form after the URL parser rewrote the address. A direct test of the helper with the hand-written host passed; a production-shaped URL exposed the gap. The regression tests now pass whole URLs through the same parsing step used by the guard.
The leadership question is not whether the team has “SSRF tests.” It is whether those tests cross the same transformations as the real request.
Write a one-page capability contract
For an AI workflow with outbound access, ask the product and security owners to agree on one record before launch. It should fit on a page and answer:
- Permitted use: which workflow needs outbound HTTP, why, and whether the call is read-only or can change another system.
- Input authority: who can edit the URL, method, headers, and body; whether any of those fields can come from a model or fetched content.
- Destination authority: which destinations are intended; what validates the first URL, follows or blocks redirects, and constrains DNS/network egress.
- Credential scope: which secrets are attached, where they are held, and whether a request can carry them to an unintended host.
- Evidence: the enforcing code, negative tests using complete requests, deployed version, and observations from the environment that will run the workflow.
- Residual owner: the gaps accepted for this use, the compensating control, and the event that will stop or revisit the approval.
Do not mark a box “covered” merely because the team has a helper function. Trace from user-controlled value to the network call. If a control sits only in a builder's validation panel, ask what the execution API does with a saved or directly submitted workflow.
If the runtime guard checks only the initial URL, do not record the destination as fully constrained. A capability contract makes those distinctions visible to the person signing off.
Match the decision to the proof
Consider a pilot that fetches public vulnerability data and prepares a report for a human reviewer. The team can show the outbound guard, tests for blocked literal addresses, and a pinned build. It cannot yet show that DNS resolution and redirects are constrained by the application or by the deployment network.
One defensible decision is a limited pilot in an environment with an independently enforced outbound network policy, no sensitive internal reachability, tightly scoped credentials, and a human reviewing the output. The missing redirect and DNS evidence stays on the record. If that network policy is not in place, the same evidence may support only a local test, not a hosted user-configurable request node. Neither decision declares the whole product safe or unsafe; each matches authority to observed controls.
The approval changes when the workflow can write outside the system. Creating a ticket, posting to a pull request, or calling a production API adds a consequence beyond fetching data. Require a separate decision about who approves the action, what evidence they see, and how it can be stopped or reversed. A URL guard does not authorize a write, and a model's confident explanation does not supply approval.
Bring these questions to the next review
Ask the team to run one normal request and one blocked request through the same path that production uses. Ask what happens after a redirect, what IP the hostname resolves to, and what the server's network policy would allow if application checks were bypassed. Finally, ask whose name appears next to the residual risk. If the answers are still “we think” or “the demo worked,” narrow the launch scope.
TopFlow's SSRF writeup and guard source show one implementation and its limits. Use them as an example of how to inspect a boundary, not as a certification for your own architecture. If your team is approving an AI workflow with network or write access, bring the capability contract to the architecture review. It will surface the decision that a component diagram and a polished demo cannot make for you.