Mesh Enforcement (Istio)

The Mitrity Mesh Authorizer governs agent traffic inside an Istio service mesh. It is a third deployment surface alongside Mitrity Gateway and Mitrity MCP Sidecar -- but instead of wrapping an MCP server, it runs the same MITRITY decision engine at an Istio mesh decision point. Every governed request in the mesh is evaluated by the same brain: intent / mission-scope, agent-to-agent (A2A) delegation-chain state, threat-intel / injection, and DLP, with mission-scoped credential injection on allow.

Use the Mesh Authorizer when your agents and the tools they call already run as workloads in an Istio mesh and you want to govern them without changing application code or routing traffic through a separate MCP gateway.

Same decision engine, a different decision point

Mitrity Gateway and Mitrity MCP Sidecar see MCP tools/call requests directly -- the agent's identity is the agent_id it presents. The Mesh Authorizer instead sits behind Istio's authorization layer: Istio calls it as an authorization provider (Envoy ext_authz is the technical mechanism) on the destination's inbound sidecar for every governed request. The Mesh Authorizer extracts the request, resolves which agent is calling, and runs the exact same governance pipeline the other two binaries run. Allow, deny, and credential-injection behavior are identical -- only the integration point differs.

Because all three surfaces report to the same MITRITY control plane, you get unified policy, audit, and visibility regardless of which surface enforces a given request. Audit events are tagged with the surface that produced them, so you can tell mesh decisions apart from gateway and sidecar decisions.

The identity model: SPIFFE ServiceAccount to agent to policy

In a mesh with mutual TLS, every workload presents a verifiable SPIFFE identity derived from its Kubernetes namespace + ServiceAccount. The Mesh Authorizer reads that identity from the request (source.principal) and resolves it to a MITRITY agent:

SPIFFE source.principal
  spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>
        │
        ▼  (namespace + ServiceAccount → agent)
   MITRITY agent
        │
        ▼
   that agent's mission profile + policy  →  allow / deny / inject credentials

This identity logic lives inside the Mesh Authorizer by design. Istio's CUSTOM authorization rules cannot match on source.principal (the caller's SPIFFE identity) -- that is an Istio constraint. So you select which workloads, ports, and paths are governed in Istio, and the Mesh Authorizer consumes the SPIFFE identity itself, maps it to the bound agent, and applies that agent's policy.

You bind a MITRITY agent to its mesh identity (namespace + ServiceAccount) in the dashboard. See Per-Agent Identity in the Mesh for the full binding workflow and the rules that make it work -- including why STRICT mTLS is mandatory and why unmapped identities are denied by default.

What the Mesh Authorizer governs

The Mesh Authorizer covers two traffic surfaces:

East-west & agent-to-agent (A2A) traffic

The default, always-on coverage. It governs:

East-west (agent → tool): an agent workload calling a tool / service workload inside the mesh.
A2A (agent → agent): one agent workload calling another. A2A hops are additionally evaluated for delegation-chain state (cycle, depth, and privilege-escalation checks) via the control plane.

Both are governed cleanly: the CUSTOM authorization filter fires on the destination's inbound sidecar, so the Mesh Authorizer sees both the caller's identity and the request.

Egress allowlist (outbound governance)

An opt-in capability that governs agent → external traffic against each agent's destination allowlist. It enforces the per-agent approved-outbound-domain list at the network layer (L3/L4), with the agent's identity intact, and denies egress to a host that is not on the allowlist (or a host flagged by threat-intel). See Mesh Egress Allowlist for how it works and how to enable it.

Capability and scope

The table below is the honest, end-to-end statement of what the Mesh Authorizer enforces today. "Enforced" means the decision blocks traffic; "Advisory" means it is recorded but does not block; "Deny-on-redact" means a DLP redact verdict becomes a deny rather than a wire-level rewrite.

Capability	Status at the Mesh Authorizer
Intent / mission-scope enforcement	Enforced (allow / deny)
A2A delegation-chain state	Enforced (allow / deny)
Threat-intel / injection on the tool identity	Enforced (allow / deny)
DLP -- block action	Enforced (deny)
Mission-scoped credential injection	Active -- broker-minted credentials added as upstream headers on allow
AIBOM (tool supply-chain risk)	Advisory-only -- recorded on the decision trace; does not deny
DLP -- redact action	Deny-on-redact (fail-closed) -- the Mesh Authorizer cannot rewrite the request body on the wire, so a redact verdict becomes a deny
East-west / A2A coverage	Governed cleanly -- the CUSTOM authorization filter fires on the destination's inbound sidecar
Egress destination/SNI allowlist	Enforced on the in-mesh egress path (opt-in) -- per-agent allowlist + threat-intel on the external host, with the agent's identity preserved

What it does not do yet

The Mesh Authorizer is deliberately honest about its boundaries:

DLP on prompts / wire-redaction is not yet available. Prompt/body inspection and true content rewriting on the wire would require in-mesh TLS termination on the egress hop, and that capability is not yet available. A DLP redact verdict therefore fails closed to a deny today.
AIBOM is advisory at the mesh. Tool supply-chain risk is recorded on the decision trace but does not block.
It does not govern raw external-HTTPS TLS-passthrough egress with per-agent identity. Preserving an agent's identity on egress requires an in-cluster TLS-terminating hop. Routing egress as raw passthrough is a validated dead-end for identity-aware governance -- see Mesh Egress Allowlist.

Requirements and supported versions

The Mesh Authorizer targets Istio sidecar mode and requires STRICT mTLS on every governed namespace. Key honest constraints:

Tested on Istio 1.24 / Kubernetes 1.29. This is the version the in-mesh and egress end-to-end suites run against, and the version MITRITY stands behind.
API floor is Istio ≥ 1.20 (the version where the extensionProviders mechanism the Mesh Authorizer relies on became generally available). Istio 1.20–1.23 and ≥ 1.25 are expected to work on the same API surface but are not in the test matrix -- validate them in staging before relying on them. Do not assume "any 1.20+".
Istio ambient mesh (ztunnel + waypoints) is unsupported. The design assumes a per-workload Envoy sidecar supplies the SPIFFE identity. Run governed namespaces in sidecar mode.
STRICT mTLS is mandatory. Without mTLS, no SPIFFE identity is presented, and the Mesh Authorizer fails closed (deny). See Per-Agent Identity in the Mesh.

Full prerequisites, the Helm install, and verification are covered in Deploy in Istio.