An operator configures an action provider that can create a work order in an external service. The provider URL is data supplied to the product, so every outbound request needs a boundary before it leaves the application. Latch routes provider discovery, execution, acceptance enrichment, and outbound event delivery through a guarded HTTP client that validates the destination and limits the response path.
Validate the destination before dialing
Public provider endpoints must use HTTPS on port 443. Latch resolves the hostname and checks every returned IPv4 and IPv6 address; if any answer points to a forbidden destination, the request is denied. For an allowed host, the client dials a vetted numeric address while keeping the hostname for TLS verification. This reduces the gap between checking DNS and connecting to an address.
The client does not follow redirects and does not inherit ambient proxy settings. A provider cannot return a redirect that quietly changes the destination, and an environment proxy cannot silently rewrite the route. Response bodies are capped at 1 MiB so a remote endpoint cannot make a normal provider response consume unbounded memory.
These checks apply across the provider lifecycle, not only when an operator clicks “run.” Discovery, execution, acceptance enrichment, and outbound event delivery use the same guarded path. A boundary that covers only the most visible request would leave other provider calls with a different network policy.
Make private integrations explicit
Some deployments need a provider hosted on a private integration network. An operator-defined origin and path mapping can target approved private IPv4 ranges, but it cannot override hard denials for loopback, cloud metadata, Tailscale, or other special-use destinations. That exception is narrow and explicit; it does not make arbitrary private URLs reachable.
For example, an approved work-order connector may point to a fixed internal gateway. The mapping names the permitted origin and path, while the network guard still rejects destinations such as local loopback or a metadata endpoint. Deployments that use an isolated relay add a separate network enforcement layer; that relay requirement is specific to those configurations, not a universal setting for every installation.
Separate reachability from permission
Passing a destination check means the request satisfies the network policy. It does not approve the provider’s business action or grant a user permission to run it. Plugin entitlement, the user’s action permission, and provider approval remain separate gates. Review those workspace controls before enabling a plugin action, and manage MCP agent permissions and credentials separately when an agent calls the product.
Test both outcomes before routing production work through a provider. Confirm the allowed endpoint uses the intended hostname, port, and path; confirm a redirect or prohibited destination is denied. Keep private mappings limited to the named integration origin. If an SLA planning workflow does not need to make an external call, do not connect a provider merely to make a rule appear automated.
The guarded client defines an outbound destination policy for provider traffic. It does not certify the external service, prove that an action is correct, or establish a general security or compliance claim for the whole application. Keep business approval with the people responsible for the work order, and treat network reachability as one check in that decision.