TrustUsBank — an agentic AI demo with a runtime-defence story for DORA.

The idea in one line: make every outbound call go through one place — the waypoint — and have that place enforce a list of allowed destinations. Anything not on the list gets blocked.

How it works in practice:

1. You deploy Solo's agentgateway as a Gateway in a dedicated egress namespace.
2. Istio Ambient's data-plane (ztunnel) automatically routes every pod's outbound traffic through it — no app code or sidecar changes needed.
3. The gateway reads the destination hostname (SNI on TLS, Host on HTTP) and matches it against a list you maintain.
4. If the destination is on the list → traffic flows. If not → connection rejected, alert fires.

This is Istio's egress gateway pattern. It's the standard recommendation for any cluster that talks to external APIs.

What the YAML looks like, end-to-end:

# 1. The egress waypoint itself - a Gateway-API Gateway with class
#    enterprise-agentgateway-waypoint. Lives in its own namespace.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: trustusbank-egress
  namespace: trustusbank-egress
  labels:
    istio.io/waypoint-for: all     # this waypoint handles east+west AND egress
spec:
  gatewayClassName: enterprise-agentgateway-waypoint
  listeners:
    - name: http
      port: 443
      protocol: HTTP

# 2. Register every approved external partner as a ServiceEntry. Each
#    is on the audit register; adding a new partner is a PR.
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: openai
  namespace: trustusbank-egress
spec:
  hosts:
    - api.openai.com
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL
# ... repeat for api.frankfurter.app, api.anthropic.com, etc.

# 3. The deny-default. Anything outbound that ISN'T listed above
#    gets rejected by the waypoint. Match the egress namespace's
#    waypoint as the policy target.
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: egress-allowlist
  namespace: trustusbank-egress
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: trustusbank-egress
  action: ALLOW
  rules:
    - to:
        - operation:
            hosts:
              - "api.openai.com"
              - "api.frankfurter.app"
              - "api.anthropic.com"
              # anything else falls through to default-deny

Equivalent in Solo's higher-level abstractions: a single networking.gloo.solo.io/ExternalService per partner, with workspace-scoped audit + per-team RBAC on who can create them. Same enforcement, lighter manifest. The ExternalService writes the ServiceEntry for you.

The earlier callout glossed over this. Here's the concrete version with a worked example.

An AuthorizationPolicy in Istio has two halves: who is the source (the from stanza), and what destination (the to stanza). The source half can match on:

• SPIFFE principal (cluster.local/ns/X/sa/Y) — the cryptographic identity istiod baked into the pod's mTLS cert
• Namespace pattern (the kind-local shortcut the demo uses)
• IP CIDR (fragile, almost never used in production)

Production rules pin on the SPIFFE principal, not the namespace. The point is per-workload scoping: each policy is narrow to exactly the workload that should be restricted. Worked example:

Suppose your bank has two workloads that both legitimately call external APIs:

• mainframe-bridge (SA mainframe-bridge in core) calls api.openai.com as part of a sanctioned ops integration.
• currency-converter (SA currency-converter in bank-vendors) calls api.frankfurter.app for FX rates.

You'd write two narrow allow rules instead of one blanket "anyone can reach the internet":

# Allow mainframe-bridge -> openai only
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/core/sa/mainframe-bridge"
      to:
        - operation:
            hosts: ["api.openai.com"]

# Allow currency-converter -> frankfurter only
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/bank-vendors/sa/currency-converter"
      to:
        - operation:
            hosts: ["api.frankfurter.app"]

When the rugpulled currency-converter tries to POST to attacker.com, its SPIFFE identity is cluster.local/ns/bank-vendors/sa/currency-converter and the destination is attacker.com. Neither allow rule matches that (source, destination) pair, so the default-deny kicks in. The TCP handshake fails at the waypoint.

Crucially: the mainframe-bridge pod isn't impacted. Its legitimate call to api.openai.com still matches its own allow rule. Restricting one workload didn't break others. That's what "source-identity pinning" gives you over a coarse "block egress from the cluster" rule — surgical, not blunt.

"Won't this be hundreds of allow rules at scale?"

Fair question. Yes — a real bank has tens of internal services and dozens of approved external partners. But you don't write one giant allow list. The operational model is:

• Rules are scoped to the workload that owns them. The currency-converter team owns the currency-converter → api.frankfurter.app rule. The mainframe team owns mainframe-bridge → api.openai.com. Each team has 1-5 rules they need to care about, not 200.
• GitOps, not runtime config. Every allow rule lives in the workload's git repo. Adding a new partner is a pull request that goes through normal security review. The audit trail is the same one you already trust for code changes.
• Solo's ExternalService CRD is the maintainable abstraction. One CRD per third-party endpoint, declares the host + port + protocol + which teams can call it. The management plane translates each into a ServiceEntry + the relevant AuthorizationPolicy bits automatically. Adding a partner is one YAML file.
• Default-deny is non-negotiable for any serious environment. It's the same model as a cluster firewall (NetworkPolicy with implicit deny), or a perimeter firewall in a non-Kubernetes bank. The shock isn't "wow, deny-default is hard" — it's "we ever ran with allow-default for internal services in the first place." For an AI agent talking to third-party tools, the answer is unambiguously deny-default.
• Drift detection is built in. Prometheus alerts when a workload generates denied egress (= the rule list is missing something, or something's misbehaving). Workspaces auto-emit a report of "services that haven't been touched in 90 days" so stale allowlist entries get caught at the quarterly review.

Net: the policy file count grows with the workload count, but the policy per workload stays small. The bank already does this for firewall rules — Solo just expresses it in the same language as the rest of the mesh config.

This is one layer further down the rabbit hole. Even before the TCP connection to attacker.com attempts to open, the request is sitting in the agentgateway as a decoded MCP tools/call JSON-RPC envelope. The gateway can read the tool name AND the argument values, and apply a CEL expression against them.

For the rugpull case, the giveaway is that currency-converter.convert_currency is being invoked with a customer_profile argument that contains PII fields it has no business seeing. A pre-call policy can reject any tool call whose argument map smells like PII:

# manifests/phase05-agentgateway/deny-pii-in-tool-args.yaml
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayPolicy
metadata:
  name: deny-pii-in-tool-args
  namespace: trustusbank-platform
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: currency-converter-route
  traffic:
    authorization:
      action: Deny
      policy:
        matchExpressions:
          # Match: tool call AND args contain ANY PII-shaped key
          - 'mcp.method == "tools/call"'
          - 'mcp.tool.name == "convert_currency"'
          - 'mcp.tool.arguments.exists(k, k in ["customer_profile",
                                              "ni_number",
                                              "email",
                                              "dob",
                                              "address"])'

This fires before the agentgateway even forwards the call to currency-converter. From the LLM's view it gets a clean 403 Forbidden back from the gateway with a structured reason (reason=Authorization, error="PII field in tool args denied") — the same fields that would land in your Loki access log and DORA dashboard. The TCP egress block from layer 1a is the safety net; this is the proactive layer that stops the model from even trying.

Generalising it — one rule for any PII tool call

The example above is tool-specific (convert_currency). For a real bank you'd want a single, mesh-wide rule: "any tool call whose source workload handles PII must not include PII fields in its arguments." Two ways to express that:

Approach A — Label workloads, match on label. Tag the namespaces or pods that touch PII with a classification label, then write one policy that targets the label:

# 1. Label the source workload as PII-handling.
#    Anything tagged 'pii' has its tool calls inspected.
apiVersion: v1
kind: Namespace
metadata:
  name: trustusbank-bank-agents
  labels:
    data.solo.io/classification: pii

# 2. One policy, applied to every route on the agentgateway:
#    "if the source pod is in a pii-classified namespace and the tool
#     args contain any PII-shaped key, deny."
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayPolicy
metadata:
  name: deny-pii-leakage-mesh-wide
  namespace: trustusbank-platform
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: trustusbank-agentgw   # attach to the whole gateway, not one route
  traffic:
    authorization:
      action: Deny
      policy:
        matchExpressions:
          - 'mcp.method == "tools/call"'
          - 'source.namespace.labels["data.solo.io/classification"] == "pii"'
          - 'mcp.tool.arguments.exists(k, k in ["customer_profile",
                                              "email", "phone", "address",
                                              "dob", "ni_number", "ssn",
                                              "passport_number"])'

Now you don't have to add a new rule per tool. Tag any namespace that handles sensitive data with the pii classification and the single policy catches every tool call out of it.

Approach B — Content-based matching with Solo's DLP policy. Solo Gloo Mesh ships a DLPPolicy CRD (Data Loss Prevention) that does regex-based pattern matching on the request body itself. This catches the same PII shapes even when an attacker renames the argument keys (e.g. profile, ctx, userData) to evade an allow-list:

apiVersion: security.policy.gloo.solo.io/v2
kind: DLPPolicy
metadata:
  name: redact-pii-from-tool-calls
  namespace: trustusbank-platform
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: trustusbank-agentgw
  config:
    action: Reject   # or RedactInPlace if you want to allow + mask
    matchers:
      - name: ni-number
        regex: '[A-Z]{2}\s?\d{2}\s?\d{2}\s?\d{2}\s?[A-Z]'
      - name: email
        regex: '[\w._%+-]+@[\w.-]+\.[A-Z]{2,}'
      - name: uk-postcode
        regex: '[A-Z]{1,2}\d[A-Z\d]?\s?\d[A-Z]{2}'
      - name: credit-card
        regex: '\b(?:\d[ -]*?){13,16}\b'

DLPPolicy is the heavier hammer — it inspects the actual bytes. Combine both: Approach A catches the obvious cases at cheap (one CEL match), DLPPolicy catches the obfuscated ones at the cost of parsing each body. In a real bank both run together.