Summary: A platform team can authenticate an MCP client and still lack a check on the operation the agent proposes. The MCP authorization specification dated June 18, 2025 defines authorization for restricted HTTP transports. APort's MCP integration example addresses another boundary: a supported runtime checking which server and tool an agent may invoke.
OAuth and OAP can serve the same workflow without being interchangeable. OAuth-based access and server-side permissions remain necessary where deployed. An OAP passport and policy decision add value when a connected action needs constraints that those existing controls do not already enforce.
Trace one proposed export
Consider an agent that can search an internal document service through MCP. The client obtains access to the service under its transport authorization flow. The service should still check the caller's resources and permissions when it receives a request.
Now suppose the agent proposes an export tool. A runtime hook can reject the server or tool before dispatch if it is outside the passport's scope. If export is permitted, the system still needs to validate the dataset, tenant and destination. A server/tool allowlist alone does not establish those argument-level checks.
This is a design example, not a claim that every APort MCP adapter automatically understands every export tool. Map the parameters into an appropriate policy, enforce them in the server, or remove the tool from the agent's scope.
Assign each check an owner
| Check | Owner in the integration | Evidence to inspect |
|---|---|---|
| Access to restricted HTTP MCP service | Authorization server, client and MCP resource server | Token validation and server-side permission checks |
| Agent's declared capabilities and limits | Passport owner and policy configuration | Scope reviewed for the intended task |
| Proposed call before dispatch | Connected runtime hook or gateway | Allow/deny result for the actual server, tool and supported context |
| Resource and argument restrictions | Service or mapped action policy | A forbidden target rejected with no side effect |
| What actually executed | Runtime and downstream service | Execution record joined to the policy decision |
A prompt that says an action is approved is not an authorization-server response. Likewise, a tool description does not grant the caller permission. Use trusted identity and configuration as the authority for access decisions.
Do not lose the deny during rollout
The OAP enforcement contract retains binary allow even when an operator chooses warn mode. Report-only may continue a denied call; an API outage is a different condition again. Record all three separately so an audit does not mistake a successful workflow for an allowed action.
A signature on a hosted decision supports checking its integrity. It does not prove that a remote MCP server honored the restriction or that the runtime never used a different path. Test the complete path with a harmless tool and observe the server-side result.
Walk an export through three denials
A useful acceptance fixture has a test document service and two synthetic projects. Give the client valid transport access to project A. Configure the agent for the service's search tool, then propose its export tool. The runtime policy should reject export before dispatch if export is outside the declared tool scope.
Next, explicitly permit export in a disposable configuration and ask for project B. This time the service's resource authorization should reject the call even though the transport connection and tool name are valid. Finally, request an export of project A to a forbidden destination; the owner of destination validation must reject it.
Use a control request that successfully exports the permitted fixture to the permitted test destination. Without that control, a broken service could make every negative test appear to pass. Record server-side invocation and effect logs, keeping sensitive content out of the policy context.
A failure in any one test identifies a particular owner: transport access, tool dispatch, resource permissions or destination policy. It does not justify turning OAuth off or treating an OAP allow as unrestricted server authority. For local transports, review the host's process and credential configuration as well; the cited HTTP authorization flow does not describe every local process boundary.
Make the transport and tool tests separate
First prove that an unauthorized client cannot access the restricted service. Then, with a valid connection, propose a tool outside the agent's scope and verify that dispatch stops. Finally, propose a forbidden resource through an allowed tool and identify which control rejects it.
The local MCP walkthrough tests the middle case without contacting a server. Keep it as a starting fixture, then repeat through your actual host and transport.
Create my passport with explicit server and tool scope for that workflow before connecting broader capabilities.
Turn the MCP design into an enterprise pilot
Choose a service owner and one permitted business task. Inventory the MCP server, allowed tools and resource permissions for the pilot cohort. Have the server owner approve resource checks while the runtime owner validates pre-dispatch authorization; the existing transport identity controls remain in place.
Review an allowed task, an out-of-scope tool and a forbidden resource separately. Keep missing telemetry and warn-mode continuation visible in the pilot report. Team is the self-service path for shared hosted decisions and organization audit; Enterprise planning addresses a wider tool inventory, policy ownership and rollout schedule.
Product and implementation sources
Choose your rollout path
Team uses organization billing and Stripe Checkout. Enterprise starts with a rollout call to agree the deployment scope.
Install my guardrail