Delegated and Managed Model Context Protocol (MCP) Access

Enterprise problem: The Northstar HelixWorks Supplier Onboarding Agent serves people and schedules, so one generic “connected” state can accidentally run nightly jobs as a departed creator, select Alice's consent for Bob, or reveal MCP connectors to an unauthorized group.

Whole-course context: The previous slice produced filtered MCP discovery and exact argument authorization; today supplies the separately owned credential binding that the gateway may resolve only after that allow.

Today’s slice: We implement durable Marketing-managed service access first, optional per-user delegated OAuth second, and identity-provider-group discovery policy third, while keeping provider, hosted-runtime, generated-app, and source-system ownership separate.

End-of-day evidence: Acme receives managed schedule allow/revoke pairs, Alice/Bob subject-selection pairs, and enterprise-group discovery allow/remove pairs with source-provider results and immutable actor chains.

Still unsolved: Human approval for risky actions, agent-to-agent delegation, data trimming, network infrastructure, and continuous audit operations remain outside this slice.

Thesis: Connector authority must be selected by operating mode, not convenience: schedules act as a durable team service, interactive on-behalf-of runs act as the current user, and enterprise policy decides who may discover or establish either path.

Smallest complete model: Choose mode, resolve the matching principal, then obtain a resource-specific token. The gateway never falls back from one branch to another when the required binding is missing.

For Northstar, the Supplier Onboarding Agent's nightly compliance report uses service:procurement-automation; Alice's interactive document lookup uses Alice's provider subject; Bob without consent receives a user action, not Alice's token or the service account.

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

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 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.

Choosing an authority mode changes reliability, attribution, and blast radius; a single default cannot optimize all three. Acme should make the choice visible at connector setup and never infer it at execution.

Reusable decision rule: Choose authority mode explicitly, resolve only the principal type and binding owned by that mode, and deny or request a new customer action instead of falling back across modes.

A credential broker can look safe while its selection order leaks another subject or mode, so implementation begins with explicit mode state and exact principal-keyed lookup.

1. Add managed mode only for connectors that declare support; provision Marketing service principal and source ACL before creating schedule.
2. Store managed metadata and Vault reference separately; issue schedules with service sub, agent/version act, and configured_by audit field.
3. Implement personal OAuth with resource indicator and minimum scopes; key binding to current platform subject plus provider subject/tenant.
4. Make lookup fail closed on missing, revoked, expired, or under-scoped binding; remove all cross-user and cross-mode fallback.
5. Version Acme IdP-group mappings; filter discovery metadata and invalidate on membership change without treating mapping as source permission.
6. Mint exact MCP-audience tokens only after prior tool authorization; send transient token directly from broker/gateway to adapter, never runtime or browser.

Verify scheduled allow after Alice offboarding, wrong-team denial, managed revocation with no creator fallback, Alice allow, Bob missing-consent denial, Bob/Alice binding separation, wrong audience, personal revocation, group removal hiding metadata, direct hidden-access denial, retained-group control, linked cross-account allow, and unlinked-tenant deny.

Acme should now configure one Campaign Launch connector in both explicitly supported modes and run a six-row identity matrix: managed schedule before/after Alice offboarding, managed revoke, Alice interactive allow, Bob missing-consent deny, and IdP-group removal. Retain each observed provider result and denial; this is the smallest evidence set that proves mode and subject selection.

The thesis is falsified if configured_by becomes sub, Bob reaches Alice’s binding, missing consent falls back to service access, a platform token reaches the MCP server, group membership bypasses source ACL, or revoking one mode changes another. Passing evidence shows the selected operating mode determines exactly one principal binding and one resource-specific token, with independent lifecycle and denial.

HelixWorks issues a short-lived exact capability; a production identity adapter can supply either a user-delegated or managed principal without changing the application service. See services/policy-broker/src/application.ts:

const grant: CapabilityGrant = {
  id: `capability_${this.ids.next()}`,
  tenantId: command.tenantId,
  runId: command.runId,
  connectorId: command.connectorId,
  capability: command.capability,
  resource: command.resource,
  argumentDigest: command.argumentDigest,
  issuedAt,
  expiresAt: new Date(issuedAt.getTime() + command.ttlSeconds * 1_000),
  revokedAt: null,
};

The service interprets normalized authority and persists one bounded grant; CPU creates identifiers and timestamps; stored expiry plus the audit decision are evidence. Repository, clock, and ID ports are injected (IoC/DI), so managed and delegated adapters do not duplicate policy logic (DRY), while identity translation and grant issuance retain separate responsibilities (SRP).

pnpm --filter @helixworks/policy-broker test

Issue otherwise identical user-bound and service-bound fixtures, revoke one, and decide both again. Only the revoked grant must deny. A managed fixture containing a human refresh token or both modes sharing one revocation key falsifies the design.