How can a workload gain new microsegmentation reach with no rule change and no reviewer seeing it?

## Two inputs, one of which is reviewed Microsegmentation at scale is only tractable because rules are not written per machine. You write `tier=app -> tier=db : tcp/1433` once, and the platform compiles it into the filter set of every virtual NIC whose workload currently matches. The compiled output is therefore a function of two things: 1. **the rule text**, which lives in the policy repository and goes through change review; and 2. **the membership**, which lives in the inventory - a tag, a label, a custom attribute, a folder, a naming convention - and is usually set by build automation or the platform team. Only the first has a reviewer attached to it. The second is treated as inventory metadata, which is exactly the misconception: **membership is a permission grant**. ## What that looks like on the day A change record shows an empty policy diff and two tags applied to a newly built virtual machine. After compilation, that machine carries rules approved in 2021 and 2023 that nobody re-opened, including an intra-tier rule permitting members of the group to talk to each other on any port. Nothing in the change asked a reviewer to consider that. Nothing in the rule base changed. The estate's permitted set grew. ## Why an adversary cares Two distinct routes, and they deserve separating. - **Deliberate.** If the attribute that drives membership can be set from a place the attacker already holds - a provisioning API, a self-service build pipeline, an inventory field editable by application owners, a name the automation pattern-matches on - then group assignment is a privilege-escalation primitive that produces no policy change to review. The control plane that sets tags is now as sensitive as the policy itself, and it is very often not treated that way. - **Accidental, and more common.** A workload is mis-tagged by a template, a copied build definition or a typo, and inherits a permission set intended for something else. It is a benign true positive with a real security consequence: an ordinary application server sitting inside the group that may reach the payments or actuarial tier. Either way, the reviewer's artefact never showed it, which returns you to this leaf's central problem: nobody can state what the set permits in aggregate, and the intruder's route is inside exactly that blind spot. ## What it costs to close There is no free version. - **Review membership too.** Correct in principle, unaffordable in practice at several thousand workloads with continuous provisioning. If you do it uniformly, you have doubled a review queue that is already being rubber-stamped. - **Review membership selectively.** Realistic. Pick the groups that appear as the *source* of a rule reaching something you care about, and gate membership in those groups only. It is a small list, it is defensible to an auditor, and it leaves the bulk of provisioning untouched. - **Render the delta as reach, not as tags.** A reviewer shown `tier=app added` cannot judge anything. A reviewer shown `this workload may now reach the actuarial data store on tcp/1433, and 412 peers on any port` can. Same computation, different artefact. - **Pin the crown jewels to explicit membership.** For the handful of rules protecting the highest-value destinations, name the workloads rather than a dynamic group. You lose the automation benefit exactly where you can afford to. - **Treat the tagging plane as a security boundary.** Who may write the attribute, is that write logged, and does the log get read. ## The intra-group rule deserves its own paragraph An `allow any` between members of the same group is the single most consequential line in most of these policies, because it converts membership into the whole control. Everything in the group is mutually reachable on every port. One mis-tagged or compromised member is inside a flat network with the rest, and the policy document still reads as microsegmentation. When you audit a generated policy, find these first - they are where the grain you paid for quietly disappears. ## The claim to get right "Nothing can change without a change request" is false here, and stating it confidently is the failure this question is aimed at. The policy *text* cannot change without one. What is *enforced* can, and does, several times a day.