Kubernetes / networking / policy
Selecting A Pod Is The Only Way To Deny
That a NetworkPolicy is a firewall rule, so you can write one that blocks something. There is no deny action, no ordering and no precedence: policies are additive and the allowed set is the union of every applicable rule. What people miss is that this makes the API do two unrelated things at once. Selecting a pod for a direction flips it from unrestricted to default-deny in that direction; rules then add connections back. So adding a policy widens access for pods it already covered and can annihilate access for a pod it newly selects, and the strongest object you can write is one with no rules in it at all. The defaults compound it: the API server puts Ingress in policyTypes whether or not you wrote an ingress section, so an egress-only policy silently denies all inbound traffic, and a port with no protocol means TCP, so an egress rule for port 53 breaks DNS.
A NetworkPolicy is not a rule that gets evaluated against a packet; it is a contribution to a set. Being selected by any policy for a direction makes a pod default-deny in that direction, and the only thing rules can then do is add connections back, so the deny you wanted is a side effect of selection and never something you wrote.
Where this is already explained
- The Gateway Reports On Its Own Denominator
That transparent interception means the gateway governs the agent's model traffic, because the words 'transparent' and 'no source changes' make coverage sound like a property of eBPF. It is a property of your hook set. A cgroup/connect4 program sees TCP over IPv4 from the processes in its scope, opening new connections — not IPv6, not a subprocess outside the scope, not a connection that was already established, and never a unix socket. Each of those is a live model call that never reaches the proxy. The failure is invisible because the gateway's own dashboard is computed over the calls it handled: a gateway governing 59.5% of the fleet reports 100% compliance, and the missing calls are not counted as violations, they are simply absent. On top of that, reading the request at all requires the payload to be readable, so a hosted model over TLS means terminating your own agents' connections with a certificate you issue; the proxy sits in the data path with a latency and a failure mode; and a gateway that rewrites prompts is your own infrastructure writing into the model's context.
- Kernel Enforcement Cannot See Intent
That putting Tetragon or Falco under an agent contains it, because eBPF sees everything and blocks in-kernel at microsecond latency. Coverage really is that good and the block really does hold. The gap is semantic: the hook sees an outbound connection to an allowed address, not that a prompt injection caused it or that the bytes are rows from a table the agent was never meant to query. Because a legitimate agent's paths, hosts and processes drift prompt to prompt, a learned allowlist is either loose enough to contain the attacker's primitives too or tight enough to break the agent — and the settings in between shrink to nothing as that drift grows. The designs that work concede this by construction: they use eBPF to see and to redirect, and put the decision at a layer that has the nouns — an L7 proxy, a per-agent identity, a network policy, an admission rule. The cost of not knowing that is a control that is trusted, correct, and produces no security.
2 published lessons depend on this concept, which is what moves it up the writing queue. Nothing is hidden behind this page — it has not been written.