Security and Identity Architecture
An AI Software Factory connects human intent to code, credentials, repositories, tools, and delivery systems. A confused identity boundary can let a browser pretend to be an agent, a service inherit human authority, or a repository credenti
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Draw the complete principal chain from human Plan approval to service dispatch, executor claim, GitHub token, webhook return, and human merge. Mark credentials, trust boundaries, authorization checks, revocation, and audit receipts.
3. Enduring Principle
Authenticate the principal; authorize the action; attest the execution
Authentication proves who or what is calling. Authorization proves that the principal may perform a bounded action. Attestation proves which software, configuration, context, and environment actually performed it.
Keep principal types separate
- A human identity owns accountable decisions.
- A service identity performs named machine capabilities.
- An agent identity links behavior, version, and provenance.
- An executor identity owns one runtime process or claim.
- A provider identity, such as a GitHub App installation, crosses one external trust boundary.
Do not create fake human users for automation or reuse one omnipotent “system” role. Delegation should preserve the human or policy authority that initiated it without giving the delegate every right of the delegator.
Apply least privilege in several dimensions
Scope authority by company, workspace, repository, environment, resource, action, path, tool, time, budget, and Attempt. Credentials should be short-lived and minted only after policy and readiness checks. Stronger-than-required provider grants are a readiness failure, not a convenience.
Treat all external content as untrusted
Repository files, issues, web pages, MCP resources, tool results, logs, and memory can contain hostile instructions. The runtime should label them as data, constrain size and format, strip active content where possible, scan for secrets, and prevent them from changing system instructions or tool policy.
Separate secrets from evidence
Secrets should enter only the process that needs them, for the shortest useful time. They must not appear in prompts unless necessary, structured events, artifacts, screenshots, error messages, or audit payloads. Audit should record secret identity or version, never secret value.
Design for revocation and compromise
Disabling a human, service, agent version, MCP server, repository installation, or policy must stop new authority promptly. Active executions need explicit revocation semantics: cancel, quarantine, rotate credentials, reconcile effects, and retain the incident trail.
Audit denials as well as successes
A denial can reveal attack, drift, misconfiguration, or a healthy control. Audit records need principal, capability, scope, decision, policy version, time, reason, and correlation identity without retaining sensitive payloads.
8. Notes and lessons learned
Mission Control’s strongest security design choice is identity separation. Its most important current limitation is incomplete enforcement across the full golden path. Both facts belong in the same explanation.
9. Interview and discussion questions
- Why is an agent identity not a human identity?
- What is the confused-deputy problem in a software factory?
- Why should excessive GitHub permission fail readiness?
- How do signed service commands prevent replay?
- What belongs in an execution attestation?
- How do you contain prompt injection from repository content?
- What current Mission Control security claim would you refuse to make?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence