Pm AI MCP To Authorization

PM AI MCP to Authorization

Use this skill when an AI product may connect to an MCP server, remote tool, agent connector, or asynchronous MCP Task and a PM must decide what a host, client, authorization server, resource server, tool, or task store may access.

The output is a product and release contract. It is not an OAuth client, MCP implementation, connector registry, secret manager, or security certification. Keep a human owner on consent, scope, consequential actions, and the final release decision.

When to use

Use it when:

• a team is adding an MCP server, remote tool, connector, or agent integration;
• a host needs to discover an authorization server or protected resource;
• a tool request may expose data, change a record, send a message, spend money, or change permissions;
• the product supports per-tool consent, delegated access, re-authentication, revocation, or managed authorization;
• a long-running MCP Task returns a task ID, status, result, or cancellation operation that must be bound to the requester;
• an OAuth callback succeeded but nobody has documented audience, issuer, scope, tenant, expiry, or downstream token handling;
• the team needs a hold, fallback, or pilot decision without live credentials.

Do not use

Do not use this skill to:

• implement OAuth, PKCE, an MCP client/server, an authorization server, or a token store;
• approve a tool, expand a scope, exchange a code, refresh a token, or revoke access;
• treat a discovered metadata document, successful callback, or HTTP 200 as proof that every tool or task operation is authorized;
• design ordinary in-session progress; use pm-ai-task-to-progress;
• define generic actor identity and delegation; use pm-ai-identity-to-boundary;
• define a generic tool schema and side effect contract; use pm-ai-tool-to-contract;
• supervise a run that continues after the user leaves; use pm-ai-background-run-to-supervision;
• paste tokens, authorization codes, cookies, customer data, private URLs, or sensitive screen content into the contract or public receipt.

Use Unknown, Not provided, Not run, Not measured, Not reproduced, or Not covered when a host, protocol version, provider, or permission result is missing.

Workflow

1. Frame the authorization decision

Write one sentence:

Decide whether actor ... may use resource ... through host ..., transport ..., scope ..., and tool/task boundary ..., with consent, expiry, revocation, and fallback ....

Record the user job, requester, owner, current workaround, protected resource, tenant or workspace, data class, tool side effects, duration, user timezone, and what remains the user's decision. A successful login is not consent for every downstream tool or task.

2. Map roles and authority

Name each role and its evidence:

Do not collapse authentication, authorization, consent, delegation, and tool execution into one connected state.

3. Identify transport and discovery

Record protocol revision, transport, canonical resource URI, issuer, metadata locations, redirect URI, client metadata or registration route, and supported scopes. For HTTP authorization, check resource and authorization-server metadata, WWW-Authenticate, issuer, resource indicator, audience, and token transport. For STDIO or another local transport, record the host's credential source and local permission boundary instead of copying HTTP OAuth rules.

If the source or host version is unclear, keep the decision at Hold and write the missing evidence. Do not infer the latest protocol from a package name.

4. Define consent, scope, and tool action boundaries

For each requested permission, record:

Separate server-level connection from per-tool authorization when a host can support it. A read-only source fetch does not authorize a message send, record write, purchase, deletion, or permission change.

5. Verify token and authorization lifecycle

Do not record a token value. Record whether the host has evidence for:

• exact issuer and authorization-server selection;
• canonical resource and audience binding;
• issuer validation and no authorization-server mix-up;
• redirect exactness, HTTPS or localhost boundary, and PKCE where applicable;
• scope minimization, consent freshness, and scope-change re-consent;
• expiry, refresh, rotation, revocation, and secure storage;
• no token in URL, logs, prompt content, task result, or upstream passthrough;
• distinct 401, 403, invalid scope, expired, revoked, and rate-limit behavior.

If a server calls another API, require a separate downstream credential boundary. A received token must not silently become a credential for a different audience.

6. Bind tasks and results to authorization context

If asynchronous tasks exist, define ownership for tasks/get, tasks/result, tasks/cancel, and tasks/list. The contract must answer:

• Is a task ID bound to the same user, tenant, client, and authorization context that created it?
• Does a requester receive only its own task metadata and result?
• Are task IDs high entropy, rate-limited, and subject to a documented TTL?
• What happens when authorization expires or is revoked while a task runs?
• Does cancellation require the same authorization context and explicit user control?
• What is the fallback when the host cannot identify the requester?

If context binding is unavailable, say so, shorten the exposure window where the host supports it, do not expose a list capability, and keep the release at Hold until the risk is accepted by the owner.

7. Model user-visible states and recovery

Use these states as needed:

not_configured, discovering, needs_consent, authorized, denied, expired, revoked, reauth_required, mismatch, rate_limited, and unknown.

For each state, specify the user control, data/tool visibility, next action, and evidence. Keep wrong issuer, wrong audience, invalid redirect, invalid scope, task not found, cross-context denial, and server error separate.

• First-time: explain resource, data, tool, tenant, duration, and side effects.
• Empty/loading: name missing metadata or discovery phase; show no fake percentage or connection success.
• Error: preserve status and reason; do not retry with broader permission.
• Recovery: re-check issuer, resource, scope, and context before re-auth.
• Backtracking: allow deny, revoke, scope reduction, manual fallback, and deletion of the local proposal; do not claim server revocation unverified.
• Mobile/accessibility: keep consent keyboard reachable, readable at narrow widths, and explicit about what remains denied.

8. Evaluate and decide

Use positive, negative, cross-context, privacy, and recovery cases. At minimum cover:

Choose Proceed, Pilot, Hold, Fallback, or Stop. A passing schema or authorization callback is not proof of tenant isolation, user comprehension, or safe tool behavior.

9. Write a privacy-safe receipt

Record package/version, host/client, source versions, transport, resource, issuer class, scope class, consent state, token/task checks, decision, limitations, and next action. Exclude raw tokens, codes, cookies, customer content, private URLs, and sensitive screen data.

Output contract

Return the sections below in this order:

1. ## Decision and user job - decision, user, workaround, desired outcome, and what remains human-owned.
2. ## Sources and freshness - source URL or ID, protocol/host version, date, relevant claim, and source limitation.
3. ## Authority and resource map - roles, tenant/workspace, transport, canonical resource, issuer, client, gateway, tool, and task store.
4. ## Consent and action boundary - data, purpose, scope, tool side effect, duration, allowed/denied actions, inspect, deny, revoke, and fallback.
5. ## Authorization lifecycle - discovery, redirect, issuer, audience, scope, token, expiry, rotation, revocation, error, and re-auth evidence.
6. ## Task and result isolation - task ownership, context binding, list/get/ result/cancel rules, TTL, rate limit, and cross-context negative cases.
7. ## UX states and recovery - first-time, empty, loading, consent, error, mismatch, expiry, revocation, mobile, accessibility, and manual route.
8. ## Evaluation and release gate - cases, oracles, observed results, Not run / Not covered, decision, rollout, fallback, and rollback.
9. ## Privacy-safe receipt - sanitized YAML or table with no secrets.
10. ## Not covered - concrete unknowns, unexecuted flows, and claims not supported by current evidence.

Common rationalizations to reject

• "The callback succeeded, so every tool is authorized." Separate consent, scope, tool action, and result access.
• "The task ID is secret enough." Bind it to authorization context and test get, result, cancel, and list paths.
• "The MCP server validates the token." Verify the intended resource, issuer, audience, scope, and downstream credential boundary.
• "It is only a read tool." Verify data egress, tenant scope, prompt/resource visibility, and whether the tool can trigger a hidden side effect.
• "We can reuse the token upstream." Deny token passthrough; require a separately issued downstream credential or a documented safe boundary.
• "No one will see the error." Keep denial, expiry, revocation, re-auth, and manual fallback visible to the user.
• "The latest spec covers us." Record the exact protocol and host versions; compatibility and security still require an actual host oracle.

Edge cases

• A public tool and a protected tool share one MCP endpoint.
• The issuer changes, the authorization server redirects, or the resource URI has a different path than the one shown to the user.
• A scope is added after the first consent, or a tool description changes.
• Authorization expires while a background task is queued, running, or ready.
• A task result is fetched from a different tenant, user, client, or region.
• The client loses the authorization context but still has a task ID.
• A gateway caches tool metadata or routes requests by method and tool name.
• A server response contains an instruction-shaped request to reveal a token, widen scope, or call another tool.
• The user denies one tool but accepts another, or revokes access mid-flow.
• The host cannot provide a reliable requester identity or audit trail.

Adjacent routing

• Use pm-ai-identity-to-boundary for generic principal, delegation, and authorization ownership outside MCP protocol details.
• Use pm-ai-tool-to-contract for tool schema, provenance, side effects, and recovery without the authorization lifecycle.
• Use pm-ai-prompt-injection-to-defense for a full attack path and negative evaluation around untrusted instructions.
• Use pm-ai-background-run-to-supervision for runs that continue after the current interaction and need pause, cancel, expiry, notification, or review.
• Use pm-ai-task-to-progress for ordinary task lifecycle and honest progress when cross-context authorization is not the central decision.
• Use pm-ai-data-to-purpose for data minimization, retention, deletion, and third-party reuse policy across an AI data flow.

Final check

Before returning the contract, confirm:

• source and protocol version are recorded;
• authentication, authorization, consent, scope, tool action, and task access are separate concepts;
• the resource URI, issuer, audience, tenant, and requester context are named;
• HTTP and STDIO or other transport behavior is not conflated;
• per-tool side effects and denied routes are visible;
• task get/result/cancel/list isolation is tested or marked Not run;
• 401, 403, mismatch, expiry, revocation, rate limit, and recovery states are explicit;
• no token, code, cookie, customer data, private URL, or secret appears;
• unknown host behavior is Unknown, Not covered, or Hold, never invented;
• the final decision and next action are owned by a human.