Delegated and Managed MCP Access

Enterprise problem: Customers need both unattended and user-personalized agents, but reusing a creator’s consent for schedules or treating a shared service credential as every user’s authority creates unowned access, weak attribution, and costly offboarding failures.

Whole-course context: The connector and per-call gateway now exist; today consumes their credential-binding and argument-policy evidence to define who the downstream MCP call acts as and how that grant is onboarded, refreshed, and revoked.

Today’s slice: Establish the admin-provisioned machine or service grant first, add optional on-behalf-of user grants as a separate mode, and map enterprise identity-provider policy to connector discovery without merging the provider, runtime, generated-app, or source-system planes.

End-of-day evidence: Reviewers receive observed allow-and-deny pairs for a scheduled service call, an interactive delegated call, and enterprise-managed discovery, each with immutable actor-chain and source identifiers.

Still unsolved: Approval of exact high-risk actions and bounded agent-to-agent delegation remain for the next slice.

If one connector mode silently substitutes for another, a schedule can inherit an employee’s authority or an interactive user can inherit a broad service account. A managed grant belongs to a durable organization or team principal; a delegated grant represents a specific user’s downstream consent through OAuth, the standard delegated-authorization protocol, and must remain independently scoped and revocable. An enterprise identity provider (IdP) authenticates workforce identities and supplies signed group membership; a source-provider access-control list (ACL) remains the final resource rule.

Use case ID	Actor	Customer job	Success outcome	Denial or recovery evidence
D08-UC-01	Team automation administrator	Run a nightly report through a team-managed MCP connector after the initiating employee has left	The schedule acts as a durable service principal, reaches only approved team resources, and attributes the configuring human as audit metadata rather than subject	A wrong-team or revoked-service probe is denied; an approved scheduled call remains the positive control
D08-UC-02	Enterprise end user	Use a shared agent with their own Google or Salesforce authority	The gateway selects only that user’s active binding, exchanges it for an MCP-resource-specific token, and the provider applies that user’s ACLs	A user without consent or required scope receives an authorization prompt or stable denial; another user’s binding is never selected
D08-UC-03	Enterprise identity administrator	Centrally map identity-provider groups to connector discovery and access policy	Group changes alter connector visibility and permitted tool/resource policy without requiring every employee to discover unauthorized servers	A user outside the mapped group cannot see connector names, schemas, resource names, or authentication configuration; an in-group user remains a positive control

Neither grant inherits the other. Team-managed service access is the primary automation path and must be complete before optional delegated access is enabled. A generated application’s tenant, end user, or role may be an input to explicit mapping policy, but no app session can manufacture either kind of provider connector grant.

If the product shows only “connected,” administrators cannot distinguish a team service account, an employee’s OAuth consent, or centrally managed enterprise access. These stories make subject, owner, provider tenant, granted scopes, and revocation status visible without exposing secret material.

Story ID	Use case IDs	User story	Observable acceptance conditions
D08-US-01	D08-UC-01	As a team automation administrator, I want schedules to act as a durable service principal, so that unattended work survives personnel changes without inheriting a creator’s rights	Schedule preview shows service subject, owner team, provider subject, bounded resources, deployment binding, and configured_by separately; post-offboarding scheduled probe succeeds while wrong-team probe denies
D08-US-02	D08-UC-02	As an enterprise end user, I want a shared agent to use only my downstream OAuth grant, so that provider ACLs and revocation remain personal	Alice’s run selects Alice’s binding and Bob’s selects Bob’s; missing consent or scope produces a stable user action or denial; no refresh or access token appears in runtime, prompt, browser, state, or logs
D08-US-03	D08-UC-03	As an enterprise identity administrator, I want identity-provider groups to govern MCP discovery, so that users do not learn about servers or resources they cannot use	Group-to-connector mapping is reviewable and versioned; removal from the group hides the connector and denies direct access promptly; in-group discovery remains an observed positive control

The same shared agent can therefore serve multiple people while credentials remain separate. Alice’s call uses Alice’s provider subject; Bob’s call uses Bob’s. A schedule uses neither: it uses service:marketing-automation or another durable machine principal.

If consent and token issuance are recorded without an observed downstream operation and negative control, the platform cannot prove that subject selection or revocation works. Each terminal envelope contains actor, resource, scope, precondition, expected result, observed result, environment, timestamp, and immutable run, trace, source, decision, or artifact identifiers.

Flow ID	Use case IDs	Path	Trigger	Numbered steps	Terminal evidence
D08-FLOW-01	D08-UC-01	Happy	Administrator enables “Team-managed” mode and runs a scheduled test	1. Verify the connector explicitly supports managed mode.<br>2. Require a team administrator to authorize a durable service principal at the provider.<br>3. Validate provider resource ACLs, granted scopes, reviewed tools, and deployment binding.<br>4. Persist only an encrypted secret reference and service ownership.<br>5. Issue the schedule run with sub=service_marketing_automation and configured_by=user_alice as audit data.<br>6. Exchange or mint an MCP-server-specific token and execute the read-only report.	Envelope records service actor, report resources and scopes, active managed-grant precondition, expected allow, observed provider result, production-like environment, timestamp, immutable schedule run, decision, trace, consent artifact, and provider request IDs
D08-FLOW-02	D08-UC-01	Denied	Security operator revokes the managed grant and selects “Verify revocation”	1. Revoke the source-provider grant and control-plane binding.<br>2. Invalidate broker caches.<br>3. Start a new scheduled run.<br>4. Deny before MCP call with no fallback to the creator’s binding.<br>5. Call an unrelated active managed connector as positive control.	Paired envelopes record service actor, revoked and unaffected resources, scopes, revoked precondition, expected denial and control allow, observed credential_binding_revoked and provider success, environment, timestamp, immutable run, decision, trace, and provider request IDs
D08-FLOW-03	D08-UC-02	Happy	Alice selects “Connect my account” and then runs the shared agent	1. Authenticate Alice to the provider control plane.<br>2. Start provider OAuth with resource and minimum scopes for the MCP server.<br>3. Store encrypted refresh token, issuer, provider subject and tenant, scopes, expiry, consent version, and revocation status under Alice’s binding.<br>4. Authorize the tool intent against Alice’s current platform and deployment authority.<br>5. Resolve only Alice’s binding.<br>6. Exchange authority for a short-lived token with MCP-server audience, Alice as subject, and agent as actor.<br>7. Invoke the MCP server and let the source provider apply Alice’s ACL.	Envelope records Alice and agent actor chain, source resource and scopes, active personal-consent precondition, expected allow, observed provider result, environment, timestamp, immutable run, decision, trace, consent, token-exchange, and provider request IDs
D08-FLOW-04	D08-UC-02	Denied	Bob runs the shared agent without authorizing the connector	1. Authenticate Bob and authorize the run.<br>2. Resolve the connector’s user-scoped mode and team access.<br>3. Search only for Bob’s binding, never Alice’s.<br>4. Return user_must_authorize_connector before secret retrieval.<br>5. Repeat Alice’s call as the positive control.	Paired envelopes record Bob and Alice actor chains, same source resource and requested scopes, missing-versus-active consent preconditions, expected deny and allow, observed stable denial and provider success, environment, timestamp, immutable decision, trace, consent, and provider request IDs
D08-FLOW-05	D08-UC-03	Happy	Identity administrator publishes an IdP-group connector policy	1. Validate the signed group assertion and organization tenant.<br>2. Map acme-marketing to Marketing Drive, Slack, and brand-asset MCP connectors.<br>3. Apply connector, tool, resource, and deployment restrictions.<br>4. Recompute effective discovery for an in-group user.<br>5. Return only permitted connector descriptions and tools.<br>6. Seal the mapping revision and observed list.	Envelope records identity administrator and in-group user, connector catalogue resource, discovery scopes, active group-policy precondition, expected filtered list, observed exact list, test environment, timestamp, immutable mapping revision, decision, source assertion, and trace IDs
D08-FLOW-06	D08-UC-03	Denied	Identity administrator removes a user from the mapped IdP group and runs a negative probe	1. Ingest the new group-membership version.<br>2. Invalidate cached discovery and pending connector authorization.<br>3. Request discovery and direct connector access as the removed user.<br>4. Hide server name, tools, schemas, resource names, and authentication configuration.<br>5. Repeat with an in-group user as positive control.	Paired envelopes record removed and retained users, hidden connector resource, discovery and call scopes, new membership precondition, expected deny and control allow, observed empty/denied and permitted results, environment, timestamp, immutable group version, decision, source assertion, and trace IDs

Managed service access comes first

Unattended work includes nightly reports, scheduled campaign synchronization, webhook-triggered support triage, batch document processing, and autonomous monitoring. These jobs cannot safely depend on the creator’s personal refresh token. The managed path requires connector support, team-admin approval, a durable team-owned principal, source-provider permissions restricted to named resources, an explicit deployment binding, allowlisted tools, and stronger policy for destructive operations.

A scheduled token identifies the service principal as sub; its act claim identifies the agent and immutable version. Organization, team, deployment, run, schedule, and trigger appear as bounded context. configured_by is audit information only. When the administrator leaves, the schedule continues because its subject never was that employee.

User delegation is separate and optional

User-level OAuth preserves source-provider ACLs, user-specific revocation, and human attribution, but requires consent, can expire, and may make schedules unreliable. The credential lookup must first verify connector mode and team availability, then fetch the binding keyed by connector, principal_type=user, and the current subject. It rejects missing, inactive, expired, or under-scoped bindings. It never falls back to another user or the team service account unless the product starts a separately authorized mode-change flow.

The platform user token authenticates the user to the provider control plane; it is never forwarded to an MCP server. The gateway obtains a resource-specific token through authorization code flow, token exchange, or another approved grant. A delegated token can carry sub=user_8472, act={agent_campaign_launch, version 17}, client ID, organization, team, deployment, run, narrow scopes, and rich authorization_details such as permitted account IDs and actions. The audience names the MCP server and lifetime is short.

If consent, subject selection, and enterprise group policy are collapsed into one “connection” flag, revocation in one mode can unexpectedly enable another. The design gives managed bindings, delegated user bindings, and enterprise discovery mappings distinct state machines while sharing the credential-free gateway and evidence path.

Use case ID	Entry point	Responsible services	Authoritative store	Failure evidence
D08-UC-01	“Team-managed” setup, scheduled test, and revocation verification	Connector Admin API verifies mode; Identity Service owns service subject; Credential Broker resolves active managed binding; Scheduler issues service run; Token Service requests MCP audience; adapter calls provider; Evidence Service proves outcomes	Connector Binding Registry for managed status and owner; Identity Registry for service principal; Vault for secret bytes; provider authorization server for source grant; Schedule Store for trigger ownership	Creator binding selected, wrong-team access, token with human creator as subject, source revocation ignored, or missing unaffected control
D08-UC-02	“Connect my account” consent and interactive run	OAuth Client manages consent callback; Credential Broker keys lookup to current user; Authorization Service checks current run and scopes; Token Exchange Service produces MCP token; source provider applies user ACL; Evidence Service records actor chain	User Credential Binding Registry for metadata and status; Vault for refresh token; authorization server for consent and token; source provider for user ACL	Alice binding selected for Bob, missing scope accepted, platform token passed through, wrong MCP audience accepted, or revoked consent still usable
D08-UC-03	IdP-group policy editor, discovery preview, and removed-user probe	Federation Ingest validates group assertions; Enterprise Mapping Service versions group mappings; Discovery Service filters connector metadata; cache invalidation propagates membership changes; Evidence Service pairs removed and retained users	Enterprise Access Policy Store for mappings; enterprise IdP remains authoritative for membership; Governed Connector Registry for discoverable metadata	Unauthorized connector metadata disclosed, stale group access persists past bound, source assertion from wrong tenant accepted, or in-group positive control fails

Enterprise-managed authorization and discovery

Enterprise-managed MCP authorization lets an organization use its existing identity provider to centralize access rather than forcing every employee to discover and independently authorize every server. An IdP group such as acme-marketing can map to Marketing Drive, Slack, and brand-asset connectors, while acme-finance maps to Snowflake, enterprise resource planning, and planning systems. The mapping may choose whether access is a centrally provisioned managed grant, permission to establish a personal delegated grant, or both as explicitly separate options.

Discovery itself is sensitive. A user without access should generally not see connector names, tools, schemas, server descriptions, resource names, authentication configuration, or consent endpoints. Direct access remains independently authorized even when the connector is hidden.

Cross-account, cross-cloud, and tenant isolation

A provider service identity and a customer resource may inhabit different trust domains. In the same cloud, native cross-account trust can let the stable service identity assume a customer-owned role. Across clouds, federation first exchanges the home-domain assertion into the customer domain, then impersonates the customer-owned principal. Both yield short-lived credentials; the customer scopes and revokes the principal, while the platform stores only secret-free connection metadata and pinned proof.

Default to one stable service identity per environment in a dedicated identity account, separate from compute, unless a hard isolation requirement demands per-tenant identities. Per-customer isolation belongs in customer-owned role scope plus a tenant-keyed connection record. An external correlation ID or exact subject-and-audience condition binds an assume operation to the intended customer and closes the confused-deputy path. Onboarding validates a linked tenant’s success and an unlinked tenant’s denial before activation; organizational policies that block outside identities are surfaced as prerequisites.

If all OAuth and enterprise-managed state is stored as one connector row, the system cannot prove which principal consented, which administrator owns automation, or which revocation should take effect. Distinct durable records preserve ownership, secret separation, scope, source tenancy, and lifecycle for each authority mode.

Generated-application database: Not created in this slice — managed grants, user consents, enterprise mappings, token exchanges, connection metadata, and evidence are provider control-plane concerns; generated-app identity remains in its own owner store and is referenced only through explicit opaque mappings.

Record or entity	Store and owner	Primary key	Foreign key or opaque reference	Tenant key	Material constraint	Lifecycle and deletion	Use case IDs
ManagedCredentialBinding	Connector Binding Registry, owned by Credential Broker	managed_binding_id	Local FKs to ConnectorInstance and ServicePrincipal; opaque Vault secret reference	organization_id	Principal type must be service; owner team and environment required; scopes/resources may only narrow provider grant; one active version	Provision, validate, activate, rotate, revoke; crypto-shred secret after retention and preserve tombstone and evidence digest	D08-UC-01
UserCredentialBinding	User Binding Registry, owned by Credential Broker	user_binding_id	Local FKs to ConnectorInstance and provider User; opaque Vault reference and provider subject/tenant	organization_id	Unique active binding per connector and user; requested scopes must be subset of granted scopes; never selectable for another subject	Create after consent, refresh, mark reauthorization-required, revoke per user, delete secret on account erasure while retaining audit tombstone	D08-UC-02
ServicePrincipal	Identity Registry, owned by Identity Service	principal_id	Opaque external provider subject; configured_by_user_id is audit-only	organization_id	Durable team owner, environment, and principal type required; creator cannot become runtime subject by fallback	Create before schedule, disable independently, transfer team ownership through approval, delete after bindings and retention expire	D08-UC-01
EnterpriseConnectorMapping	Enterprise Access Policy Store, owned by Enterprise Mapping Service	mapping_revision_id	Opaque IdP tenant and group references; local ConnectorInstance and policy references	organization_id	Signed source tenant must match organization; revision immutable; mapping explicitly distinguishes managed versus delegated eligibility	Draft, simulate discovery, publish, supersede on group change, retain policy digest, delete on enterprise disconnect after audit export	D08-UC-03
TenantConnectionRecord	Connector Registry, owned by Connector Service	tenant_connection_id	Opaque customer-owned principal, database or MCP resource, and per-customer pinned-proof references	organization_id	Unique connector and customer tenant; contains no credential; linked and unlinked negative tests required before active	Insert on onboarding, update idempotently, disable or delete on offboarding while customer independently revokes source principal	D08-UC-01, D08-UC-03
TokenExchangeDecision	Append-only Decision Store, owned by Token Service	token_exchange_decision_id	Opaque run, binding, actor-chain, authorization-server, MCP-resource, and policy references	organization_id	Output audience must equal requested MCP resource; short lifetime and minimum scopes required; token bytes prohibited from storage	Append metadata on issue or denial, retain digest and outcome, expire operational details, preserve audit tombstone	D08-UC-01, D08-UC-02
AccessEvidenceEnvelope	Evidence Store, owned by Evidence Service	evidence_id	Opaque run, decision, trace, source assertion, consent, provider request, and artifact references	organization_id	Actor, resource, scope, precondition, expected, observed, environment, timestamp, and immutable ID fields mandatory; allow and deny pairs linked	Append and seal, retain per audit/legal hold, export to customer, cryptographically erase sensitive payload at expiry, retain non-sensitive tombstone	D08-UC-01, D08-UC-02, D08-UC-03

Review checklist

• [ ] Managed service grant is implemented and proven before optional user delegation.
• [ ] Scheduled sub is the service principal; configured_by never becomes authority.
• [ ] User lookup is keyed to current subject and never falls back to another binding or mode.
• [ ] Platform tokens are never passed through; issued MCP tokens have exact resource audience, short lifetime, actor chain, and minimum scopes.
• [ ] Enterprise group removal hides metadata and denies access, while the mapped-group positive control still works.