Stop Authority Amplification
Primary source: [Hugging Face technical timeline](https://huggingface.co/blog/agent-intrusion-technical-timeline) • Defensive references: [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) and [AWS EKS identity guidance](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html)
The enterprise problem and today’s slice
Enterprise problem: A contained code-execution foothold becomes an enterprise incident when workload, node, cluster, network, broker, and source-control credentials amplify one another.
Whole-course context: We consume the qualified evidence ledger and Day 02 feedback-loop map, then ask where an independent control would have stopped reuse of authority.
Today’s slice: We trace one malicious dataset configuration from evaluator foothold to progressively broader authority and design containment at every handoff.
End-of-day evidence: An authority graph, earliest-break decision, negative-path test matrix, and revocation proof tied to immutable traces.
Still unsolved: Organization-specific incident response, procurement, and forensic conclusions outside the public record remain out of scope.
Thesis: Preventing the first bug is valuable, but preventing authority amplification is decisive: no workload foothold should automatically become node, cluster, network, secret, or supply-chain authority.
The smallest complete model is foothold → authority acquisition → independently revocable action. The middle edge, where access becomes reusable credential or role, is the leverage point.
Role-based access control (RBAC) maps an identity to allowed actions. The Instance Metadata Service (IMDS) exposes cloud-instance identity and metadata; a pod that can reach it may inherit authority intended for its node.
Customer use cases
Operators need a boundary-by-boundary control map because “least privilege” without a concrete negative path cannot show where amplification stops.
| Use case ID | Actor | Customer job | Success outcome | Denial or recovery evidence |
|---|---|---|---|---|
| D03-UC-01 | Platform security owner | Prevent workload compromise from becoming infrastructure authority | Evaluator identity cannot access metadata, privileged pods, unrelated secrets, VPN, broker, or source control | Each prohibited transition is denied and an unaffected workload remains healthy |
| D03-UC-02 | Incident commander | Revoke acquired authority and prove containment | Credentials, sessions, workloads, and dependent grants are invalidated within measured bounds | Replayed credentials fail, affected resources are reissued, and immutable evidence shows completion |
Actor-centred user stories
Prevention and recovery must share the same authority graph or responders will rotate credentials without knowing their downstream dependants.
| Story ID | Use case IDs | User story | Observable acceptance conditions |
|---|---|---|---|
| D03-US-01 | D03-UC-01 | As a platform security owner, I want every authority transition explicitly granted, so that one compromised workload cannot inherit another plane’s privileges | Tests deny metadata, privileged workload, cross-namespace secret, private-network, broker-admin, and source-write transitions |
| D03-US-02 | D03-UC-02 | As an incident commander, I want dependency-aware revocation, so that containment removes both the credential and every session derived from it | Revocation report names credential lineage, terminal denial, unaffected controls, completion time, and trace IDs |
End-to-end product flows
An authority review starts at the platform action that creates a workload identity and ends with observable positive and negative decisions.
| Flow ID | Use case IDs | Path | Trigger | Numbered steps | Terminal evidence |
|---|---|---|---|---|---|
| D03-FLOW-01 | D03-UC-01, D03-UC-02 | Happy | Platform owner launches the bounded authority test | 1. Issue a short-lived evaluator identity. 2. Perform its declared evaluation action. 3. Record the scoped authorization. 4. Expire the identity. | Allowed action, policy digest, actor, resource, scope, expiry, environment, and immutable trace ID |
| D03-FLOW-02 | D03-UC-01 | Denied | Evaluator workload requests authority outside its declared job | 1. Resolve workload identity. 2. Evaluate capability and resource scope. 3. Deny cross-boundary transition. 4. Alert on attempted amplification. 5. Run unaffected positive control. | Denial decision, policy digest, actor, resource, scope, environment, time, control result, and trace ID |
| D03-FLOW-03 | D03-UC-01, D03-UC-02 | Recovery | Incident commander activates containment graph | 1. Freeze new evaluations. 2. Revoke workload and broker sessions. 3. Rotate exposed credentials. 4. Replace affected workloads. 5. Replay negative tests. 6. Resume by approval. | Signed containment report with credential lineage, measured revocation times, negative replays, and approval ID |
System design derived from the flows
The control plane must make authority transitions explicit and independently revocable, because network reach or membership in one plane must not imply another plane’s permission.
| Use case ID | Entry point | Responsible services | Authoritative store | Failure evidence |
|---|---|---|---|---|
| D03-UC-01 | Workload-identity issuance | Identity broker, metadata firewall, admission policy, RBAC authorizer, egress gateway | Signed authority-policy registry | Any undeclared transition succeeds or lacks an immutable decision |
| D03-UC-02 | Incident containment console | Credential-lineage service, revocation orchestrator, workload reconciler, evidence signer | Append-only containment register | Derived session remains valid after deadline or negative replay is absent |
Data model and ownership
Revocation cannot be complete without credential lineage, because a root credential may have minted sessions that outlive its rotation.
Generated-application database: Not created in this slice — identity, policy, and containment services own durable authority and evidence state.
| Record or entity | Store and owner | Primary key | Foreign key or opaque reference | Tenant key | Material constraint | Lifecycle and deletion | Use case IDs |
|---|---|---|---|---|---|---|---|
| Authority grant | Policy registry / platform security | grant_id | workload_identity_id | organization_id | Resource, action, purpose, expiry, and issuing policy digest required | Expire automatically; retain audit revision | D03-UC-01, D03-UC-02 |
| Credential lineage | Identity store / credential broker | credential_id | parent_credential_id or None — root issuer | organization_id | Every derived session names parent and maximum lifetime | Revoke descendants; delete secret material after retention | D03-UC-01, D03-UC-02 |
| Containment run | Containment register / incident response | containment_run_id | incident_id and affected credential references | organization_id | Completion requires negative replay and unaffected control | Append-only; retain per incident policy | D03-UC-01, D03-UC-02 |
Failure modes, trade-offs, and decision rules
Convenient shared administration reduces operational friction but turns one compromised credential into a multiplier.
| Failure mode | Trade-off | Reusable decision rule |
|---|---|---|
| Auto-mounted service-account token | Easy API access versus ambient cluster authority | Disable automount and issue short-lived audience-bound identity only when required |
| Instance metadata reachable from pods | Simple cloud integration versus node-role theft | Use workload identity and enforce metadata isolation |
| Privileged pod plus host mount | Operational convenience versus node-root path | Deny privileged, host namespace, and host-path use except isolated break-glass pools |
Shared system:masters broker credential | Fast multi-cluster administration versus total trust collapse | Use per-cluster, task-scoped, short-lived roles outside bypass groups |
| Source-write credential reachable from runtime | Automated delivery versus supply-chain amplification | Separate runtime and delivery identities; require signed, reviewed promotion |
AWS recommends scoping pod identity and restricting instance metadata in its EKS identity guidance, while the EKS pod-security guidance explains layered workload controls. Kubernetes warns that granting workload-creation rights can implicitly grant access to service accounts and other resources in its RBAC guidance.
Implementation and verification
Control diagrams are insufficient unless every authority edge has a negative test and a recovery deadline.
- Export workload-to-role, role-to-resource, credential-to-session, network, and source-control relationships into one authority graph.
- Remove shared bypass-group membership and long-lived cross-plane credentials.
- Enforce workload identity, metadata isolation, restricted admission, namespace secret scope, segmented egress, and signed promotion.
- Test denied transitions from an ephemeral evaluator identity while a safe evaluation remains healthy.
- Revoke one test credential and measure invalidation of every derived session.
Do not test by reproducing the intrusion. Use synthetic identities and harmless requests that prove authorization decisions without touching production secrets or executing untrusted payloads.
Practical next action and falsifiable evidence
Choose the highest-volume evaluator namespace and build its authority graph this week. Rank transitions by blast radius, then implement the earliest circuit breaker that preserves the declared evaluation job.
The design is falsified if a synthetic evaluator identity can read instance metadata, create a privileged workload, read an unrelated secret, join a private network, obtain broker administration, write source, or retain any derived session past the revocation objective. Observable proof is a signed run containing actor, resource, scope, precondition, expected and observed result, environment, timestamp, immutable trace ID, unaffected positive control, and measured revocation latency for every edge.