Workloads can call the tagging API to label themselves and policy trusts it — how do you fix issuance, and what does running it cost?

## What is actually broken Attribute-keyed segmentation makes a label a grant. If any workload can write its own policy-relevant labels, then compromising any workload is equivalent to being granted whatever the most privileged label reaches. The control did not fail; it was told a lie by a party permitted to speak. This is a design defect in issuance, and no amount of network-side enforcement fixes it, because the enforcement is doing exactly what it was told. The fix has four parts, and an interviewer wants all four plus the bill. ## 1. Split the label namespace Tags began as descriptive metadata — owner, cost centre, application name — and permission to write them was scoped accordingly: broadly, casually, to nearly everyone. The moment policy keys on an attribute, that attribute stops being metadata. So carve out a **restricted set of policy-relevant labels** (`tier`, `env`, `data-class`, whatever your rules name) and treat the rest as free-form. Two label spaces, two very different lists of writers. Without this split every hardening step you take collides with the legitimate, high-volume, low-risk tagging that teams do all day. ## 2. Deny self-assignment The workload's own runtime credential must not be able to write its own policy-relevant labels. This is the single highest-value rule, because it converts "compromise one workload" back into "compromise the deployment path", which is a much harder and much better-watched target. It also removes an entire class of accident: a script that re-tags its own host on startup and quietly grants itself database reach. ## 3. Make the deployment path the writer, from a declaration Labels are set at creation, by the pipeline, from a declaration that a human reviewed — the same review that gates the code. Two properties follow. First, the label has *provenance*: there is a record of who asked for it and who approved it, not merely a record that it exists. Second, the label change becomes visible in the same place as every other change to that service, so a request to move a workload into a more privileged tier gets read by the same reviewer who reads its dependencies. Scope write permission per label value where you can: a team may set its own service tier, but not `env=prod`, and not the label that grants ledger-database reach. ## 4. Reconcile, because drift is normal The gap between what a label claims and what the workload is does not stay closed. It opens through emergency changes made by hand during an incident, through workloads rebuilt outside the pipeline, through labels that were true when written and became false when the service changed shape. So run a reconciliation: for every workload, compare its current policy-relevant labels against what the deployment record says was launched, and report the differences. Treat unexplained differences as findings, not noise. Be honest in interview about what reconciliation proves. It proves the label matches the *deployment record*. It does not prove the workload is running what it should — that is a different problem with different machinery and it does not belong to the issuance path. ## What it costs, which is the half candidates skip The question asks what you now operate, and the answer is a service: - **An owner and on-call.** If the issuance path is down, nothing deploys with correct labels, and the workaround under pressure is a manual write — the exact thing you just forbade. So the failure mode of issuance must be designed, and someone must carry the pager. - **A review path with real latency.** Label changes now move at the speed of change review. Teams will discover that a five-second tag edit became a two-day ticket, and they will be unhappy, and some of them are right. - **An exception queue.** There are always legitimate cases — a migration, a test fleet, a vendor appliance nobody can put through the pipeline. Exceptions need an expiry date and a review, or they become the policy. - **Reconciliation toil.** The job will produce differences that are benign, and someone must work the list. A reconciliation nobody reads is worse than none, because it is cited as evidence. - **A permission review nobody scheduled.** The list of principals that may write policy-relevant labels has to be re-examined on a cadence, exactly like a firewall rule base. ## The framing that lands The honest sentence is: attribute-keyed segmentation does not remove work, it relocates it. You stopped maintaining address rules that decayed under churn, and you started running an issuance control with an owner, a queue and a review burden. That trade is usually right in an estate where addresses last hours — but a candidate who presents label-keying as pure simplification has not operated one.