Genace
Sign inGet started

generation API egress allowlist: separate API traffic from media retrieval

An outbound policy for a generation application has at least two destinations: the authenticated API origin and the hosts serving reference or output media. Treating them as one unrestricted network client makes both security and incident diagnosis harder. Define separate roles, credentials, and destination review processes for each path.

Start with a small traffic inventory

Identify which processes submit jobs, observe status, fetch reference previews, download results, and upload to your storage. Record the destination policy owner and the reason each process needs access. A dispatcher generally needs the API, while a delivery worker needs approved media hosts and your storage service.

outbound_roles:
  api_client:
    origin: https://genace.ai
    path_prefix: /api/v1/
    credential: server_generation_key
    redirects: reject
  media_collector:
    credential: none_from_api_client
    destinations: reviewed_media_host_policy
    redirects: validate_each_hop

This YAML is an architecture policy example, not syntax for a specific firewall or Genace feature. Translate it into the actual network and application controls supported by your platform. Do not assume a document alone constrains traffic.

Keep the API origin fixed

Construct API URLs in trusted server code and attach the bearer key only there. Reject caller-supplied API origins and unexpected redirects. A hostname policy should be complemented by controls appropriate to DNS resolution, TLS verification, ports, and private network access in your environment.

Avoid hard-coding a transient IP address for a hosted service without a documented operational plan. Infrastructure can change. The maintainable boundary is a reviewed destination policy with monitoring, ownership, and a process for safe updates rather than an unexplained permanent address assumption.

Review media hosts separately

Genace outputs contain URLs, but the public output schema does not promise a permanent complete list of delivery domains. Inspect actual approved provider behavior and maintain a versioned media policy. If a new host appears, fail delivery with a clear policy category and review it instead of automatically allowing every host.

Apply the policy again after redirects and constrain resolved network destinations. A media worker should not inherit the API bearer header. Signed source URLs may themselves grant temporary access, so keep them out of broad logs and use only the required storage credentials for upload.

Preserve jobs during policy incidents

A blocked observation request is a local access failure, not proof the remote render failed. A blocked output download is a delivery failure after possible rendering success. Retain the saved job ID, last snapshot, and pending action so recovery can resume after a policy correction.

Do not resubmit to test a firewall change. Use a read-only API request or a controlled local media fixture first. A model listing proves gateway access, not upstream rendering capability.

Acceptance criteria

Verify API credentials never reach media destinations, private network targets are blocked by the intended enforcement layer, and redirect checks cannot bypass the policy. Simulate a new media host and confirm the failure is visible and recoverable. Review who can change the allowlist and how those changes are audited.

See SSRF boundaries, redirect secrets, and non-generating health checks.

Continue with security

Where these facts come from