11

Model Context Protocol (MCP) Tool and Argument Authorization

Treat every model tool call as an untrusted proposal, filter MCP discovery before it reaches the prompt, and authorize the exact arguments again at execution time.

The enterprise problem and today’s slice

Enterprise problem: Northstar may approve a useful supplier-system connector yet still leak sensitive schemas or modify the wrong supplier when the HelixWorks Supplier Onboarding Agent sees every reachable tool and treats a model-selected argument as authority.

Whole-course context: The previous slice produced a credential-free runtime, a workload-bound run delegation, and a single-action capability pattern; today consumes that chain to govern which MCP tools appear and which exact call may execute.

Today’s slice: We build a reviewed tool catalogue, filter discovery through current policy intersections, authorize exact resources and arguments before credential retrieval, use resource-specific MCP OAuth, and preserve the source provider’s final access-control list (ACL) decision.

End-of-day evidence: Acme receives an exact discovery list, a hidden-tool denial, an allowed Marketing-channel post, and a denied executive-channel post with immutable policy digests and provider traces where execution occurred.

Still unsolved: Optional personal connector delegation, enterprise-managed MCP consent, human approval for high-risk intent, and nested agent invocation remain outside this slice.

Thesis: MCP reachability only exposes a candidate catalogue; safe tool use requires the gateway to filter what the model may discover and then reauthorize the exact proposed call before any credential is resolved.

Smallest complete model: Discover, decide, execute. Northstar first shows the Supplier Onboarding Agent only reviewed Procurement tools, then decides one exact supplier change, then executes through a source-specific credential and the supplier system's own ACL.

MCP is a protocol through which AI clients discover and call tools. Its tools/list and tools/call operations are separate authorization moments; hiding a tool reduces exposure but never replaces execution-time denial.

Customer outcome and implementation focus

The customer outcome is a reliable, reviewable implementation of 07 mcp tool and argument authorization. This day introduces the mechanism before policy detail and evidence review; it does not repeat the same customer stories in prose, tables, and diagrams.

Components in focus

Authorization policy service owns decisions; the connector/runtime gateway owns enforcement. Compute: API and isolated worker processes. Storage: PostgreSQL is authoritative for grants and state; Redis is a versioned cache; vault owns secrets; object storage retains redacted evidence only.

Implement the mechanism

Implement the day’s boundary with a current, explicit decision before privileged compute or a downstream call. Bind every effect to a tenant, subject or workload, deployment, resource, and short-lived evidence ID; a cache or model response never grants authority.

Failure modes, trade-offs, and decision rules

MCP controls trade prompt utility and latency against exposure and freshness, but no trade-off permits credential lookup before an exact allow. Acme should spend complexity where it removes a trust bridge.

Reusable decision rule: Filter the catalogue before prompt construction, reauthorize the exact canonical call before broker access, and let the source ACL make the final resource decision.

Failure or trade-offConsequenceReusable decision rule
Return all server toolsSchema leakage, prompt noise, and accidental selectionFilter to explicit intersection before prompt construction
Trust server annotationsMalicious metadata lowers riskEffective risk is maximum of server hint, platform review, organization override, and runtime arguments
Authorize tool name onlyAllowed tool escapes through channel, recipient, data class, or sizeValidate exact canonical arguments and resource set
Copy source ACL into platformStale duplicate may overgrant or incorrectly denyPlatform narrows; source provider decides final resource access
Resolve credential before policyDenied proposal still reaches sensitive secret pathMake broker access structurally downstream of persisted allow
Cache catalogue indefinitelyChanged or disabled tool remains visiblePin reviewed digest to deployment and invalidate on schema/policy revision

Implementation and verification

A polished tool preview can hide an unsafe direct-call path, so Acme must implement discovery and execution as independent guarded endpoints sharing versioned policy inputs.

  1. Ingest the Slack MCP catalogue into a governed registry; compute and review schema digests and independent risk.
  2. At tools/list, intersect reviewed, connector, Marketing, version-17, deployment, and Alice restrictions; persist exact inputs and output names.
  3. At tools/call, verify run audience and current owner facts, then canonicalize and authorize channel, text, data class, and risk before any broker call.
  4. Resolve the chosen service binding only after allow; request a short-lived token whose audience is the Slack MCP resource, never pass the platform token.
  5. Let Slack apply its ACL; append provider request ID and observed result to the prior decision.
  6. Quarantine changed schema digests and require policy fixtures plus review before rediscovery.

Verify exact list equality, hidden-tool absence, direct hidden-tool denial, changed-schema quarantine, Marketing allow, executive/external denial, overlength denial, broker-not-called assertion, wrong-audience rejection, Slack ACL denial, and a valid positive control for each denial.

Practical next action and falsifiable evidence

Acme should now run one two-part contract test against Campaign Launch version 17: snapshot the effective catalogue, then execute the same message against allowed and forbidden channels and retain the observed outcomes. This proves both halves of the model without adding human approval yet.

The thesis is falsified if an unauthorized schema reaches the prompt, a hidden tool reaches the broker, an argument changes after allow, the platform token reaches Slack, or platform approval bypasses Slack’s ACL. Passing evidence shows a reviewed discovery subset followed by a separately authorized, resource-specific provider call.

HelixWorks repository lab

Treat an MCP tool as a typed operation before it becomes a provider call. services/connector-broker/src/domain.ts derives the protected resource and exact argument digest:

export const argumentDigest = (operation: SupplierOperation): string =>
  `sha256:${createHash('sha256')
    .update(JSON.stringify(canonicalize(operation)))
    .digest('hex')}`;

export const resourceFor = (operation: SupplierOperation): string =>
  `supplier/${operation.type === 'supplier.create'
    ? operation.supplier.externalId
    : operation.externalId}`;

The broker interprets Northstar's supplier.create intent, creates stable policy inputs, and only then permits network I/O. Hashing consumes CPU; a decision linked to the provider operation ID proves enforcement. Canonicalization and resource derivation are reusable domain functions (DRY/SRP); the gateway is injected (IoC/DI), so discovery cannot gain credential access by importing provider code.

pnpm --filter @helixworks/connector-broker test

Authorize one supplier payload, reorder its keys, then change its email. Reordering must preserve the digest; the changed email must change it and deny against the old grant. A provider call for the changed payload falsifies exact-intent authorization.