Workload Identity, Secrets, Privacy, and Compliance
Define who or what acts, which authority it receives, how credentials are delivered, and how information obligations persist across the factory.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Define who or what acts, which authority it receives, how credentials are delivered, and how information obligations persist across the factory.
- Best for: Security, platform, architecture, privacy, legal, and compliance owners.
- Prerequisites: Security and Identity Architecture.
- Reading time: 15 minutes.
- You will learn: Workload identity, delegated authorization, secret delivery, tenancy, retention, residency, provenance, licensing, and control evidence.
- Keep three ideas: identity is not authority; secrets should be short-lived and attempt-scoped; and compliance evidence follows data and artifacts end to end.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Trace one Attempt from a human-approved WorkOrder through workload identity to repository, model, artifact, and deployment tools. Add cross-region data, cancellation, secret leakage, and a deletion request. Mark every control and retained audit fact.
3. Enduring Principle
Bind every action to an identity chain
Record accountable human or system owner, authorized WorkOrder, orchestration service, worker workload identity, agent and capability versions, tool credential, and external actor. The chain explains both delegation and the point of enforcement.
Issue least-privilege, short-lived authority
Use workload identity to obtain attempt-scoped credentials for exact resources and operations. Separate read, modify, publish, merge, deploy, approve, and administer permissions. Tokens expire, cannot be reused across tenants, and are revoked on cancellation or quarantine.
Separate secrets from context
Deliver secrets through controlled channels directly to tools or processes. Prevent them from entering prompts, memory, logs, diffs, artifacts, screenshots, or model output. Scan and redact, but rely first on architecture that avoids exposure.
Govern information throughout its lifecycle
Classify source, prompts, context, telemetry, artifacts, evidence, memory, and backups. Define allowed purpose, provider, region, encryption, access, retention, deletion, legal hold, and incident handling. Deletion workflows must address derived indexes and backups while preserving required audit evidence lawfully.
Preserve intellectual-property and license provenance
Track source and licenses for dependencies, training or reference material where applicable, generated artifacts, copied snippets, and capability packages. Policy determines acceptable licenses and attribution. Similarity or provenance concerns create review, not automatic acceptance.
Map controls to evidence
Policy-as-code can enforce repeatable rules, but control ownership, rationale, exceptions, sampling, and audit artifacts remain explicit. Compliance frameworks are mappings over operating controls; they do not replace the threat model.
8. Notes and lessons learned
The useful question is not “which agent did this?” It is “which accountable chain delegated which exact authority to which workload, using which credential, for which subject and purpose?”
9. Interview and discussion questions
- How does workload identity differ from an API token?
- Why should a secret bypass the model context?
- What must a deletion workflow include?
- How do license controls enter a capability supply chain?
- Why is policy-as-code insufficient by itself?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence