feature: Per-agent egress scoping for AgentRuntime NetworkPolicies

[rhuss]

Summary

Add optional per-agent egress rules to AgentRuntime, allowing platform engineers to scope outbound traffic for verified agents instead of relying on the current allow-all egress default.

Context

The NetworkPolicy controller currently makes a binary decision based on agent verification status:

• Verified agents (mTLS or signature-verified): allow-all egress
• Unverified agents: egress restricted to K8s API server only (port 6443, CIDRs auto-discovered)

The allow-all egress for verified agents was introduced in commit e29e532 as a workaround for an OVN-Kubernetes limitation: port-only egress rules (e.g., "allow DNS on port 53" without destination IPs) are silently dropped by OVN-Kubernetes on OpenShift, breaking DNS resolution and external API access.

While verification proves an agent is trusted, allow-all egress violates the principle of least privilege. A compromised but verified agent could exfiltrate data to any destination.

Why this matters

In enterprise multi-agent deployments, agents call specific external endpoints (LLM APIs, databases, internal services). Platform engineers should be able to declare which destinations an agent is allowed to reach, so that the NetworkPolicy reflects least-privilege rather than "verified means unrestricted."

Proposed approach

Add an optional egress configuration to AgentRuntime that the NetworkPolicy controller reads when constructing the permissive policy:

• When no egress configuration is set: behavior is unchanged (allow-all egress for verified agents, backward-compatible)
• When egress rules are set: the controller uses the provided rules instead of allow-all

Rules should use standard Kubernetes NetworkPolicy egress format (CIDR-based ipBlock + ports). This is portable across all CNIs including OVN-Kubernetes, since CIDR-based rules (unlike port-only rules) are not silently dropped.

Design questions to resolve

1. Where does the egress config live? Options include a field on AgentRuntime.spec, a separate policy CRD, or a namespace-level ConfigMap. Each has different trade-offs for per-agent granularity vs. operational simplicity.
2. Should default rules (DNS, K8s API) always be injected? Omitting DNS from custom egress rules would break every agent silently. Should the controller merge user rules with a mandatory base set, or trust the user?
3. Interaction with the AgentCard deprecation. The NetworkPolicy controller currently watches AgentCard and reads ConditionVerified. As AgentCard is deprecated in favor of AgentRuntime (see Consolidate AgentCard into AgentRuntime status #371), the verification signal source and controller watch target need to change.
4. Scope of the verification decision. AgentRuntime's status.card already carries validSignature, attestedAgentSpiffeID, and transportSecurity. Is this sufficient to replicate the current permissive/restrictive decision, or does the full ConditionVerified evaluation (identity binding, strict mode) need to be ported?

Prior art

• Issue feature: Per-agent egress scoping for verified agent NetworkPolicies #224 proposed this feature on the AgentCard CRD. The design questions and CNI evaluation table there are still relevant, but the target CRD has shifted to AgentRuntime.
• The OVN-Kubernetes workaround was introduced in PR ✨ Feat: AgentCard signing production readiness and Helm chart fixes #221 (commit e29e532). The commit message notes that "the NetworkPolicy's purpose is to control ingress, not egress," treating egress scoping as explicitly out of scope at the time.
• The KubeRay project faces a similar problem with RayCluster egress and opted for CRD-level egress rules.

Acceptance criteria

• Platform engineers can declare per-agent egress rules on AgentRuntime
• Verified agents with custom egress rules get a scoped NetworkPolicy instead of allow-all
• Verified agents without custom egress rules retain allow-all behavior (backward-compatible)
• Custom egress rules work on OVN-Kubernetes (CIDR-based, not port-only)
• DNS and K8s API egress are always permitted regardless of custom rules
• The NetworkPolicy controller can derive verification status from AgentRuntime (not just AgentCard)

---

This issue will also serve as input for a 30-minute spec-driven development (SDD) demo session, demonstrating how brainstorming and specification surface design questions before implementation begins.