通过 AI API 网关进行 MCP 连接器治理：OAuth 令牌、工具范围和每用户归因

When an agent calls Gmail, Drive, Stripe, an internal system, or a remote MCP server, the model request is only part of the security event. The real operational question is: who authorized the connector, which OAuth scopes were granted, which tool was invoked, what data left the model provider boundary, and how can access be revoked during an incident?

An AI API gateway that only proxies model calls cannot answer those questions. It may know the tenant, model, API key, prompt size, and cost. It may not know that the model delegated work to a connector operating under a human user's OAuth token. That gap weakens attribution, approval policy, revocation, and audit response.

The practical pattern is to treat MCP connector authorization as a first-class gateway control-plane object. Do not reduce connector governance to an allowlist of tool names. Manage connector enrollment, OAuth token provenance, tool scope classification, approval policy, revocation state, and audit logging as part of the same governance layer that already handles API key management, model access, tenant policy, and usage analytics.

Facts, Recommendations, and Predictions

Facts: OpenAI documents remote MCP as a Responses API tool category and allows applications to provide an OAuth access token for a remote MCP server. OpenAI also identifies hosted service connectors such as Gmail, Google Drive, Google Calendar, Dropbox, and Microsoft Teams. OpenAI's data-control documentation says MCP servers used with the remote MCP server tool are third-party services, and data sent to them is subject to those services' retention policies. Anthropic's connector documentation describes custom connectors using remote MCP servers and notes that users commonly authorize connectors through OAuth, with permissions that can later be revoked. The MCP authorization specification uses OAuth-style authorization for HTTP-based MCP transports. OAuth security guidance in RFC 9700 is relevant to token handling, authorization-code flows, and client security.

Recommendations: A gateway should register connectors before production use, bind each connector call to tenant, key, user, token subject, and server identity, classify tools by read/write risk, enforce approval policy before dispatch, and maintain revocation state centrally.

Predictions: Remote MCP adoption will push AI gateways beyond model routing and token metering. Gateways that cannot see connector identity, OAuth scope, approval decisions, and downstream retention boundaries will be harder to use in regulated, enterprise, and partner-operated environments.

The Governance Problem Is Identity Splitting

Connector calls involve at least three identities, and they should not be merged in logs or policy checks.

• Gateway caller: the API key, service account, workload, or partner application that submitted the model request.
• Delegated user: the human or end user who authorized access to Gmail, Drive, CRM, calendar, payments, internal data, or another protected resource.
• Connector target: the remote MCP server or hosted service connector that receives the tool call and may forward it to another system.

If those identities collapse into one field called user, the audit trail becomes ambiguous. A production service account may submit a request on behalf of 20,000 end users. A single human may authorize several connectors with different scopes. A remote MCP server may expose tools backed by multiple downstream services. The gateway needs separate fields for all three.

A useful event model starts with fields like:

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

This structure lets security, finance, and platform teams answer different questions from the same record. Which tenant invoked the tool? Which application key did it? Which end user delegated access? Which connector received data? Was the action read-only or destructive? Was approval required?

Model Connectors as Gateway Resources

A connector should be enrolled before it is used in production. Enrollment does not need to be slow, but it should produce a durable object that policy can reference.

A minimal connector resource can include:

• tenant_id: the tenant or organization allowed to use the connector.
• connector_id: a stable internal identifier, independent of server display names.
• server_url: the remote MCP server URL or hosted connector identifier.
• owner_user_id: the administrator or user who enrolled it.
• authorization_server: issuer or authorization server metadata where available.
• allowed_tools: reviewed tool names and versions or fingerprints.
• tool_classes: read, write, export, admin, payment, messaging, or unknown.
• approved_scopes: OAuth scopes approved for the connector.
• retention_class: internal, model-provider, third-party standard, or prohibited for sensitive workloads.
• revocation_status: active, user_revoked, tenant_disabled, expired, quarantined, or denied.

This is similar in spirit to a model profile or provider credential record, but connector authorization is not the same object as an upstream model key. Provider runtime credentials let the gateway call model APIs. Connector tokens represent delegated authority into third-party or internal systems. They deserve separate provenance, storage controls, and audit policy.

Broker or Validate OAuth Tokens Deliberately

There are two common implementation patterns.

Gateway-brokered OAuth

In this model, the gateway initiates or coordinates the OAuth flow, stores refresh tokens or access-token material in a vault, mints short-lived connector sessions, and attaches access tokens when dispatching remote MCP calls. This gives the gateway strong control over consent, token lifetime, revocation, and audit joins.

The trade-off is complexity. The gateway must handle consent screens, authorization-code flow security, token refresh, token rotation, encrypted storage, redirect URI management, issuer validation, and tenant-specific OAuth application configuration. RFC 9700 matters here because this pattern puts the gateway close to OAuth client responsibilities.

Application-managed OAuth

In this model, the application obtains the OAuth token and passes it through the model or gateway path when invoking a remote MCP connector. This can be faster to ship because existing products may already have connector authorization flows.

The trade-off is fragmented governance. If the gateway only sees an opaque token, it may not know token subject, scopes, issuer, freshness, revocation status, or consent provenance. A safer version of this pattern requires the application to provide signed connector metadata with each call, and the gateway should validate issuer, audience, expiry, connector enrollment, user binding, and approved scope before dispatch.

For user-data connectors such as email, calendar, storage, CRM, and payments, prefer per-user OAuth tokens. Shared long-lived bearer tokens should be limited to explicit service-account workflows scoped to a tenant and reviewed as higher-risk resources.

Normalize Tool Scopes Before Dispatch

MCP servers can expose tool names and metadata, and some ecosystems provide hints such as read-only annotations. Use those signals, but do not treat server-provided metadata as fully trusted. Tool metadata can be wrong, stale, ambiguous, or adversarial. OWASP's MCP guidance highlights least privilege, allowlisting, authentication, authorization, and monitoring; MCP Top 10 work also calls attention to tool poisoning risks.

A gateway should maintain its own normalized action classes:

• Read: search, list, get, fetch, retrieve, summarize existing content.
• Write: create, update, edit, label, move, comment, schedule.
• Send: email, chat message, webhook, ticket response, notification.
• Delete: remove, purge, archive, revoke.
• Export: bulk download, file transfer, dataset extraction.
• Financial: charge, refund, invoice, payout, subscription change.
• Admin: permission change, user invite, role update, policy edit.
• Unknown: anything not reviewed or not confidently classified.

Then enforce policy on normalized classes instead of raw tool names. For example:

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

This keeps policy stable when a connector renames gmail.search to mail.messages.query. The raw tool still needs review, but the approval system can reason in operational categories.

Run a Pre-Dispatch Connector Check

Before the gateway permits a model-initiated connector call, it should run a compact pre-dispatch decision. This is where AI usage analytics, security policy, approval workflow, and retention policy meet.

A practical sequence is:

1. Resolve tenant and key: identify the gateway key, tenant, workload, environment, and model request.
2. Resolve end user: require a stable end-user ID for delegated connectors. Reject anonymous delegated calls unless explicitly allowed.
3. Resolve connector: match server URL or hosted connector ID to an enrolled connector resource.
4. Validate token: check issuer, audience where applicable, expiry, subject, tenant binding, revocation state, and required scopes.
5. Classify action: map tool name and metadata to read, write, send, delete, export, financial, admin, or unknown.
6. Check retention boundary: determine whether the workload allows third-party MCP server processing and logging.
7. Apply approval policy: auto-allow, require user approval, require admin approval, block, or quarantine.
8. Reserve budget if billable: if connector execution has direct or indirect charges, reserve budget before dispatch.
9. Write the decision: persist the decision before calling the connector, not only after success.

Writing the decision first matters. If the connector times out, streams partial output, or triggers a downstream error, the audit log should still show that the gateway allowed or denied a specific attempted action.

Approval Should Be Workflow-Aware

Per-call approval is simple to reason about and often unusable in practice. A customer-support agent that needs to read a ticket, search Drive, draft an email, and update a CRM record should not force the user through a modal for every harmless read operation. At the same time, sending an email, deleting a file, refunding a payment, or exporting a folder should not be silently delegated because a model selected a tool.

A workable policy is layered:

• Auto-allow reviewed read-only tools for low-risk tenants and fresh user authorization.
• Require approval for send, create, update, delete, export, financial, and admin actions.
• Allow grouped approvals for a named workflow, scope, and time window.
• Require reapproval when scopes expand, tool definitions change materially, or the connector moves to a higher risk class.
• Block unknown tools until reviewed.

Grouped approvals should be explicit. A user may approve: "For the next 30 minutes, allow this support workflow to search Drive and draft replies, but require confirmation before sending." That is more useful than a binary connector allow/deny switch.

Retention Boundaries Need Their Own Field

Remote MCP calls can move data outside the model provider's retention and processing boundary. That is not automatically wrong, but it must be visible. A workload that is allowed to use a model endpoint under one data-retention setting may still be prohibited from sending the same content to a third-party MCP server with different retention terms.

Add retention classification to both workloads and connectors. Example classes:

• internal_only: no third-party connector calls allowed.
• approved_processors_only: connector must be on an approved vendor list.
• third_party_standard_allowed: standard SaaS connector processing is allowed.
• no_argument_logging: connector calls allowed, but arguments must be redacted or hashed.
• export_blocked: read/search allowed, bulk export denied.

This is where the gateway protects teams from a subtle mistake: assuming model-provider data controls automatically apply to every tool the agent uses. They do not necessarily apply once data is sent to a remote MCP server or external service connector.

Build a Connector Audit Ledger

A connector audit ledger should join model requests, gateway authorization, connector dispatch, and downstream results. Do not rely on raw provider traces alone, because each provider may expose tool events differently, and application logs may omit token or approval context.

Recommended ledger fields include:

• model_request_id and trace ID.
• tenant_id, gateway_key_id, workload, environment, and end-user ID.
• connector_id, server URL hash, hosted connector identifier, and risk class.
• tool_name, tool version or metadata fingerprint, and normalized action class.
• OAuth issuer, token subject, scope set hash, expiry bucket, and token provenance.
• Arguments hash, redacted arguments, sensitivity class, and retention class.
• Approval decision, approver, approval scope, and approval expiry.
• Dispatch status, response status, error class, latency, and downstream request IDs where available.

Full argument logging can help incident response, but it also increases privacy and retention risk. Prefer structured fields, hashing, selective redaction, and sensitivity tags by default. Allow full capture only under an explicit incident or debugging policy with expiry.

Revocation and Quarantine Are Product Requirements

Revocation cannot be a manual database edit. Users and administrators need workflows that turn into immediate policy state.

Implement at least these actions:

• User disconnect: revoke or mark inactive all tokens for one user's connector authorization.
• Tenant disable: block one connector for an entire tenant without disabling unrelated model traffic.
• Token expiry handling: fail closed or reauthorize when refresh fails or authorization freshness exceeds policy.
• Connector quarantine: block a connector while preserving its configuration and logs for investigation.
• Emergency denylist: block by server URL hash, connector ID, issuer, or tool fingerprint.
• Scope downgrade: reauthorize with fewer scopes when a workflow no longer needs broad access.

The important implementation detail is that revocation status must be checked at dispatch time. A nightly sync is useful for reconciliation, but it is not sufficient for incident response.

Conformance Probes for Remote MCP Connectors

Before a connector is available to production tenants, test it as a governed dependency. A short probe suite catches many integration and policy failures.

• Metadata discovery returns stable server identity and expected tool definitions.
• Protected-resource metadata and authorization behavior match documented assumptions where applicable.
• Dynamic client registration requirements are understood, supported, or explicitly disabled.
• Requests without tokens fail safely.
• Expired tokens fail predictably and do not trigger uncontrolled retries.
• Read/write classification matches observed behavior, not only descriptions.
• Malformed tool metadata is rejected or marked unknown.
• Tool list changes trigger review when names, scopes, descriptions, or risk classes change.
• Connector errors are logged without leaking sensitive arguments into generic error fields.

These probes are not a replacement for security review, but they give the gateway a repeatable way to detect drift. Remote MCP servers can change independently of the model provider and independently of your application release cycle.

Implementation Checklist

• Create a connector registry with tenant, server, authorization, scope, tool, risk, retention, and revocation fields.
• Separate gateway key identity, delegated end-user identity, and connector identity in every policy decision.
• Store connector tokens in a credential vault, but keep them distinct from model-provider runtime credentials.
• Prefer per-user OAuth for user-data connectors; limit shared service tokens to explicit service-account workflows.
• Normalize tool actions into read, write, send, delete, export, financial, admin, and unknown.
• Run pre-dispatch checks for connector enrollment, token validity, scope match, retention compatibility, approval state, and budget reservation.
• Log connector decisions before dispatch and settle final status after response or error.
• Build user disconnect, tenant disable, connector quarantine, and emergency denylist workflows.
• Probe connector metadata, token behavior, tool drift, and malformed metadata before production use.

Actionable Conclusion

MCP and service connectors make agents useful because they let models act on real systems. That same usefulness turns connector authorization into a control-plane concern, not a prompt-engineering detail.

The gateway should know more than the model, token count, and API key. It should know which connector was called, which user authorized it, which scopes were granted, which tool action class was requested, whether approval was required, whether the retention boundary was compatible, and how access can be revoked. Start with a connector registry, a pre-dispatch policy check, and a joined audit ledger. Then add OAuth brokerage, grouped approvals, conformance probes, and emergency quarantine as connector usage grows.

The goal is not to block remote MCP adoption. The goal is to make connector access attributable, revocable, reviewable, and compatible with the same governance expectations teams already apply to model access and an OpenAI-compatible API gateway.

Related reading

• broader agent tool governance patterns