MCP is easy in a demo. In production, every tool call needs a name behind it

Model Context Protocol demos tend to show how easily an agent picks up a new tool: point it at a server, and the tool appears. Enterprises face the opposite question. Who is calling this tool, on whose authority, and how is each call checked? Two announcements from the past week answer it from different sides.

AWS: the tool sits behind organizational identity

On October 2, AWS solutions architect Jishnu Dasgupta published a reference architecture for adding web search to Claude Desktop through Amazon Bedrock AgentCore Gateway. The point of the design is what the desktop does not hold: no search API key on the user’s machine.

The chain runs like this. A user signs in through AWS IAM Identity Center, the organization’s single sign-on. Amazon Cognito federates that identity and issues a JWT through an OAuth 2.0 authorization code flow. AgentCore Gateway validates the token on every request and exposes the managed Web Search tool as an MCP-compatible endpoint over streamable HTTP. Claude Desktop discovers the tool with a standard MCP tools/list call and uses it when it needs current information. AWS says query traffic stays inside AWS infrastructure.

Two limits to note. This is a tutorial architecture, not a statement that every MCP deployment needs this exact stack. And the managed web search capability is currently offered in US East (N. Virginia), Europe (Ireland) and Asia Pacific (Tokyo); it needs an AWS Organizations management account to set up Identity Center.

Ping: the agent borrows the user’s authority

On September 29, Ping Identity launched three identity agents for Gemini Enterprise, available on Google Cloud Marketplace and built with Google’s Agent Development Kit. Employees can manage their authentication devices in conversation; help desk and identity administrators can handle users, sessions, access and MFA enrollment.

The design detail that matters: Ping says the device management agent follows a least-privilege model, holds no standing credentials and cannot act without direction from the authenticated user. Actions run through Ping’s APIs within the authority assigned to the person, and administrative changes in Advanced Identity Cloud require explicit confirmation. CEO Andre Durand framed it as keeping “every action tied to the authority of the person behind it.”

Five identities in every tool call

Put the two together and a production MCP call involves more identities than a demo admits:

• the person who asked for the work;
• the agent that decided to call the tool;
• the credential the tool call carries, ideally short-lived and scoped to this call;
• the tool or server identity, which the gateway trusts;
• the accountable owner of the agent and of the tool.

1. User signs in with corporate SSO
2. Token issued for this user and client
3. Agent requests tool via MCP
4. Gateway validates token and policy
5. Tool runs within the user's authority
6. Call logged with user, agent and tool

• Who: User signs in with corporate SSO · Token issued for this user and client
• What: Agent requests tool via MCP
• Enforced and recorded: Gateway validates token and policy · Tool runs within the user's authority · Call logged with user, agent and tool

Human identityAgent intent

What enterprise teams should take from it

Stop distributing static API keys to agents. A key on a laptop or in an agent config is a credential with no user attached. Put tools behind a gateway that accepts tokens tied to a signed-in person or an agent identity.

Decide when the agent acts as the user and when it acts as itself. Delegated authority (the Ping model) is right when the action belongs to the user. An agent identity with its own narrow rights is right for background work. Mixing them, for example an agent with a user’s full rights running unattended, is where incidents start. We traced that distinction in our analysis of agent identity as its own IAM discipline.

Make the gateway the enforcement point. Token validation, tool allowlists and per-tool policy belong in one place that logs every call. That is the role we described for the AI gateway as a policy enforcement point.

Map it onto the identity provider you already run. In a Microsoft estate the same questions are answered with Entra ID as the identity provider and a gateway such as Azure API Management in front of MCP servers. The AWS post does not cover that setup, and the configuration differs, but the audit questions are identical. A SOC 2 auditor reviewing logical access will ask the same thing of an MCP tool that they ask of any system: who had access, who approved it, and where is the log.

Remember why this is urgent. Microsoft’s new threat report, which we covered in our analysis of agents and identity hygiene, lists agent identity, authentication between agents and revocation among the questions security teams now own.

What to do now

1. Inventory MCP servers and tools in use, including the ones developers connected on their own, and the credentials each uses.
2. Remove static keys from desktops and agent configs; replace them with gateway-validated tokens.
3. Classify each tool: acts as the user, or acts as the agent. Write it down.
4. Require SSO for every human-triggered tool call, and log user, agent and tool together.
5. Add confirmation steps for administrative or irreversible actions, as Ping does for identity changes.
6. Check where the tool runs and where its traffic goes before you enable it for regulated data.

The bottom line

MCP solved how agents find tools. It did not solve who is allowed to use them. The enterprises that get MCP into production will be the ones that treat every tool call as an authenticated, authorized and logged request, with a person or a named agent behind it.