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 focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
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.
4. Tradeoffs and alternatives
Fine-grained authorization improves containment but increases configuration and operator friction. Capability-based service commands reduce ambiguity but require more integration work than a generic service token. Short-lived tokens reduce exposure but increase dependence on token-minting availability.
Sandboxing can limit filesystem and network effects, but no sandbox justifies broad credentials. Separate containers or hosts provide stronger isolation than process restrictions at greater cost. The correct level follows risk and threat model, not fashion.
5. Current Mission Control Implementation
At commit
b31e27564deb1c03c167e61b5ee094567c2ba7b1,
Mission Control deliberately separates human, service, and GitHub identities.
Human authentication uses Clerk tokens, while Convex tenant/operator/role records remain the source of company authorization. Exact Clerk subject IDs, not email addresses, bind humans to operators. Company and workspace operations use server-side permission checks and protect the last active owner.
The production Clerk issuer is still a non-routable placeholder at the studied commit. Clerk rollout therefore has documented controls but is not configured production evidence.
The orchestration server authenticates inbound HTTP with a bearer token and signs outbound Convex commands with a separate HMAC secret. Signed envelopes bind service identity, named capability, workspace, repository, command ID, short expiry, and payload digest. Convex retains accepted, denied, failed, and replayed command receipts. Current named service capabilities are WorkOrder dispatch and receipt ingestion; broad task, artifact, handoff, and other service operations remain incomplete.
GitHub uses an App installation rather than personal access tokens. Readiness requires exact least privilege: metadata read, contents write, pull requests write, checks read, and a defined webhook set. Missing, excessive, stale, or revoked authority blocks readiness. Webhook signatures are checked against the raw body, delivery GUIDs deduplicate effects, and installation tokens are ephemeral and not retained.
The security matrix is candid that company administration and some factory paths are enforced while Mission, Task, approval, remaining evidence, orchestration, and release authorization still need the complete golden-path security slice. The missing GitHub App configuration was a real blocker in the retained lab.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence