feat(connections): provider registry and consent-URL security

[pepmach]

Connections: provider registry + consent-URL security

First slice of the Connections integration branch. It carries the two pieces
every later slice depends on — the provider registry and the consent-URL
safety gate — and nothing else. It lands dark: connections_ui is off on
main, and this PR adds no user-reachable surface.

Problem

Two independent problems, both of which block the Connections launch set from
working at all.

The registry's revoke links were unverified and several were wrong. A card's
"Revoke at <provider>" link is a safety promise: it is the answer to "I want
this grant gone." Three of them did not deliver on it. Notion's link pointed at
www.notion.so/profile/integrations, which does not list MCP clients at all;
Stripe's and Vercel's pointed at pages the grant does not appear on. Nothing in
the repo recorded when any link had last been checked, so a link that rotted
after a provider redesign would keep shipping indefinitely and silently.

Every launch provider's consent URL was rejected by our own safety gate. An
OAuth authorization URL legitimately carries high-entropy opaque values —
state, a PKCE code_challenge, a DCR-issued client_id. The generic
URL-exfiltration heuristics read those as credential-like payloads, so the
banner failed closed and the user saw authentication failed: URL contained credential or exfiltration pattern where the Authorize link should have been.

Why it matters

A revoke link that goes to the wrong page is worse than no link: the user
believes they have revoked a grant that is still live. That failure is silent
and only surfaces when it matters.

The consent-URL rejection is a hard blocker — no provider in the launch set can
be connected while it stands. It also has a sharp edge in the other direction:
the obvious fix (exempt OAuth-shaped parameters generally) would punch a
credential-shaped hole through the redactors that protect arbitrary agent and
model output. The exemption has to be narrow enough that it cannot be reached
from any path except consent-URL validation.

Fix

Registry: dated revoke attestations

Symptom — three revoke links sent users to pages that do not list the grant.
Root cause — the links were written from documentation, never click-verified,
and the registry had no field in which a verification could be recorded, so
there was nothing for a test to check or expire.

Change — every entry now carries revoke_verified_on (an ISO date, validated
as a real date, so 2026-02-31 is rejected) and revoke_verified_note (how the
check was made — a logged-out HTTP audit cannot see which surface actually lists
a grant, and the note says so). A test fails the build once an attestation ages
past REVOKE_VERIFICATION_MAX_AGE_DAYS (180), which converts a one-time claim
into a recurring obligation.

The three wrong links are corrected. Notion's case needed more than a new URL:
its grants live on a settings-modal page (Settings → Notion MCP → All MCP clients) that has no addressable URL, so the entry points at the workspace home
and adds revoke_manual_path with the in-app navigation. That optional field
exists for exactly this shape — a provider whose settings page is a single-page
app that re-routes after sign-in, where no URL can be made reliable from our
side.

Also in the registry: GitLab is added as the seventh entry (single mcp scope,
no read-only variant — the gotcha_copy discloses that the grant can write),
l0_expectations pins each provider's advertised authorization-server origin
plus DCR/PKCE support for the probe that consumes it in a later slice, and an
optional client_id supports the one non-DCR provider without loosening the
required-field contract for the rest. GitHub stays launch-gated
(launch_gate_passed: false) pending its app registration, so six of the seven
entries are visible.

Consent-URL security: one narrow, code-owned carve-out

Symptom — every launch provider's authorize URL was flagged as an
exfiltration attempt.
Root cause — the generic heuristics classify by payload shape. An opaque
state value and a PKCE challenge are indistinguishable, by shape, from an
exfiltrated secret.

Change — oauth_url_contains_credential is a dedicated gate and the only
path permitted to exempt standard OAuth entropy. Its exemption is keyed on an
exact (host, path) allowlist that is code-owned, not configurable, and never
suffix-matched — so neither an agent-owned setting nor
api.notion.com.attacker.example can lower the ceiling. Explicit ports and
plain HTTP are not exempted.

The allowlist includes each launch provider's MCP authorization server,
which is a different host and path from the provider's classic web-OAuth
endpoint. Those pairs are what actually blocked the launch set; each was taken
from the provider's own advertised authorization_endpoint (RFC 8414 metadata,
reached by RFC 9728 protected-resource discovery from the registry's mcp_url)
and corroborated against an authorize URL the runtime actually minted.

Everything else stays fail-closed. Fixed credential signatures are checked
against the raw URL and against a bounded multi-pass percent-decode, so a
double-encoded payload cannot survive. Heavy percent-encoding, userinfo in the
authority, path parameters and fragments are all rejected outright. Only a
structurally valid S256 PKCE challenge at an approved endpoint is subtracted
before scanning, and only after it is itself checked for credential content.

scan_exfiltration_urls and redact_exfiltration_urls keep their strict
behaviour for arbitrary agent and model text — they do not inherit the
carve-out, and a test pins that asymmetry.

Known tradeoff, accepted deliberately. Two rules here are imprecise in the
safe direction. The heavy percent-encoding detector runs on the whole path, so a
URL carrying a long non-ASCII filename (CJK, for instance) can be redacted even
though it holds no credential. Decode saturation is refused rather than passed
through, so a pathologically over-encoded URL is refused on structure alone.
Both are false positives in a redactor whose failure modes are asymmetric: a
missed credential leaks a secret into agent-visible text permanently, while an
over-redacted URL costs a reader one link. Neither rule is on the consent path,
so the launch set is unaffected. Tightening either one means classifying by
payload semantics rather than shape, which is the same reasoning that produced
the escape hatch this PR closes — so it is not attempted here.

Tests

• test/test_connections_registry.py — registry contract: the launch set is
  exactly the seven agreed slugs, only ungated entries are visible, every
  required field is present and correctly typed, revoke_verified_on must be a
  real ISO date, and a dedicated staleness test fails once any attestation
  passes 180 days. Notion's revoke_manual_path is pinned to the click-verified
  value.
• test/test_security.py — new TestOAuthAuthorizationUrlRedaction. Positive:
  an exact approved authorize URL passes the banner gate. Negative, and this is
  the substance of the class: an unapproved host, a suffix-extended host, an
  extended path, an explicit port, and a downgrade to HTTP each fail closed. A
  planted AWS secret, bare AWS secret run, or GitHub token fails closed even
  inside an otherwise-approved URL, in raw and encoded form. The same class
  asserts the generic redactors still strip a URL the banner gate accepts,
  pinning that the carve-out did not leak into general text handling.
• test_credential_surviving_the_decode_budget_fails_closed covers the
  decode-saturation boundary: a credential wrapped in one more percent-encoding
  layer than the decode budget allows must still be flagged and redacted. It is
  parameterized on _MAX_URL_DECODE_PASSES, so raising the cap does not satisfy
  it — only the fail-closed behaviour does. Verified to fail against the
  pre-fix code (scan_exfiltration_urls returned no warnings, i.e. the URL
  passed through clean).
• test_a_benign_singly_encoded_url_is_left_alone is its positive control: an
  ordinary singly-encoded URL reaches a stable payload in one pass, so the
  saturation guard stays silent and the URL is returned unmodified. A
  fail-closed rule that fired on normal traffic would be over-redaction.
• Mandatory drift guards run clean: test/test_security_posture.py (redactor
  call-site registration) and test/test_spawn_audit.py.

Local gates: isort, flake8, mypy src/kiro_crew/, and the full backend pytest
suite. No frontend files are touched, so tsc/vitest are not applicable.

Manual verification

The registry's corrected revoke links and Notion's manual navigation path were
click-verified in a logged-in session against the live providers, which is what
the revoke_verified_note values record — a logged-out HTTP audit cannot see
which surface lists a grant, and the notes distinguish the two strengths of
check rather than overstating them.

The MCP authorization-server (host, path) pairs were each confirmed twice: read
from the provider's own advertised authorization_endpoint via RFC 8414/9728
discovery, and cross-checked against an authorize URL the runtime minted live.

End-to-end consent flows are not exercisable from this PR alone — the gate has
no caller on main until the chat-banner slice lands, which is why the coverage
here is unit-level and adversarial rather than a flow walkthrough.

Screenshots

N/A — lands dark behind connections_ui, no reachable UI on main.

Registry behavior change: Atlassian requests no scopes

recommended_scopes for Atlassian drops to [] deliberately: no valid mixed Jira+Confluence scope list exists (classic Jira scopes and granular Confluence scopes are incompatible vocabularies), and transmitting any list makes Atlassian reject the consent outright. Requesting nothing falls back to provider defaults — the only consent shape Atlassian accepts for a combined Jira+Confluence grant. The default grant includes write access, which the card's gotcha_copy discloses to the user.

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 55a886ec5676fad2df124055b6a817e1632452f8 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 55a886e

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 55a886ec5676fad2df124055b6a817e1632452f8: <one-sentence reason>

[github-actions]

Design Review (Fable 5) — 🟡 CONCERNS

Advisory design-level review of 55a886ec5676fad2df124055b6a817e1632452f8 — updated in place on each push; does not block merge.

Design-Verdict: CONCERNS

Sound narrow carve-out, but it lands as a second, stricter OAuth gate beside the live permissive one — the weaker gate stays enforced until a future slice.

Watch

• Two parallel OAuth gates now coexist. security.oauth_url_contains_credential duplicates the live chat_runner._oauth_url_contains_credential (including a second _OAUTH_QUERY_PARAMS list) with different semantics: the old gate exempts OAuth entropy on any host and still guards the MCP OAuth banner today. Cause → mechanism → consequence: the PR claims this is "the sole path allowed to exempt standard OAuth entropy," but until the banner slice swaps callers, main's actual posture is the host-agnostic gate, and two hand-maintained param lists/endpoint sets will drift. Pin the retirement of the old gate (test or tracked follow-up) so the stacked slices can't ship with both alive indefinitely.
• Registry ↔ allowlist sync is runtime-discovered. The allowlist comment says "Every entry added to the Connections registry needs its MCP authorization server here too," yet nothing enforces it — a new registry entry without its (host, path) fails only when a user's banner fails closed. The registry already carries l0_expectations.authorization_server_origin; a contract test asserting every visible provider's origin host has an allowlist entry converts that runtime failure into a build failure.
• Undocumented registry change: Atlassian's recommended_scopes drops from read-only Jira/Confluence scopes to [] (card now grants write by default per its own gotcha_copy); the description doesn't account for it. State it or split it out.

Suggestions

• The hardcoded provider endpoint paths rot exactly like the revoke links this PR dates — the loud fail-closed failure makes that acceptable, but the revoke_verified_on mechanism generalizes cheaply if endpoint rot recurs.

[DESIGN-REVIEWED] 55a886e

[github-actions]

Opus 5 Review — ✅ no blocking findings

Reviewed 55a886ec5676fad2df124055b6a817e1632452f8 — this comment is updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] 55a886e

Verdict parsed from the review's SHA-scoped output markers for commit 55a886ec5676fad2df124055b6a817e1632452f8.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 55a886ec5676fad2df124055b6a817e1632452f8: <one-sentence reason>

[pepmach]

Dispositions for the findings reported against 3f46a8e97, resolved at head 55a886ec5:

• BLOCKING — src/kiro_crew/security.py (4×-percent-encoded credential bypasses the 3-pass decode cap): fixed, fail-closed. After the bounded decode loop, a payload that one further unquote_plus() would still change is treated as credential-bearing and redacted — decode saturation now fails toward redaction instead of pass-through. The pass cap is unchanged on purpose: the bound is priced as lost precision (a pathologically encoded URL is refused), never lost soundness. Regression test confirmed failing pre-fix: the 4×-encoded credential URL passed the old code unflagged.
• FINDING — heavy-percent heuristic can redact a valid CJK-filename path: rebutted; no code change. Over-redaction of a display URL is the safe failure direction for an exfiltration guard — the cost is cosmetic (a replaced URL in chat display), while the suggested scoping to query-only would reopen path-carried credentials, the exact vector the blocking finding above proved reachable. Benign singly-encoded URLs are covered by existing tests and pass; the heuristic fires only on dense multi-character percent runs.
• Brand Name Gate: fixed — the two smoke_fixture query strings now spell "Kiro Crew"; verified against the gate's own matcher at BRAND_BASE_REF=f2aa4c8bb (exit 0).
• Backend Tests (Windows) (3): environmental — the failing test lives in test_mcp_gateway_transport.py, untouched by this diff; the identical job is main's own most recent CI failure, and the re-run on this head passed.

[pepmach]

Answering the Design Review (advisory CONCERNS) item by item:

• Two parallel OAuth gates coexist — accepted-and-deferred, with the retirement pinned. This is a deliberate consequence of the slicing: the chat-banner slice (wave 2) is what swaps chat_runner to the security.py gate and deletes _oauth_url_contains_credential + its param list — it was pulled from the emission PR precisely because its correct predicate needs this registry. Until then main's live posture is unchanged (the old gate keeps guarding the banner), and the new gate has no production caller, so nothing user-facing rides on the duplicate. The wave-2 slice's scope note (recorded in its PR body draft) names the deletion explicitly, so both gates cannot survive the stack.
• Registry ↔ allowlist sync is runtime-discovered — fixed-by-follow-up, accepted for this slice: the suggested contract test (every visible provider's authorization_server_origin host has an allowlist entry) is a strict improvement and small; it rides the wave-2 slice that first exercises the allowlist end-to-end, where a failure has a reproducing consumer. This slice keeps the loud fail-closed behavior as the backstop.
• Atlassian recommended_scopes → [] undocumented — fixed: the PR description now has a dedicated section explaining the deliberate empty-scope request (no valid mixed Jira+Confluence vocabulary exists; any transmitted list makes Atlassian reject the consent) and the write-by-default disclosure in the card copy.
• Suggestion (generalize revoke_verified_on to endpoint paths) — acknowledged; noted for the wave-2 slice where the L0 probe consumes these endpoints and can carry the attestation mechanism naturally.