The prevailing approach to egress filtering—maintaining extensive allowlists of IPs and domains for agent communication—is fundamentally reactive and difficult to maintain. While network-layer controls provide a valuable defense-in-depth layer, they treat the symptom, not the cause. The core issue is that our agents currently possess omnipotent network access, and we try to wall it in with filters.

A capability-based model addresses the root cause. Instead of an agent having implicit permission to connect anywhere its host network allows, it should only hold explicit, unforgeable credentials (capabilities) for specific, authorized resources. This shifts the security boundary from the network perimeter to the agent's own internal authorization logic.

Consider the difference:
* **Filtering Model:** Agent has system credentials. Firewall rules attempt to block all egress except to `api.updates.example.com:443`. A vulnerability in the agent could allow it to exfiltrate data via DNS tunneling or reuse credentials on a different, internal service.
* **Capability Model:** Agent holds a cryptographically-scoped token, bound to its identity, that only authorizes `POST` requests to a specific path on `api.updates.example.com`. Even if the agent's process is compromised, the capability cannot be reused for other endpoints or hosts.

The technical foundation for this exists today. We should be designing agents that:
* Use short-lived, attestation-backed credentials (e.g., SPIFFE/SPIRE, short-lived X.509 certs from an HSM-backed CA).
* Embed explicit authorization in these credentials (e.g., `scope: updates.write`).
* Have no built-in secrets for broad access; all network access is gated by a capability-challenge.

This would render most egress filtering rules redundant, as the agent simply lacks the cryptographic means to initiate a meaningful connection to an unauthorized destination. The network policy could then default-deny, serving as a final failsafe rather than the primary control.

A minimal proof-of-concept for a capability-bearing gRPC call might involve a signed request attestation:

```proto
message UpdateRequest {
bytes payload = 1;
string capability_token = 2; // JWT or similar, signed by internal CA
bytes client_attestation_document = 3; // e.g., AWS Nitro Enclave document
}

service AgentUpdate {
rpc PushUpdate(UpdateRequest) returns (UpdateResponse) {
option (google.api.method_authorization) = {
// Authorization is evaluated based on the token's claims, not source IP.
};
}
}
```

The conversation should move from "what IPs should we allow?" to "what precise actions should this agent instance be capable of performing, and how do we cryptographically enforce it?"