Prove the egress before you install

Every connection Prism needs is outbound from the namespace. The reason to prove them before installing is what the alternative looks like: a missing firewall rule is discovered on the first chat turn, or on the first ingest days later, and both present as Prism being broken rather than as a route being closed.

To	Port	Needed
Your Agent Router data plane — `router.proxyUrl`	443	Always. All inference rides it.
Your Agent Router management plane — `mcps.management.valetServiceUrl`	443	Only for Router spend (`indexed`/`live`) or `directory=live`
GitHub — `ingest.github.apiUrl`	443	Only for `sources.github=live`
Jira — `ingest.jira.url`	443	Only for `sources.jira=live`
Your Oracle listener — the source's `db_host`:`db_port`	1521, or the port your estate moved it to	Only for an Oracle source. From the app pod (the probe, when an admin clicks it) and the ingest pod (the scheduled walk)
Your Snowflake account — `<account>.snowflakecomputing.com`	443	Only for a Snowflake source. From the app pod (the probe), the semantic MCP pod (a `query-through` source's answers) and the ingest pod (a `snapshot` copy's daily walk, snowflake-snapshot.md)
Your SMTP relay — `smtp.host`:`smtp.port`	587/465	Only for `app.identity.mode: local`
Your registry	443	Image pull, from the nodes rather than the pod

Run the checks from a pod in the target namespace, not from a laptop or a jump host. The whole question is what that namespace's egress rules permit, and every other vantage point answers a different question:

kubectl run prism-egress-check -n <namespace> --rm -it --restart=Never \
  --image=<an image with curl that your registry serves> -- sh

Any image with curl will do — the destinations are the point, not the tool. On a cluster that can only pull what has been mirrored, use one you have already imported.

Then, for each destination that applies:

# Agent Router data plane — the one mandatory connection
curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "authorization: Bearer <your inference key>" "<your gateway>/models"

# Agent Router management plane — any HTTP response proves the route
curl -sS -o /dev/null -w '%{http_code}\n' "<your management plane URL>/"

# GitHub — this is the exact call the built-in upstream probe makes
curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer <your GitHub token>" "<your GitHub API URL>/rate_limit"

# Jira
curl -sS -o /dev/null -w '%{http_code}\n' "<your Jira base URL>/rest/api/2/serverInfo"

# SMTP relay — a TCP connect is the whole question here
nc -z -w 5 <relay host> <relay port> && echo open

# Snowflake — any HTTP status, a 401 included, proves the route
curl -sS -o /dev/null -w '%{http_code}\n' https://<account>.snowflakecomputing.com/api/v2/statements

# Oracle listener — the same question, and the answer the probe's
# "nothing answered at that host and port" refusal is telling you about
nc -z -w 5 <your listener host> <your listener port> && echo open

Read the result as two separate questions, in this order.

No response at all — a hang, a timeout, 000, a DNS or TLS error. The route is closed. This is an egress, proxy or firewall matter and no Prism setting changes it.
Any HTTP status at all, including 401 and 403 — the route is open. You have proved the thing this procedure exists to prove. A 401 or 403 is then a credential question, which is Take a source live for GitHub and Jira, and install step 1d for a Router key whose project does not match its gateway.

Keeping those two apart is most of the value here. "GitHub returned 403" sends someone to the token; "GitHub never answered" sends them to the network team. Guessing which, days later, from a chat that says nothing useful, is what this procedure replaces.

Not on this list, deliberately: anything inside the cluster. The app, the runner, the MCP servers and Postgres talk to each other over Service names and are not subject to your egress rules. And nothing inbound is required beyond end-user browser traffic reaching the ingress.

If a route will not open: send us the destination, the exact error, and whether a laptop on the corporate network can reach the same address. That last one is the fastest way to tell a namespace egress rule from a firewall rule.