Mesh Egress Allowlist

By default the Mitrity Mesh Authorizer governs traffic inside the mesh (east-west and agent-to-agent, or A2A). The mesh egress allowlist extends governance to traffic leaving the mesh: an agent calling an external host. It enforces each agent's approved-destination list at the network layer, with the agent's identity intact, and denies egress to a host that is not on that agent's allowlist (or a host flagged by threat-intel).

This capability is opt-in and off by default. Enable it when you want the same per-agent destination control the gateway and sidecar provide, applied to mesh-resident agents' outbound traffic.

What it enforces

The mesh egress allowlist governs agent → external traffic against the per-agent destination allowlist -- the same "approved outbound domains" list you manage in the dashboard for any agent. On each egress request it:

Resolves the calling agent from its SPIFFE identity (namespace + ServiceAccount -- see Per-Agent Identity in the Mesh).
Classifies the request as outbound.
Checks the external host against that agent's destination allowlist.
Allows the request if the host is on the allowlist; denies it if the host is not on the allowlist, or if threat-intel flags the host.

It is network-layer (L3/L4): it sees the agent identity and the destination host/SNI, but it does not terminate the agent's own TLS, so it does not inspect the egress body or prompt. Content inspection on egress -- prompt/body inspection and redaction for egress traffic (DLP on prompts / wire-redaction) -- is not yet available -- see Boundaries.

You manage the destination list itself in the dashboard, not here. This page is about turning egress enforcement on in the mesh; the allowlist entries, patterns, and the DLP events egress produces are documented under Destination Allowlists.

How per-agent identity survives egress

There is an important mechanism behind egress governance. Istio's CUSTOM authorization filter fires on the destination's inbound sidecar -- so for the Authorizer to see both the agent's identity and the external host, the egress has to reach an inbound sidecar that the Authorizer governs.

The proven path routes the agent's egress through an in-cluster egress hop over mesh mTLS (which preserves the agent's SPIFFE identity), and that hop terminates TLS in-mesh toward the upstream. Its inbound sidecar runs the egress authorization policy, so the Authorizer sees the agent identity and the real external host, resolves the agent, and enforces the allowlist on that host.

Why not just route raw external HTTPS straight out? Routing egress as raw TLS passthrough through an Istio egress gateway is a validated dead-end for identity-aware governance: on a real Istio cluster the authorization callout never reached the Authorizer (the passthrough handshake completed before any decision, and the agent's identity was not delivered). True external-HTTPS TLS-passthrough egress is destination/SNI-only at best and is not productionized. For per-agent egress governance, the egress hop must terminate TLS in-mesh -- the path above. Do not expect MITRITY to govern arbitrary passthrough egress with per-agent identity.

Enabling mesh egress enforcement

Mesh egress enforcement requires three things in place:

Egress is locked down to a registry. Set Istio's outbound traffic policy to REGISTRY_ONLY so external hosts are reachable only through declared ServiceEntry destinations -- otherwise agents can bypass the hop.
An in-cluster egress hop that terminates TLS toward the upstream. Per-agent identity depends on this; a passthrough hop will not work (see above).
The governed agents have a populated destination allowlist -- DLP enabled with their approved outbound destinations set in the dashboard.

Enable egress governance on the Mesh Authorizer Helm release and point it at your egress hop:

Value	Effect
`istio.egress.enabled`	master switch for the mesh egress allowlist (default `false`)
`istio.egress.hosts[]`	the governed external hosts (host / port / protocol) -- one `ServiceEntry` is created per host
`istio.egress.inMeshEgressHost`	the in-cluster egress hop the hosts route to (must terminate TLS for per-agent identity)
`istio.egress.authorizationPolicy.namespace`	namespace of the egress hop workload
`istio.egress.authorizationPolicy.selector`	required -- labels of the egress hop workload (not the agents)

helm upgrade mitrity-mesh-authorizer \
  oci://ghcr.io/mitrity-io/charts/mitrity-extauthz --version 0.12.0 \
  --namespace mitrity-system --reuse-values \
  --set istio.egress.enabled=true \
  --set istio.egress.inMeshEgressHost=<your-in-mesh-tls-terminating-egress-host> \
  --set istio.egress.authorizationPolicy.namespace=istio-system \
  --set istio.egress.authorizationPolicy.selector.app=<egress-hop-workload-label>

Also set meshConfig.outboundTrafficPolicy.mode: REGISTRY_ONLY on your Istio install (mesh-wide config -- see Deploy in Istio) and declare each governed external host as a ServiceEntry routed to the egress hop.

Verifying egress enforcement

From a governed agent workload, an allowed external host should succeed and a host outside the allowlist (or a threat host) should be denied:

# An external host on the agent's allowlist -> ALLOW.
kubectl exec -n agents deploy/<some-agent> -c <app> -- \
  curl -s -o /dev/null -w '%{http_code}\n' https://<allowlisted-host>/<path>

# A host NOT on the agent's allowlist -> DENY (403).
kubectl exec -n agents deploy/<some-agent> -c <app> -- \
  curl -s -D - -o /dev/null https://<non-allowlisted-host>/<path>

A denied egress also produces an unauthorized_destination DLP event in the dashboard, with the agent's identity preserved -- see Destination Allowlists for the DLP event types and how to review them.

Boundaries

The mesh egress allowlist is honest about its limits:

Network-layer only. It enforces a per-agent destination / SNI allowlist (plus threat-intel on the destination) at L3/L4, with the agent's identity. It does not terminate the agent's TLS, so it does not inspect the egress body or prompt.
DLP on prompts / wire-redaction is not yet available. Prompt/body inspection and redaction for egress traffic would need in-mesh TLS termination of the agent's own traffic. That capability is not yet available; a DLP redact verdict fails closed to a deny.
Raw external-HTTPS passthrough egress is not governed per-agent. Per-agent identity requires the in-cluster TLS-terminating hop, as described above.