Map the Gateway Before Adding Credentials
Build one observable request path before adding authorization or secrets. • Lab status: conceptual reconstruction. Receipts are expected simulated outputs, not deployed-system measurements.
System map · Day 01
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Entry and policy
Ahead — Browser and callback
Client entry
Design target · not proved
Starts one no-auth request with a known operation and an evidence identifier.
Onboarding and control
Connector control plane
Design target · not proved
Accepts only the connector and operation already approved for this bounded trace.
Authorization services
Ahead — Authorization server
Compute and execution
Ahead — Refresh coordinator compute
Storage and evidence
Ahead — Specification draft store · Connector configuration store · Secret and token vault · Sanitized discovery cache · Ordered migration log
Evidence plane
Source-backed today
Stores redacted 200 and 401 traces without retaining request credentials.
Traversed today
Overview
Why a connector gateway needs a boundary map
A connector gateway accepts a caller's request, applies a connector policy, and asks an upstream system to do work. If those responsibilities blur, a successful HTTP response can hide the wrong caller, wrong destination, or leaked credential. Today you will trace the smallest complete path through the fictional Atlas Connector Lab and produce SCG-R01, a boundary map backed by one allowed call and one upstream denial.
The recurring lab has two upstream interfaces: a Calendar REST API and a companion Model Context Protocol (MCP) server. MCP is a protocol through which a client can discover and call tools. The gateway may translate either request shape, but the external resource still owns its data and final authorization decision.
Read evidence without leaking request material
An evidence plane turns each boundary decision into a redacted record. Its job is to preserve actor, resource, scope, precondition, expected result, observed result, environment, timestamp, and immutable run ID. It must not store authorization headers, cookies, request bodies, or future secret values.
{
"runId": "scg-d01-denied",
"actor": "learner-client",
"resource": "calendar-lab:list-private-events",
"precondition": "route resolved; no credential configured",
"expected": "upstream_unauthorized",
"observed": "upstream_unauthorized",
"secretFields": "redacted"
}
For the positive control, call public-status again after the denial and require another 200. Recovery means correcting a mistyped connector ID and replaying only that disposable request. Cleanup deletes the two local trace receipts; it does not mutate the upstream fixture.
Decide which actor owns the denial
The worked example supplies every fact except one: which actor rejected the protected call? Choose client entry, connector control, connector runtime, or external resource, and cite the observed status boundary. The deterministic answer is external resource because the trace proves the runtime executed the request and recorded the upstream 401.
Treating any 401 as a gateway routing failure is the target misconception. Replay the public control through the same route: its 200 separates healthy routing from missing upstream authority. Decline questions that ask you to design authorization, choose scopes, or add a secret; those are multiple unknowns and belong to later days.
Carry the boundary receipt forward
SCG-R01 contains the five stable actors, the request and execute edges, paired 200/401 evidence, and scoped cleanup. Day 02 consumes this map to place OpenAPI validation and connector-draft storage at the control boundary.