V33 Promotion: Keep credential identifiers out of proof-root hashing

Route MCP interface authorization roots through the authenticated principal instead of API key record ids, document the boundary in V33 promotion notes, and regenerate the V33 promotion readiness report.\n\nValidation:\n- pnpm --dir packages/executions-mcp/src/mcp-server run type-check\n- pnpm --dir packages/executions-mcp/src/mcp-server run test:mcp -- --runTestsByPath src/__tests__/unit/pipeline-ingress-contract.test.ts --runInBand\n- pnpm --filter @bitcode/btd test -- --runTestsByPath __tests__/interface-authorization-policy.test.ts --runInBand\n- pnpm run generate:v33-promotion-readiness\n- pnpm run check:v33-gate10\n- git diff --check

Author: geraldarthurdavis

.bitcode/v33-promotion-readiness-report.json

@@ -55,7 +55,7 @@
   "currentTarget": "V32",
   "documentationEvidence": [
     {
-      "digest": "sha256:c5f427b82720085093158501a0141d4db171ace7437481a4bc175b4897081df5",
+      "digest": "sha256:f4f18279dea8ecc27de7e13ee5c4c4496b45ad5e4dfd37aa2909355fda7f391e",
       "present": true,
       "relativePath": "BITCODE_SPEC_V33.md",
       "requiredTokens": [
@@ -74,7 +74,7 @@
       ]
     },
     {
-      "digest": "sha256:3fb790d89c99396ca8e422cdfdadcff9baf2c4bf5b44cd338313bf08826c8f5a",
+      "digest": "sha256:82166f72b7f63ad1dae97e1ddb258af14cfca8d69b1e0dbd4437432e8455ca5d",
       "present": true,
       "relativePath": "BITCODE_SPEC_V33_DELTA.md",
       "requiredTokens": [
@@ -93,7 +93,7 @@
       ]
     },
     {
-      "digest": "sha256:3dea3f5113e0fc89303a92fef92d88eef7faf56c3015cd00950965983c463f86",
+      "digest": "sha256:d044bd4bad93f88f2019a8133a172807389a710f4f5c5eb5406da88d981a7755",
       "present": true,
       "relativePath": "BITCODE_SPEC_V33_NOTES.md",
       "requiredTokens": [

BITCODE_SPEC_V33.md

@@ -572,6 +572,8 @@ Generated artifacts must be stable, source-safe, and explicitly tied to validati
 
 V33 Gate 10 closes when `version/v33` can promote to active V33 without direct `main` writes. The readiness report `.bitcode/v33-promotion-readiness-report.json` proves that all V33 interface artifacts are present, source-safe, parseable, and wired into gate checks, promotion checks, generated proof appendix support, and workflow validation. Promotion rewrites runtime posture from `V32` active / `V33` draft to `V33` active / `V34` draft and generates `BITCODE_SPEC_V33_PROVEN.md`; the resulting posture is V33 active / V34 draft.
 
+Interface authorization promotion readiness also requires credential identifiers to stay outside BTD proof-root hashing. Interface adapters may retain API key record ids in adapter-local audit context, but BTD roots bind the authenticated principal, organization authority, wallet/license/rights state, protected-source visibility, and repair posture.
+
 ## V33 validation canon
 
 Validation must include spec-family checks, canonical-input checks, canon-posture drift checks, V33 gate checks, package tests, interface contract tests, and source-safe example tests.

BITCODE_SPEC_V33_DELTA.md

@@ -235,5 +235,6 @@ Closure acceptance:
 
 - V33 promotion checks validate all gate artifacts, interface contracts, compatibility matrices, telemetry proof hooks, and generated proof appendix support;
 - promotion scripts support V33 command planning, dry-run, generated proof output, and derived promotion commit body generation;
+- MCP and other interface adapters keep credential record identifiers in adapter-local audit context rather than hashing them into BTD authorization proof roots;
 - promotion workflow can rewrite active V33 / draft V34 posture;
 - `version/v33` can be requested into `main` only after all V33 gates close.

BITCODE_SPEC_V33_NOTES.md

@@ -233,6 +233,12 @@ The Gate 10 checker is `check:v33-gate10`. It must pass both before promotion
 with `BITCODE_SPEC.txt` pointing at `V32` and after promotion with the pointer
 at `V33`.
 
+Promotion readiness also requires interface authorization proof roots to avoid
+hashing credential record identifiers as proof material. Interface adapters keep
+API key record ids in their own audit context; BTD authorization roots bind the
+authenticated principal, organization authority, wallet/license/rights state,
+and source-visibility decision.
+
 ## Carryforward from V32
 
 V33 inherits these V32 truths:

packages/executions-mcp/src/mcp-server/src/tools/pipeline-tools.ts

@@ -184,10 +184,10 @@ function assertPipelineWriteAdmission(
     action: 'request_finding_fits',
     authIssuer: {
       issuerKind: 'api_key',
-      issuerId: context.apiKeyId ?? context.userId,
+      issuerId: context.userId,
       issuedAt,
       expiresAt: new Date(Date.now() + 10 * 60 * 1000).toISOString(),
-      issuerRoot: context.apiKeyId ? `mcp-api-key:${context.apiKeyId}` : `mcp-user:${context.userId}`,
+      issuerRoot: `mcp-authenticated-principal:${context.userId}`,
     },
     actorId: context.userId,
     organizationId: context.organizationId ?? null,