Development plan for the security portfolio¶

Updated on 2026-10-06 against the local checkouts. The shared Kubernetes lab connects three projects and passed eighteen scenarios both after a fresh rebuild and with the main passwordless profile enabled. Native human sign-in passed eleven real synthetic WebAuthn/OIDC checks, responsive interface checks and the complete scoped lifecycle after operator-approved VM recovery. Real Google integration remains a separate operator gate. This plan distinguishes recorded proof and subsequent delegation work. Earlier standards and market research below was checked on 2026-10-04; it is dated evidence, not a continuously refreshed trend report.

Keep mcp-svid-auth as the lab coordinator, mcp-spiffe-bridge as a TypeScript transport library, and hipaa-fhir-mcp as its synthetic domain consumer. Keep the repositories independently buildable. ecs-contract remains a separate AWS configuration ownership tool and is excluded from the Kubernetes lab. The common theme is making identity, authority, data boundaries and configuration ownership explicit and testable.

Project roles and priorities¶

How the implemented lab fits together¶

flowchart LR
    SPIRE[SPIRE workload identities] --> Agent[Research workload]
    Agent -->|JWT-SVID assertion| Auth[mcp-svid-auth]
    Auth -->|300-second token for FHIR only| Agent
    Agent -->|mTLS and scoped access token| Bridge[mcp-spiffe-bridge inside FHIR gateway]
    Bridge -->|Verified caller context| Tools[hipaa-fhir-mcp tools]
    Tools --> Fixture[Offline synthetic FHIR data]
    Human[Approved operator] -->|Verified passkey; Google connection pending| Identity[ZITADEL sign-in]
    Identity -->|Validated identity; opaque local session| UI
    UI[Read-only Headlamp] -.->|Service state, policy and safe verdicts| Bridge

The bridge verifies the TLS peer. The FHIR gateway separately verifies the access token, whose subject must match that peer's SPIFFE ID. The tools receive the trusted request context. Kubernetes coordinates process startup and discovery; it does not decide clinical access. The base has nine service pods; the optional identity profile adds three. The bridge is a library inside the FHIR gateway.

The local operator can use the base viewer or enable the human sign-in profile with make ui-login. There is no implemented user delegation or authorization of individual clinical records. The current gateway uses an offline fixture; the standalone HTTP FHIR client is a separate boundary with remaining validation work.

Optional evidence-oriented demonstration¶

The separate IT GRC project (it-grc, not yet public; formerly ciso-assistance) pushes executed lab evidence into the unmodified CISO Assistant Community edition (CE), used as the GRC system of record. CE runs on k3s in its own Lima VM, it-grc, not in the shared security-lab VM. Its input is the credential-free demo report that make demo writes, or a retained copy. The bridge maps the eighteen scenarios to the public NIST SP 800-66 rev2 framework, sets at most partially_compliant with status in_review, and leaves compliant, done and evidence approval to a human reviewer in CE.

This is a downstream consumer of the lab's saved evidence, not a new authentication authority. It has no lab Kubernetes API credential, no automatic remediation and no FHIR access. Its CE sign-in is separate from the Headlamp sign-in gate; shared single sign-on would need its own approved client, callback and application role. A saved report is dated evidence, not a live check of the lab. Any later live access to the lab must use a separately attested SPIRE workload and its own narrowly scoped token. The Headlamp session and a Google ID token must never serve as that credential. The two VMs have separate lifecycles.

Human identity demo: optional OIDC provider¶

The selected ZITADEL profile is the requested exception to the CNCF-only selection. It uses a real OIDC gate and runs ZITADEL, Login V2 and PostgreSQL on demand inside the existing Lima VM. The tools remain separate from workload identity. See operation and boundaries.

The first increment is passwordless human sign-in for the local read-only panel:

1. A synthetic operator proves possession of a passkey with required user verification, then completes Authorization Code with PKCE. Real Google identity linking remains pending operator configuration.
2. A server-side session gate verifies the issuer, client, callback, state, nonce and token lifetime, and checks a local viewer role, an approved stable subject and fresh signed authentication evidence.
3. The gate discards OIDC tokens after validation. The browser gets an opaque five-minute session cookie. The existing namespace-scoped viewer credential still serves Kubernetes reads.
4. An authenticated user without the viewer role is denied. A successful human login grants no additional MCP tool or data permissions.

Keep the existing machine-to-machine exchange unchanged in that increment. Do not replace the accepted JWT-SVID assertion with a generic OIDC JWT or assume that a provider's private-key JWT profile accepts SPIRE credentials. Do not forward a user's OIDC token to the MCP server, Kubernetes API or FHIR backend.

Human-directed tool access is a subsequent, separately specified token contract. A verified user grant and the acting workload's SPIRE identity must both be checked before a new, short-lived, single-resource credential is issued. Permissions must be the intersection of the user's permitted operations, the workload policy and the requested record context. Current tokens identify the workload and require sub to match mTLS; adding a human subject must not silently weaken that check. SMART authorization for a clinical FHIR backend remains a separate integration.

Acceptance gates for the additional profile¶

The OIDC gate and optional provider resources passed the local synthetic passwordless acceptance and full lifecycle. Real Google linking and physical passkey enrollment remain operator gates. User delegation and individual record authorization remain subsequent work. Human roles in this synthetic demo are not evidence of HIPAA compliance or clinical consent.

This prioritization is a judgment about the inspected implementation and maintenance cost. No user interviews, adoption figures, revenue estimates, or market size were measured.

Public developments checked on 2026-10-04¶

The strategic interpretation of these sources is a move toward explicit machine authentication, managed integration, and stronger application authorization. That is an inference from standards and product capabilities, not a measured adoption trend.

Findings that should change the backlog¶

Details and acceptance criteria are in each repository's docs/development-plan.md.

Claude demo notes and recommended scope¶

The relevant local Claude conversation, dated 2026-09-26 and 2026-09-27, proposes smallest-board: Go on a 3 by 3 board, a service and a separate infrastructure repository, persistent games, and all three configuration sources. It treats live deployment as an optional extension. Those are planning notes, not evidence that the demo exists. The local ECS source now contains the resolver and infrastructure construct, so the earlier dependency on implementing those stages is satisfied in code. Publication and remote CI status were not checked.

Keep the visual board, but begin with a compact deterministic move sequence. Full game rules, an optimal-play oracle, and a database would substantially increase the work before the ownership lesson is visible. Add them only if they contribute to that lesson.

The first demo should show:

1. An application deployment changes a harmless setting such as board theme.
2. A deliberately conflicting infrastructure example resets it, making the problem visible.
3. The contract version preserves it during an unrelated infrastructure change.
4. A stale infrastructure plan is detected or explicitly stopped by the shared deployment procedure.
5. A bad declaration fails offline before deployment. Later, synthetic pointer and vault sources demonstrate resolution without displaying values.

For the security demo, keep the first presentation to identity issuance, an allowed read, a denied write, a token rejected by another resource, and the limit of identity under an excessive grant. Present the longer threat scenarios as an appendix. Script scenario 10 as a deterministic tool request where useful; an LLM is not required to prove that identity checks cannot determine user intent.

For FHIR, use fixed synthetic responses for the repeatable demonstration and make the public sandbox optional. For the bridge, the minimum demonstration must contain MCP initialization, tool discovery, and one call under mTLS, including a denied identity and rotation.

Development sequence from the current baseline¶

Work through one accepted increment at a time. The order below is a development sequence, not a release-date promise.

Evidence and validation limits¶

• mcp-svid-auth: the 2026-10-06 baseline passed 278 tests, lint, formatting, strict types, generated configuration and documentation builds. All eighteen real Lima/Kubernetes/containerd scenarios and teardown passed. The viewer was restarted with nine ready services and five browser-verified views. See lab evidence and UI evidence.
• The final root offline gate passed 467 tests, lint, formatting, strict types, generated configuration, strict documentation build, and source/history secret scans on 2026-10-06, including three setup-lifecycle regressions. The main profile passed eleven real WebAuthn/OIDC checks, four closed Google setup checks with fake inputs, five protected desktop views and browser logout. Two setup repetitions preserved the viewer. Real Google sign-in and physical-device completion remain unverified.
• A failed-start check first proved refusal of the legacy profile without changing pod identities. The operator then approved its ephemeral database deletion; the native replacement passed. Hosted Login V2 reached the required passkey screen without a password form. Sixty-four five-second samples across the final recovery cycle including native startup observed a maximum of 1858.1 MiB in the 4 GiB guest, excluding host overhead and the local model.
• A fresh main-checkout rebuild passed eighteen scenarios at 14:55 UTC; an enabled-profile repeat passed eighteen at 15:02 UTC with fresh relay credential and FHIR audit state. A later cycle failed after macOS disk exhaustion and guest I/O errors. After the operator-approved VM restart, the complete fresh cycle from 15:25 to 15:31 UTC passed eighteen scenarios, native startup, viewer stop/idempotence, identity-backend-loss recovery, eleven identity checks, four closed Google setup checks, five desktop views, the 390 x 844 mobile layout and final scoped teardown. CISO's namespace UID and the shared VM were preserved at every phase. Its successor, IT GRC, now runs in its own VM.
• hipaa-fhir-mcp: the shared integration has actual allowed and denied mTLS/OAuth requests, a verified caller and safe audit. Its local gate was freshly rerun on 2026-10-06: ten tests, typecheck, build, Biome and the PHI sweep passed. The standalone HTTP response validation and stdio schema rejection gaps remain.
• mcp-spiffe-bridge: the local gate was freshly rerun on 2026-10-06: 56 tests, typecheck, lint and build passed, including real local TLS sockets and credential failure cases. Lint reports nine pre-existing warnings. The eighteen-scenario lab was also freshly rerun that day. Automatic reconnect remains unimplemented.
• ecs-contract: the last recorded gate is 2026-10-04: 131 tests, lint, formatting and strict types. No new ECS tests or AWS calls were run for this update. Claude's board proposal remains a separate demo plan.
• it-grc (formerly ciso-assistance): its 2026-10-13 record pushed that day's eighteen-scenario lab report into CE v4.1.1 in the it-grc VM. The audit held 20 partially_compliant and 132 not_assessed of 152 assessable requirements, nine evidence objects in review and none approved; verify found no drift. This is that project's recorded result, not a check rerun by the root coordinator, and not HIPAA compliance. Results of the retired version 0.1.1 prototype are historical.

No live AWS changes, real clinical records, publication, remote CI runs, or GitHub writes were performed. Raw private planning notes and private identifiers are not included in these documents.