An agent can connect to an MCP server. That shows a connection works, and says nothing about which customer's records the agent should read or whether it can change them.

The MCP community's multi-user authorization discussion asks how access should work across users and downstream services, and a just-in-time authorization discussion asks how to obtain additional permission when a tool needs it. Neither requires replacing your team's agent.

Does authenticating to an MCP server authorize every tool call?#

No. Authentication and authorization answer different questions. The MCP authorization specification defines authorization for HTTP-based transports. The application still enforces the permission for the requested operation and resource.

Write down the check for your integration: actor, customer or tenant, tool, target, and allowed operation. A valid bearer token ends the decision only when it establishes access to that target.

An agent allowed to inspect one customer's support ticket is not allowed to export every customer's conversations. Both reach the same server, so the enforcement point must distinguish them before using the downstream credential.

How do I restrict individual tools or their arguments?#

Enforce the restriction where the operation executes. Tool descriptions guide the model but cannot stop a caller attempting a different action. The MCP tools specification covers tool discovery, invocation, and annotations. Annotations do not replace permission checks.

Open discussions cover tool-level scope requirements; implement against the protocol version your client and server share.

Separate permission to use a tool from the allowed target and parameters. "Can update tickets" leaves open which tickets and fields; "can add an internal note to tickets assigned to this support team" is a narrow decision to enforce. Test a direct call with a disallowed target rather than trusting the UI to hide the tool.

Whose identity should a shared MCP server use?#

Keep the requesting actor, agent identity, and downstream credential owner explicit. The multi-user discussion above raises the problem of several end users with different external-service tokens, and a shared server must not select credentials by the most recently connected user.

Resolve the downstream connection from authenticated application state and bind it to the tenant and actor. A model-supplied customer ID is an input to validate and proves nothing about the caller's customer.

A useful diagnostic record has non-secret identifiers for the user, agent, selected connection, target, and decision, so you can explain why a call used a connection without logging the token. For identity work, the Okta connector guide and access investigation workflow keep the target identity precise.

Can I pass the client's access token through to another API?#

No. An MCP access token is not a universal downstream credential. The authorization specification requires audience validation and prohibits accepting tokens issued for another resource and passing them through as though they authorized this server.

Use the downstream service's own authorization flow and credential, and record how the user's permitted operation maps to that credential's capability. If a server uses a broader service credential, the server-side resource check matters more, since the credential's ability to act does not establish the user's right to request the action.

Revocation has three operations: removing a tool from discovery, revoking a user's application access, and revoking a downstream token. Define which stops which calls, then test a previously authorized session after access changes.

How should an agent request additional permission or approval?#

Return the narrow reason the operation cannot proceed. A missing OAuth scope, an unshared resource, and a required approval need different recovery paths, and repeating a denied call gets nowhere.

For application approval, present the exact action: destination, parameters, expected effect, and who can decide. Preserve that action while waiting, and reassess it if its target or meaningful parameters change.

Test these cases:

Case	Expected behavior
Valid identity, wrong tenant	Deny before accessing the downstream resource
Visible tool, prohibited argument	Deny the specific operation
Authorized read	Return only the allowed data
Sensitive write needs approval	Wait with the proposed change visible
Access revoked while waiting	Recheck before execution

Deixic's developer path lets you keep your own agents and route connected calls through company controls. Start with one workflow and inspect its approval and action history. The question: can this agent do this thing to this resource, and can I see why?

Find another symptom in the agent troubleshooting question index.