Threat Model, Tests, and Rollout

Enterprise problem: A plausible authorization architecture can still ship creator privilege, cross-team credential leaks, confused-deputy calls, prompt-driven tool escalation, stale grants, or public-agent access because happy-path demos do not exercise hostile boundary crossings.

Whole-course context: The incoming evidence is an immutable deployment, two-key runtime path, independently revocable app/provider grants, and complete redacted decision lineage; today converts those artifacts into executable release gates.

Today’s slice: We build a threat model and negative-test matrix across provider control plane, hosted runtime, generated application, connectors, agent delegation, and downstream authorities, then stage canary, production, rollback, and retirement.

End-of-day evidence: A signed release dossier maps each named attack to a control and observed test, proves positive controls, records exact artifact and policy digests, and includes canary promotion or rollback plus residual-risk acceptance.

Still unsolved: Organization-specific legal approvals, production credentials, capacity targets, incident staffing, and irreversible final deletion require accountable owner gates outside this course.

A release checklist can pass while a real attacker crosses an untested plane, so each customer job must connect named threats to executable positive and negative evidence. The final rollout is allowed only for the exact build that produced that evidence.

Use case ID	Actor	Customer job	Success outcome	Denial or recovery evidence
D12-UC-01	Enterprise security engineer	Attack the authorization boundaries before customers do	Every threat has an owning control, test fixture, expected denial, observed result, immutable trace, and adjacent positive control across app, provider, runtime, connector, agent, and downstream planes	Any privilege union, wrong audience, schema drift, argument substitution, stale membership, unauthorized data row, or public connector call fails the release gate with a reproducible counterexample
D12-UC-02	Accountable release owner	Roll the exact verified build from isolated test through canary to production and recover or retire safely	Promotion pins artifact, policy, schema, infrastructure, and test-evidence digests; production probes match canary; rollback and retirement preserve customer data and audit obligations	A failed canary blocks promotion, rollback restores the last verified release, and retirement denies new use before export/retention/deletion jobs proceed under separate approval

The threat model assumes prompts, retrieved documents, websites, tool output, model reasoning, generated code, caller-supplied IDs, and agent-authored role claims are hostile. Trusted inputs are authenticated identity, current membership, immutable deployment metadata, reviewed policy bundles and tool schemas, workload identity, app-owned session and role state, connector registry, and downstream resource policy—but every trusted component can fail unavailable or stale and needs tests for that failure.

Security requirements that say only “prevent escalation” cannot be falsified, so stories name the attack, expected terminal signal, and evidence linkage. Release authority is separate from security test execution to prevent one actor from silently accepting their own failed control.

Story ID	Use case IDs	User story	Observable acceptance conditions
D12-US-01	D12-UC-01	As a security engineer, I want hostile identity, sharing, tool, delegation, knowledge, runtime, and app-data probes executed against the release candidate, so that no single-plane allow or model instruction can expand effective authority	Every matrix row has actor, resource, scope, precondition, expected and observed result, environment, timestamp, source fixture, trace/decision ID, control owner, and positive control; all mandatory denies occur at the intended enforcement point; an unexpected allow blocks release
D12-US-02	D12-UC-02	As a release owner, I want canary promotion, rollback, and retirement tied to the exact verified digests, so that production cannot drift from the reviewed candidate and recovery does not corrupt application data	Four-eyes approval selects a signed dossier; canary runs user, workload, network, tool, app-row, and audit probes; production reports identical digests; rollback is rehearsed; retirement disables entry points before exports and approved deletion; every transition is immutable

The bounded platform envelope is tested with contrasting archetypes: a private collaborative Workboard proves tenant rows and roles; an organization-scoped revenue dashboard proves delegated connector reads and downstream row policy; and a public intake application proves anonymous create can be allowed while anonymous read, enumeration, export, administration, and enterprise connectors remain denied. A falsifier in any archetype rejects the shared invariant instead of being dismissed as an app-specific exception.

Passing unit tests does not prove the deployed candidate enforces the same policy, so the flow begins with a visible “Evaluate release” action and carries immutable identity into canary and production. The test harness never receives broad production credentials; it invokes normal product surfaces as bounded test principals and workloads.

Flow ID	Use case IDs	Path	Trigger	Numbered steps	Terminal evidence
D12-FLOW-01	D12-UC-01	Happy	Security engineer starts “Run mandatory authorization suite” for a release candidate	1. Test orchestrator resolves candidate artifact, policy, tool-schema, infrastructure, and fixture digests.<br>2. It provisions isolated organizations, teams, app tenants, users, groups, connectors, documents, workloads, deployments, and agents with least privilege.<br>3. It executes positive controls and mandatory denied cases for identity, sharing, app rows, knowledge trimming, tools, arguments, protocol tokens, delegation, runtime, prompt injection, and revocation.<br>4. Every request goes through production-equivalent policy enforcement and redacted audit.<br>5. Coverage service confirms every threat maps to at least one control and observed test, and every use-case invariant is exercised by multiple archetypes.<br>6. Signer seals the dossier only if no unexpected allow, missing evidence, or secret leak exists.	For each probe: actor, exact resource, scope, precondition, expected result, observed result and enforcement point, isolated environment, timestamp, artifact/policy/schema digests, immutable source fixture, trace and decision IDs; dossier adds coverage manifest and signature
D12-FLOW-02	D12-UC-01	Denied	A retrieved document instructs the revenue-dashboard agent to use an administrator export tool and substitute an executive account	1. Model may emit the malicious intent, but cannot provide trusted team, connector, role, or approval state.<br>2. Tool gateway loads original subject/team, immutable deployment manifest, reviewed schema, connector binding, and structured arguments.<br>3. Manifest and deployment exclude admin.export; argument policy also rejects the account.<br>4. No capability token, secret resolution, or downstream request occurs.<br>5. An approved dashboard read succeeds as a positive control.<br>6. Prompt-injection denial metric and complete trace are asserted.	Actor and agent actor, forbidden tool/account resources, requested scopes, hostile-document precondition, expected gateway denial, observed no broker/downstream call and allowed read control, environment, timestamp, policy digest, fixture hash, decision ID, and trace ID
D12-FLOW-03	D12-UC-02	Happy	Release owner approves signed dossier for canary and then production	1. Promotion service verifies separation-of-duty approvals and all dossier signatures.<br>2. Canary controller deploys the exact artifact with pinned policy, schema, network, and workload revisions.<br>3. Synthetic principals exercise each boundary plus audit completeness and revocation freshness.<br>4. Owner reviews customer-visible health, denial, latency, and drift evidence.<br>5. Production promotion changes only the immutable release pointer.<br>6. Post-promotion probes compare served digest and alias against the approved candidate.<br>7. Release record closes with owner, timestamps, results, and residual-risk acceptance.	Actor, release resource and production scope, signed-dossier precondition, expected exact-digest promotion, observed canary/production probes, environment, timestamps, source commit, artifact/policy/schema/infrastructure digests, deployment ID, and immutable release transition ID
D12-FLOW-04	D12-UC-02	Recovery	Canary shows an authorization-staleness breach or production must retire the application	1. Controller blocks further promotion and selects the last verified immutable release for rollback, or disables all new entry surfaces for retirement.<br>2. Runtime cancels incompatible runs and reconciles prior workload/network state.<br>3. Generated-app database remains at its compatible schema and is not restored from a code rollback.<br>4. Recovery probes verify intended access and all mandatory denies.<br>5. For retirement, customer export and retention jobs run under separate approvals before cryptographic erasure or deletion.<br>6. Provider source, runtime artifacts/secrets, app data, connector grants, and audit records follow their owning deletion schedules.<br>7. Residual retained/irrecoverable data is documented.	Actor, failed or retired release resource, rollback/retire scope, failing-probe precondition, expected containment, observed prior digest or denied entry points, data-integrity result, environment, timestamps, incident/retirement ID, deletion-job IDs, and immutable evidence bundle

Mandatory adversarial matrix

An untested attack is an undocumented acceptance decision, so the release gate includes at least these categories:

Category	Mandatory probes	Intended control
Identity and agent access	Outside organization; disabled user; former member; view-only user tries run; deployment absent from active team; unapproved version	Current identity/membership plus explicit team deployment and action grant
Sharing and generated app	Source team token copied to target team; builder probes app rows; app user probes source; wrong tenant; public route reads/exports/administers; public deployment requests private graph or connector	Separate package/bindings, project/preview/app authorities, tenant predicates, route policy, public-safe capability class
MCP and connectors	Wrong/expired audience; provider token passthrough; disabled/unmanifested tool; changed schema; unavailable connector	Resource-specific token, strict audience, no passthrough, filtered discovery, schema hash/quarantine, explicit connector binding
Arguments and downstream data	Allowed Slack tool targets forbidden channel; read grant used for write; SQL escapes schema; Drive escapes folder; CRM targets unapproved account	Exact operation and argument policy plus downstream resource authorization
Agent delegation	Caller invokes inaccessible callee; callee exceeds user; cycle; depth/fan-out/budget exceeded; parent cancelled	Original subject/actor preservation, authority intersection, audience binding, cycle and budget limits, cancellation propagation
Runtime and prompt injection	Stolen run token from wrong workload; trusted workload without token; arbitrary egress; document requests admin export; model invents approval	Two-key workload/user rule, strict mTLS, default-deny egress, independent gateway policy, immutable trusted context
Revocation	User, connector, deployment, approval, app grant, or arguments change during run	Versions/events, immediate high-risk recheck, fresh token, argument digest, session/stream/job convergence

The named threat cases include creator privilege inheritance, cross-team credential leakage, confused deputy, MCP token passthrough, prompt-injected tool use, shared service-account overreach, tool-definition drift, argument substitution after approval, membership revocation delay, and public-agent escalation. Each control is designed so compromise of one plane still meets a veto in another.

Tests become ceremonial when fixtures bypass real gateways or evidence can be altered by the release owner, so the verification system uses production-equivalent entry points and independently signed stores. Control owners fix failures; the release orchestrator only evaluates declared evidence.

Use case ID	Entry point	Responsible services	Authoritative store	Failure evidence
D12-UC-01	Security evaluation console and versioned test manifest	Threat registry; fixture provisioner; product-surface probe runner; policy, protocol, delegation, app-row, knowledge, runtime, and revocation test adapters; audit validator; coverage checker; evidence signer	Versioned threat/control/test manifest owned by security engineering; immutable probe event store owned by evidence service; source fixtures owned by test repository	Unexpected allow, expected allow denied, wrong enforcement point, missing positive control, uncovered threat, missing field/trace, secret canary, digest mismatch, or unreproducible fixture
D12-UC-02	Release approval, canary, rollback, and retirement consoles	Separation-of-duty approval service; release orchestrator; artifact verifier; canary controller; runtime reconciler; synthetic monitor; rollback controller; export/retention/deletion workflows	Signed dossier and release transitions owned by provider control plane; observed deployment state owned by hosted runtime; domain data and schema state owned by generated app; audit retention owned by security operations	Invalid signature, stale approval, canary or post-promotion probe failure, served-digest drift, rollback reconciliation failure, data corruption, deletion-before-export attempt, or incomplete retirement evidence

The implementation sequence reduces dangerous dependency inversions: establish enterprise identity, team membership, active-team selection, and revocation; separate creator from durable agent owner and make versions immutable; declare capabilities without credentials and bind them per team deployment; route exact tool intents through a gateway with argument constraints and approval; harden MCP discovery, audience, schema review, and token exchange; secure agent-to-agent delegation with authority intersection and limits; then add complete operations, outage exercises, and cross-team attack tests. Later phases never weaken earlier boundaries.

Production readiness is a proof set, not a checkbox count: identity covers enterprise federation, multifactor authentication for privileged users, issuer/audience validation, short tokens, and current membership; sharing keeps packages separate from credentials and app access; connectors distinguish user and service authority, minimize OAuth scopes, and vault tokens; runtime has no broad credentials and enforces mTLS plus workload allowlists; audit retains actor chain, policy version, credential mode, approval, redaction, and SIEM export.

Release safety collapses if test results can point at mutable tags or if retirement treats provider source, runtime secrets, and app records as one deletion object. The model pins every proof to immutable digests and lets each plane execute its own reviewed lifecycle.

Generated-application database: Not created in this slice — the release system exercises existing app tenant, role, route, row, and lifecycle behavior through isolated fixtures, while durable threat, evidence, release, rollback, and retirement state belongs to provider and hosted-runtime stores rather than a new production app database.

Record or entity	Store and owner	Primary key	Foreign key or opaque reference	Tenant key	Material constraint	Lifecycle and deletion	Use case IDs
ThreatCase	Security manifest repository; security engineering	threat_case_id plus manifest digest	Local control/test IDs; opaque plane owner reference	None — threat definitions apply across tenants while fixtures are tenant-scoped	Named attack, protected asset, trust boundary, precondition, control owner, expected outcome, and residual risk required; immutable per digest	Review and version; supersede without erasing old definitions; retain with every referencing release	D12-UC-01
TestCase	Versioned test repository; security quality owner	test_case_id plus fixture digest	Local threat_case_id; opaque product route and policy references	organization_fixture_id	Must use normal enforcement path and declare positive control, expected enforcement point, evidence schema, and deterministic setup	Execute per candidate; quarantine flaky cases rather than ignore; retain source with release evidence	D12-UC-01
ProbeObservation	Immutable evidence store; evidence service	probe_observation_id	Local test ID; opaque actor, resource, decision, trace, artifact, and policy references	organization_fixture_id plus optional app_tenant_fixture_id	Actor/resource/scope/precondition/expected/observed/environment/time/immutable ID mandatory; append-only and redacted	Append during test/canary/production; sign batch; retain by release/audit policy; delete sensitive fixture payload separately	D12-UC-01, D12-UC-02
ReleaseDossier	Provider release store; release governance	dossier_digest	Local observation manifest; opaque artifact, policy, schema, infrastructure, source commit, and approval references	organization_id plus target team/environment	All required tests covered, no unexpected allow, exact digests signed, separation-of-duty approvals current	Create after evaluation; invalidate on any referenced digest change; retain permanently or by regulated release policy	D12-UC-01, D12-UC-02
ReleaseTransition	Provider deployment store; release orchestrator	release_transition_id	Local prior/next dossier and artifact references; opaque runtime revision	organization_id plus team and environment	State machine allows candidate → canary → production, block, or rollback; served digest must equal approved digest	Append every transition; never overwrite; retain through artifact and audit retention	D12-UC-02
RuntimeAttestation	Hosted-runtime state store; runtime reconciler	runtime_attestation_id	Opaque release transition; local workload, network, secret-reference, and policy revisions	organization_id plus deployment ID	Observed artifact/policy/schema/infrastructure digests and workload identity must equal desired state	Issue after reconciliation and periodically; revoke on drift; retain with release evidence; purge operational detail later	D12-UC-01, D12-UC-02
RetirementPlan	Provider lifecycle store; retirement orchestrator	retirement_plan_id	Opaque provider project, runtime deployment, generated app, connector, export, audit-retention, and deletion-job references	organization_id	Disable entry points before data action; explicit owner/approval/deadline per plane; legal hold blocks deletion; deletion cannot precede required export	Draft, approve, disable, export, retain, delete or cryptographically erase, verify; preserve signed tombstone and residual statement	D12-UC-02
ResidualRiskAcceptance	Governance store; accountable owner	risk_acceptance_id	Local dossier or retirement plan; opaque threat and evidence references	organization_id	Named owner, bounded scope, rationale, compensating control, expiry, and review date; cannot waive an unexpected cross-tenant allow	Approve separately; expire automatically; renew with fresh evidence; retain decision under governance policy	D12-UC-01, D12-UC-02

The final invariant remains an intersection: enterprise user is authenticated and mapped to current organization/team; user and team may run one immutable deployment; deployment declares approved capabilities; model proposes but does not grant; gateway authorizes exact tool and arguments; broker resolves the correct user or service credential; protocol server validates its own audience; downstream system enforces resource permission; generated app enforces its tenant, route, role, and row predicates; and audit records the full chain. Creator authority is never inherited, sharing logic never shares credentials, and every privileged action is authorized again at execution time.

Static architecture sketches can look like empirical models when their source and adaptation limits are hidden, causing readers to infer precision or dynamics that the article never supplied. The primary source here is an unpaginated text attachment, so printed-page and PDF-page fields are unavailable; the canonical inventory uses exact source-line anchors and records every substantive diagram detected by the course parser’s visual-art rule.

All 17 source visuals are conceptual reconstructions, not transcriptions, calibrated simulations, or interactive labs. They preserve topology, ordering, trust boundaries, and allow/deny arguments as Mermaid diagrams in the mapped lessons. They are explicitly excluded from the interactive-lab registry because the source provides no data series, algorithm, or parameter semantics: inventing three controls would invent unsupported behaviour rather than reveal the source. This exclusion would be falsified if a source dataset, algorithm, or parameterized state model were supplied; that evidence would require atomic labs, controls, readouts, protocols, and responsive browser proof.

Manifest ID	Source trace	Original argument	Mapped course reconstruction
agent-auth-source-visual-01	Line 87, platform/team tree	Organization teams remain separate authority scopes	Day 04 identity and effective-authority architecture
agent-auth-source-visual-02	Line 545, active-team tree	Multi-team membership must not become a permission union	Day 05 login and active-team flow
agent-auth-source-visual-03	Line 778, agent versions	Review and deployment bind immutable behaviour	Day 01 agent/version entity model
agent-auth-source-visual-04	Line 973, deployment tree	Shared logic receives independent team bindings	Day 01 deployment architecture
agent-auth-source-visual-05	Line 1261, unsafe runtime	Ambient team credentials create standing authority	Day 06 run-admission threat model
agent-auth-source-visual-06	Line 1273, bounded runtime	Runtime receives only narrowed run inputs	Day 06 two-key and capability flow
agent-auth-source-visual-07	Line 1393, user OAuth	A personal call resolves only that user’s grant	Day 08 delegated-access flow
agent-auth-source-visual-08	Line 1422, managed OAuth	Scheduled work uses a durable team service principal	Day 08 managed-access flow
agent-auth-source-visual-09	Line 1822, MCP architecture	Discovery, arguments, credentials, and source ACLs are separate gates	Day 07 MCP gateway architecture
agent-auth-source-visual-10	Line 2185, IdP groups	Enterprise groups explicitly narrow connector discovery	Day 08 enterprise-managed discovery model
agent-auth-source-visual-11	Line 2433, approval flow	Approval binds one immutable intent and one use	Day 09 approval/delegation flow
agent-auth-source-visual-12	Line 2730, security trimming	Unauthorized chunks are removed before model context	Day 02 knowledge-authorization flow
agent-auth-source-visual-13	Line 3031, revocation stream	Grant changes invalidate caches and active work within bounds	Day 11 revocation convergence flow
agent-auth-source-visual-14	Line 3067, repository tree	Policy, infrastructure, environments, and tests stay separately owned	Day 10 trust-boundary architecture
agent-auth-source-visual-15	Line 3359, delivery pipeline	Validation and canary evidence bind the promoted digest	Day 10 release flow
agent-auth-source-visual-16	Line 3529, event lineage	Session-to-provider identifiers form one causal chain	Day 11 audit architecture
agent-auth-source-visual-17	Line 3997, final architecture	Every plane and downstream system enforces an independent gate	Day 12 production architecture