Implementation evidence and activation gates

Source and scope

Inspected on 22 October 2026:

Platform PR #1129 — authentication foundation, open and Draft, head 542b32ef34c3a4fcdbe9165c262247474d8db11b.
PR base 250ce72dff4c79fc35816077a90ed41287bed9fa. The implementation identifies Planning revision 423815fb as its specification input. The original design baseline remains Platform f0125a735ff1dff5687a8438c464863836315bfd.
Source inspection covered the PR's changed files, test definitions, hosted CI logs and review findings. No Platform tests or live OAuth flows were rerun for this assessment. Author-reported runtime observations remain attributed.

The branch's ADR-024 sets status: accepted and links PR #1129. Its decision body matches the local proposed reference; only status and decision-PR metadata differ. ADR-024 is absent from the inspected PR base. The branch therefore contains an adoption candidate, not proof of mainline adoption. No human approval was recorded in the inspected PR reviews.

Claims supported by source and hosted tests

All source links below are pinned to the inspected head. They establish what the branch implements, not that the feature is merged, deployed or accepted. Product's acceptance table records remaining criterion-level results.

Claim	Inspected evidence	Conclusion and limits
Chimp Streamable HTTP, both 2025 revisions	Dependency, endpoint, HTTP tests	Chimp `0.6.0`; initialization negotiates `2025-06-18` or `2025-11-25`, falling back to November for an unknown requested revision. Missing/duplicate/unsupported subsequent version headers are rejected. No `2026-07-28` or streaming support.
Exact tenant/resource and signed Connect identity	Verifier, boundary, signed-token tests	RS256, exact issuer and single resource audience, organization, human subject, client, consent and lifetime checks. Signed HTTPS CIMD identities are accepted without fetching their URL. Live two-tenant verification remains open.
Current organization authority on every protected request	Resolver and boundary	Reads active membership, every assigned role's permissions, organization flags and permission definitions. No access-decision cache. Failed, partial, repeated-cursor or excessive pagination denies access. Real environment propagation remains unmeasured.
Eight-second authority and no expired buffered success	Context, endpoint guard, policy tests and HTTP suite	Deadline is the earlier of external expiry and lookup start plus eight seconds. Guard checks before/after dispatch. A controlled-clock test confirms the handler ran but its expired reply was withheld. It is not a deployed socket-timing measurement or a cancellation mechanism.
Separate browser/MCP credentials and consent attribution	Internal credential, codec and endpoint tests	MCP-only audience and channel/resource binding; typed consent survives round trip. Browser and MCP credentials are rejected across channels. Distinct consents remain distinct. Manual browser regressions remain open.
Only harmless read/write probes	Endpoint, context and HTTP tests	Exactly two server-owned fixed handlers with empty arguments and no business dependencies. Discovery and direct calls enforce tenant activation plus read, and write additionally needs write permission. Hosted fixtures cover all permission combinations. This is not proof of future business-tool authorization.
Shared permissions and deterministic export	Catalog, exporter, navigation changes	Existing definitions move into core; navigation retains aliases and adds no MCP menu. Export sorts compiled definitions by slug. Runtime checks definitions without creating grants or enabling tenants. Live provisioning is a separate action.
Disabled default, local ingress and operating guidance	Default configuration, route generator, setup guide	Resource list defaults to empty; organization flag and user grants are independent gates. Local `/mcp` and metadata routes bypass browser ForwardAuth and use bearer authentication. Production ingress configuration is not established by those local changes.
Privacy and operational attribution	Sentry privacy changes/tests, endpoint and boundary	Finite method/outcome/source tags, safe spans and verified-context request logs are implemented. No raw caller messages reach Chimp. Deployed Sentry/log inspection and complete denial attribution remain activation checks.

Test execution and reported observations

The hosted CI run 39804320777 completed successfully for the inspected head. Its preview-image build log contains executed test results, including:

Suite	Passing tests	Failed / ignored
`WorkosMcpSuite`	7	0 / 0
`WorkosMcpHttpApiSuite`	3	0 / 0
`McpEndpointsSuite`	9	0 / 0
`McpPolicySuite`	4	0 / 0

This independently corroborates 23 focused infra/web tests, including the CIMD follow-up at this head. The hosted log also records passing catalog, navigation and Sentry privacy suites and successful image compilation. Other aggregate suites contain skipped tests; this is not a claim that every Platform test ran or that E2E/manual acceptance passed. The PR body's earlier 188 targeted tests, local just fmt/fmt-check, permission-export run, route-generation checks and /readyz/unauthenticated /mcp smoke checks are author-reported local results; their specific local execution logs were not supplied in the inspected PR evidence.

The author's runtime report states that a real WorkOS-issued Connect token from Codex browser OAuth exposed the HTTPS CIMD validation defect. After the fix, authenticated initialization/discovery and actual Codex desktop calls to both probes succeeded. The PR body identifies CLI 0.163.0; it does not establish the desktop build, active mode or negotiated revision. The code and signed-token tests support the fix, but the live OAuth observations were not independently replayed. The setup guide warns that this CLI version discovers resource automatically and that adding --oauth-resource duplicates it. Verify that version-specific behavior in the activation environment.

The author's development organization was deliberately enabled for those trials. This does not establish production activation, renewal, consent withdrawal, real two-tenant rejection or complete browser-auth regression results.

Specification approval and implementation review

The specification is approved as Ready. The implementation PR determines the final design, and this specification can be updated afterward. Review findings and their resolution remain in the Platform PR; they do not add new Planning approval conditions. Specification approval does not establish implementation merge, ADR adoption, production activation or release acceptance.

CodeRabbit's current-head review records coverage through 542b32ef and no actionable comments in its latest incremental pass. Automated review results are separate from implementation approval and the activation checks below.

Remaining activation and acceptance gates

Gate	Required evidence and decision
Candidate and ownership	Record reviewed/merged implementation and ADR adoption, release commit/image, target environment, exact resource/issuer/organization, named operational owner and acceptance decision owner.
Client compatibility	Record exact desktop/CLI versions, active protocol mode, negotiated revision, OAuth registration/resource configuration, success, cancellation and recovery on the saved connection.
Access and isolation	Deliberate definitions/grants; all four permission combinations; changed permissions and membership; real two-resource/two-tenant rejection; existing browser login/callback/renewal/logout regression checklist.
Withdrawal and lifetime	Measure token expiry, renewal, re-authentication, consent withdrawal, provider propagation and tenant-disable delay. Accept the total exposure; eight seconds alone is not the provider/consent revocation bound.
Capacity and ingress	Verify the documented trusted-client-address ingress controls and operating bounds in the selected deployment.
Operations	Inspect safe logs/Sentry, provider-failure signals, expired-response behavior, disable/re-enable, emergency route withdrawal/rollback, and complete the manual checklists. Record blocking findings and retest fixes.
Acceptance and availability	Record AC-1 through AC-6 results in Product with release/environment evidence. Obtain separate activation and acceptance decisions before expanding use.

No production activation or final acceptance is established by this evidence record. The manual checklist remains unchecked until those results exist.