Daily harness signal · September 24, 2026

One namespace.
Several authority paths.

One implementation lesson · Agent-tool distribution

A strong login check does not protect a namespace when another route grants the same rights from weaker proof. Audit the issued permissions across authentication methods, not just each method’s success.

Evergreen · source August 6, 2026

Do not equate website control with organization authority

Use when

You operate an MCP registry or adapt its namespace verification for an internal agent-tool catalog. GitHub access-token authentication required organization Owners, but control of one GitHub Pages repository could satisfy HTTP proof and obtain the same organization-wide publishing namespace.

Action

Require the server-side repair included in Registry 1.8.1, or a reviewed equivalent; updating mcp-publisher alone does not repair the server. At the shared DNS/HTTP validation boundary, lowercase the domain and reject this predicate before fetching proof or issuing a token: 

d == "github.io" || strings.HasSuffix(d, ".github.io")

Direct io.github publishers to reviewed GitHub authentication. In your existing authorization tests, record each enabled route’s required proof and resulting namespace grants. A matching namespace string must not silently erase differences in authority.

Acceptance check

Use local mocked handlers, not public namespaces. Both DNS and HTTP must reject github.io, my-org.github.io, my-org.GitHub.IO, and sub.my-org.github.io without proof fetches or JWT issuance. An ordinary domain with valid proof must still authenticate. The lookalike github.io.example.com must not match the Pages exclusion or receive io.github.* rights. For GitHub access-token exchange, an active member must lack the organization grant; an active Owner must receive it. Retain server revision, statuses, fetch counts, and decoded permission claims.

Evidence

Merged PR 1506 has maintainer confirmation and ships in the August 6 release. Tagged source places the exclusion before key retrieval; both handlers use that shared path. Tagged table tests cover case, subdomains, and lookalikes. The access-token implementation explicitly checks active Owner membership. These are inspectable source semantics, not our runtime results.

Caveat

This closes the Pages route, not all organization-wide publishing paths. Tagged GitHub OIDC still grants the repository owner’s whole namespace; do not advertise the registry as universally Owner-only. Namespace authorization also does not establish package safety, per-server ownership, or clean historical metadata. Our handler-level acceptance procedure is untested; no registry, credential, installation, or configuration changed today.

Compact source notes

  1. SashaMIT’s PR 1506, merged August 6, 2026, and Registry 1.8.1, released that day. Maintainer review reports targeted and race tests passing; no exploitation incident or public deployment verification is claimed.
  2. Tagged shared validator, regression tests, DNS handler and HTTP handler inspected, not executed. Retrieved main and history retain the repair; neither attests deployed binaries.
  3. Owner-check PR 1383, merged July 10, documents both its limits and owner/member verification. Tagged access-token and OIDC implementations confirm distinct grant rules. OIDC signature/audience validation is not an organization-role check; this issue is not a recommendation to replace OIDC with broadly shared personal tokens.
  4. Anchor lens: exact grant construction, shared validation and negative assertions. Unity lens: overlapping authentication routes must preserve explicitly intended authority, not merely identity spelling; proposed invariant. Source semantics: confidence_confirmed; proposed integration checks: confidence_likely. A prohibited proof fetch, JWT, or namespace grant falsifies the corresponding acceptance check.