{"version":"2.1.274","anchor":"403-handling-in-bearer-token-auth-retry-now-gated-by-nks","canonical_anchor":"403-handling-in-bearer-token-auth-retry-now-gated-by-nks","heading":"403 retry and design-consent handling gated by an additional origin check","tier":"internal","area":"Auth","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274\/e\/403-handling-in-bearer-token-auth-retry-now-gated-by-nks","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274","markdown":"### 403 retry and design-consent handling gated by an additional origin check\n\nBearer-token 403 retry logic and the design-consent MCP error path now both require an extra same-origin check (Nk) before triggering.\n\n**Unclear.** What condition the new Nk(s) check actually verifies is not specified.\n\n**What**\n\n- The fetch wrapper that retries a request after a 403 response with a sent bearer token now also requires a new check (`Nk`) to pass, in addition to the existing check that the response was a 403 with a token sent.\n\n- The same check now gates whether a 403 response gets turned into a `needs_consent` design-MCP error, restricting that behavior to first-party design MCP endpoints.\n\n**Why** This narrows when the 403-retry and design-consent behavior kicks in, preventing them from firing for responses that aren't actually from the first-party design MCP service.\n\n- Area: Auth\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}