Skip to main content
Synthetic defensive note — not customer work

Boundary note 01 · 25 July 2026

Authenticated is not authorized.

A valid identity at the MCP edge proves who entered. It does not prove that the downstream resource belongs to that identity.

Boundary under review
Identitytenant-red Tool inputtenant-blue · inv-200
Input controls scope lookup(args.tenant_id) Cross-tenant result Authenticated request, wrong authorization subject.
Identity controls scope lookup(ctx.tenant_id) Denied Caller input selects an object, never the owner scope.
SourceSynthetic handler
DecisionIdentity owns scope
FailureInput replaces identity
VerificationDenied negative test
01 · Architecture

Follow the authorization value, not just the request.

Authentication belongs to the connection or request context. Tool arguments are untrusted selectors. The handler must preserve that distinction when it constructs the downstream lookup.

02 · Trust decision

The trusted identity supplies the owner scope.

An object identifier from tool input can select which invoice, repository, ticket, or connected account the caller wants. It must not select which tenant or user owns that object.

Authorization invarianthandler layer
requested_object = args.object_id
owner_scope = context.authenticated_tenant

resource = store.find(
    object_id=requested_object,
    tenant_id=owner_scope,
)

if resource is None:
    raise AuthorizationError()
03 · Failure mode

Normal telemetry can describe the wrong decision perfectly.

Transport authentication can succeed, the tool can exist, the JSON schema can validate, and the downstream lookup can return quickly. If the handler uses caller-controlled tenant input, ordinary telemetry records a legitimate-looking success while missing the ownership error.

Observedtools/call · get_invoice · success · 42 msValid shape

The defect is established by comparing the authenticated identity with the source-level storage predicate, not by treating a successful tool call as proof of authorization.

04 · Defensive verification

Prove an allowed path and a denied path.

  1. 01

    Pin the reviewed source, configuration, authenticated identity, and non-production resource fixtures.

  2. 02

    Execute one same-owner request and confirm the expected object is returned.

  3. 03

    Keep the authenticated identity fixed, change only the requested object to another tenant, and require a typed denial.

  4. 04

    Inspect the source predicate and confirm the trusted context, not tool input, supplies owner scope.

A passing negative test proves this pinned boundary rejected this fixture. It is not certification of the application, organization, or MCP protocol.

The complete vulnerable handler, fix, and executable retest are in the synthetic case study. Engineers can inspect the broader bounded telemetry reproduction on the technical proof page.

Synthetic reference — not customer work

Which identity-to-resource path matters most?

Bring one deployed boundary. Rasheed will tell you whether it fits the focused review before asking for evidence.

Discuss one MCP boundary