Egress: deny it at the network

Egress: deny it at the network

The detection container has no legitimate reason to make outbound internet connections. It receives text, runs local models, returns spans.

Deny egress at the network policy, not in application configuration. internal: true in the compose fragment above, a NetworkPolicy with no egress rule in Kubernetes, a security group with no outbound rules in a cloud VPC.

This single control neutralises a category of outcomes. A compromised dependency that phones home cannot. A malicious model artefact that beacons cannot. Data staged for exfiltration has nowhere to go. It costs one configuration block and it is the highest-value control in this chapter after "do not log the data".

The same applies to the gateway, with one exception: the gateway must reach the model provider. Allowlist that one host and deny the rest.

Provenance: pin by digest

Pin images by digest, not by tag, as image: presidio-analyzer@sha256:<digest> in the fragment above. A tag is a mutable pointer, so :latest and even :2.2.358 can be repointed at different bytes.

Know who builds the image and from what. This is not hypothetical diligence. Presidio moved out of the Microsoft GitHub organisation and is transitioning to community ownership under the Data Privacy Stack organisation. The project is actively maintained and the move is orderly, so this is not an argument against using it. It is a demonstration that the answer to "who maintains the component that sees all our personal data" is not fixed at adoption. Review it on a schedule, the way you review anything else that can change without telling you.

Verify signatures where the project publishes them, and mirror images into your own registry so that a deleted upstream tag does not become an incident.

Identity and least privilege

Non-root user. All capabilities dropped. no-new-privileges. Its own service identity rather than a shared one. Authenticated callers only, so that anything on the network cannot submit text and read findings.

The compose fragment above does the container half. The authentication half belongs to your platform: mutual TLS, a service mesh identity, or at minimum a bearer token the gateway holds and nothing else does.

Scope the identity tightly. The sidecar needs to accept connections and nothing else. It should not have credentials to your database, your key vault, your object storage, or your cloud account.

Lifecycle

The container ages. The NER model inside it ages. The Python dependencies age faster than either.

Two consequences. Patching is continuous, and a detection container running an eighteen-month-old base image is a liability regardless of how good its detection is. Model updates change behaviour, which is why Chapter 7's golden-set test runs in CI. An upgrade that improves overall accuracy and halves recall on PERSON should fail a build.

Put a review date on the component. Who maintains it, what version are we on, when did we last measure it, when did we last patch it. Four questions, quarterly.

The boundary of this chapter

Each of the seven controls above is the shallow end of a discipline with its own literature, its own tooling, and in several cases its own full-time roles.

Out of scope here, named so you know what you are not getting:

• Key management and rotation. "Put the key in a KMS" is one sentence covering envelope encryption, rotation schedules, key hierarchies, break-glass procedures, and what happens to a vault encrypted under a key you rotated.
• Secrets management. How the sidecar gets its certificate, how it is renewed, what happens when it expires at three in the morning.
• Supply-chain attestation. SBOMs, provenance attestation, signature verification in admission control, reproducible builds.
• Cluster policy and runtime security. Admission controllers, pod security standards, runtime detection, network segmentation beyond one deny rule.
• Threat modelling the deployment itself. Which is worth doing and is a workshop, not a checklist.

This chapter gives you the controls that matter most for this specific component, in a form you can implement this week. Appendix C is the same content as a one-page checklist. A complete hardening programme for a regulated production environment is a different body of work, and treating a checklist as equivalent to that work is the failure mode this section exists to prevent.

The honest position: implement these seven and your detection sidecar is defensible in a security review and materially better than most deployments of its kind. It is not the same thing as having done platform security properly, and you should not tell anyone it is.

Door one is closed, the components that close it are trustworthy. The remaining doors are the ones most teams have never opened, and they hold considerably more data.

Sources for this chapter

• Presidio's move out of the Microsoft GitHub organisation to community ownership — https://presidio.dataprivacystack.org/ · Used here as the provenance example.
• Egress control, provenance-aware deployment and tool-call payload auditing as mitigation directions — named across the agent-security literature cited in Chapter 15.
• Container controls (read-only root filesystem, tmpfs, non-root UID, dropped capabilities, no-new-privileges, digest pinning, network policy) — standard container hardening practice; see the Docker and Kubernetes security documentation for each directive.

This chapter is explicitly a summary. The seven controls, their ordering, and the observation that the detector sees 100% of your personal data are the author's framing. Every control named is the shallow end of a discipline with its own literature, which the chapter states at the end and Appendix C repeats.