Threat Model, Tests, and Rollout
Source: How Enterprise Authentication and Authorization Work in an Agent Platform, sections 34 and 36–39; turns the final architecture and implementation order into release evidence.
The enterprise problem and today’s slice
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.
Thesis: Production authorization is a falsification problem, not a checklist problem: release only the immutable build whose independent boundaries survived named attacks through normal product paths and can be rolled back or retired with equally strong evidence.
Smallest complete mental model: name the attack, observe the control under the exact candidate, and make the release decision from signed evidence.
Boundary: This day proves the shared platform envelope across provider, hosted runtime, generated application, connectors, delegated agents, and downstream systems. It does not waive customer-specific legal, staffing, credential, capacity, or irreversible deletion approvals.
Customer outcome and implementation focus
The customer outcome is a reliable, reviewable implementation of 12 threat model tests and rollout. This day introduces the mechanism before policy detail and evidence review; it does not repeat the same customer stories in prose, tables, and diagrams.
Components in focus
Authorization policy service owns decisions; the connector/runtime gateway owns enforcement. Compute: API and isolated worker processes. Storage: PostgreSQL is authoritative for grants and state; Redis is a versioned cache; vault owns secrets; object storage retains redacted evidence only.
Implement the mechanism
Implement the day’s boundary with a current, explicit decision before privileged compute or a downstream call. Bind every effect to a tenant, subject or workload, deployment, resource, and short-lived evidence ID; a cache or model response never grants authority.
Failure modes, trade-offs, and decision rules
Release programs fail when coverage is broad but shallow, or when a flaky test is ignored until an attacker supplies the same timing. The consequence is security theatre: many green checks with no reliable claim about the candidate actually serving customers.
| Pressure | Tempting shortcut | Resulting failure | Safer trade-off | Decision rule |
|---|---|---|---|---|
| Increase coverage count | Add checklist rows without executable fixtures | Named threats have no falsifiable observation | Prefer fewer boundary-complete probes, then expand from uncovered attack surfaces | Count a threat as covered only when control, negative observation, positive control, owner, and evidence ID are all present |
| Stabilize continuous integration (CI) | Retry or ignore flaky authorization tests | Timing-sensitive stale grants and race conditions disappear from the gate | Quarantine the release and fix fixture determinism or product race; never convert an unexpected allow into tolerated flakiness | An unexpected allow is always blocking; an unstable test is missing evidence, not a pass |
| Test safely | Give the harness broad credentials or call internal policy functions | Tests bypass the normal boundaries they claim to prove | Use bounded fixture principals and public product surfaces in isolated tenants | The harness must have no authority that the tested actor would not possess |
| Promote quickly | Reuse evidence after policy, schema, network, or artifact change | Dossier describes a different system | Invalidate and rerun only the affected dependency-closed suite, then reseal the full digest manifest | Evidence is reusable only while every referenced immutable input remains identical |
| Recover quickly | Roll back code and customer database together | Newer generated-app data is lost or corrupted | Roll back executable pointers; handle schema/data with a compatibility plan and independent owner | Recovery actions respect plane ownership even under incident pressure |
| Retire completely | Delete source, runtime, app data, connectors, and audit as one job | Required export or legal retention is lost, or an entry point remains active | Disable entry points first; execute per-plane export, retain, erase/delete, and signed tombstone workflows | No deletion begins until authority is denied and the owning plane's prerequisites are observed |
Security and availability are not opposites, but degraded modes must be explicit. A low-risk read may have a bounded outage policy; a cross-tenant or high-impact write may not fail open merely to protect uptime. Residual-risk acceptance can bound a known limitation with owner and expiry, but it cannot waive an unexpected cross-tenant allow.
Implementation and verification
A threat matrix is useful only when it drives a reproducible candidate evaluation and a real rollout state machine. Start with the HelixWorks Supplier Onboarding Agent plus contrasting Workboard, revenue-dashboard, and public-intake fixtures so the shared invariants are tested outside one application shape.
- Version the threat-control-test manifest and give every threat a protected asset, precondition, control owner, expected enforcement point, positive control, residual, and fixture digest.
- Provision isolated organizations, teams, app tenants, users, connectors, documents, workloads, agents, and downstream rows with the least authority required by each case.
- Execute mandatory identity, sharing, row, knowledge, connector, MCP, argument, approval, delegation, workload, prompt-injection, and revocation probes through normal product surfaces.
- Seal redacted observations only when every probe contains actor, resource, scope, precondition, expected result, observed result, environment, timestamp, source fixture, trace/decision ID, and exact digest tuple.
- Require independent release approval, deploy that tuple to canary, rerun boundary and audit probes, compare observed revisions, and promote only by immutable pointer.
- Rehearse rollback without restoring app data; then rehearse retirement by disabling entry points before export, retention, connector revocation, secret/artifact cleanup, app-data deletion, and signed residual evidence.
Falsifiable evidence: the release claim fails if any unexpected allow occurs, a positive control fails without explanation, a probe bypasses normal enforcement, a threat lacks an owner or evidence join, a secret canary appears, served digests differ from the dossier, rollback corrupts app data, or retirement deletes before required export/retention.
Source-visual inventory and fidelity
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 | Days 01 and 05 identity/lifecycle boundaries |
agent-auth-source-visual-02 | Line 545, active-team tree | Multi-team membership must not become a permission union | Days 04-05 federation and lifecycle flows |
agent-auth-source-visual-03 | Line 778, agent versions | Review and deployment bind immutable behaviour | Day 07 agent/version entity model |
agent-auth-source-visual-04 | Line 973, deployment tree | Shared logic receives independent team bindings | Day 07 deployment architecture |
agent-auth-source-visual-05 | Line 1261, unsafe runtime | Ambient team credentials create standing authority | Day 10 run-admission threat model |
agent-auth-source-visual-06 | Line 1273, bounded runtime | Runtime receives only narrowed run inputs | Day 10 two-key and capability flow |
agent-auth-source-visual-07 | Line 1393, user OAuth | A personal call resolves only that user’s grant | Day 12 delegated-access flow |
agent-auth-source-visual-08 | Line 1422, managed OAuth | Scheduled work uses a durable team service principal | Day 12 managed-access flow |
agent-auth-source-visual-09 | Line 1822, MCP architecture | Discovery, arguments, credentials, and source ACLs are separate gates | Day 11 MCP gateway architecture |
agent-auth-source-visual-10 | Line 2185, identity-provider groups | Enterprise groups explicitly narrow connector discovery | Day 12 enterprise-managed discovery model |
agent-auth-source-visual-11 | Line 2433, approval flow | Approval binds one immutable intent and one use | Day 13 approval/delegation flow |
agent-auth-source-visual-12 | Line 2730, security trimming | Unauthorized chunks are removed before model context | Day 08 knowledge-authorization flow |
agent-auth-source-visual-13 | Line 3031, revocation stream | Grant changes invalidate caches and active work within bounds | Day 15 revocation convergence flow |
agent-auth-source-visual-14 | Line 3067, repository tree | Policy, infrastructure, environments, and tests stay separately owned | Day 14 trust-boundary architecture |
agent-auth-source-visual-15 | Line 3359, delivery pipeline | Validation and canary evidence bind the promoted digest | Day 14 release flow |
agent-auth-source-visual-16 | Line 3529, event lineage | Session-to-provider identifiers form one causal chain | Day 15 audit architecture |
agent-auth-source-visual-17 | Line 3997, final architecture | Every plane and downstream system enforces an independent gate | Day 16 production architecture |
Practical next action and falsifiable evidence
A complete course still produces no assurance until one real candidate is attacked, so freeze the HelixWorks Supplier Onboarding Agent artifact/policy/schema/infrastructure tuple and run the mandatory suite in an isolated production-equivalent environment. Review the first counterexample rather than the aggregate pass rate: verify its actor, boundary, intended enforcement point, downstream non-call or call, positive control, and immutable lineage.
Promote only if the signed dossier covers all named threats, all 17 source-visual arguments remain traceable as documented conceptual reconstructions, canary and production serve the approved tuple, and rollback preserves generated-app data. Otherwise block the release, assign the failing control to its owner, and rerun from the changed digest; that observable sequence is the final evidence that the platform treats authorization as a living system rather than a static diagram.
This evidence is falsifiable: any unexpected allow, missing positive control, untraceable source argument, digest drift, or destructive rollback rejects the release claim.
HelixWorks repository lab
Run the cross-service adversarial path in tests/smoke-product.ts. Its release probe rejects a canary and verifies reconciliation:
canaries.decision = { approved: false, reason: 'error budget exceeded' };
await assert.rejects(
promote.execute({
tenantId,
releaseId,
environment: 'local',
artifactDigest,
expectedPreviousArtifactDigest: priorDigest,
correlationId,
causationId: completedEvent.eventId,
}),
CanaryRejectedError,
);
assert.deepEqual(deployments.operations.at(-1), {
action: 'rollback',
tenantId,
releaseId,
environment: 'local',
artifactDigest: priorDigest,
});
The intent is “promote only observed-safe bytes.” Node, the release use case, and injected adapters interpret it; release state returns to the previous digest; CPU, memory, and test I/O run the scenario; the PASS dossier and rollback operation are evidence. The use case owns promotion (SRP), ports provide IoC/DI, shared contracts remain DRY, and PubSub feeds evidence without coupling services.
pnpm verify
pnpm smoke:product
The suite also checks one side effect under duplicate delivery, cross-tenant denial, revocation denial, and secret-free evidence. Any unexpected allow, two supplier writes, failed rollback, missing fact, or aws-sm:// in evidence rejects the candidate.