Your MCP Server Doesn’t Know Which Laptop Is Calling

MCP has made it remarkably easy to connect AI tools to the systems your teams use every day: CRMs, wikis, code repos, ticketing systems and internal data. Install a connector, paste a token, and the agent is in.

That’s also the problem. Most MCP connections run on long-lived API keys and OAuth tokens sitting on a laptop. They prove the request has a credential. They don’t prove which device it came from, or whether that device is one you trust.

A token can be copied. A device can’t.

This December, we put that idea to the test. We ran a holiday puzzle hunt where the only way into our MCP server was a hardware-attested device identity, and players had to figure out how to catch an impostor trying to get in with a copied key. In this webinar, we’ll share what happened and what it means for securing MCP at work.

We’ll cover:

• Why API keys and OAuth tokens on a laptop are the weakest link in most MCP setups
• How an MCP gateway can require device identity, user identity and policy on every tool call
• Replacing long-lived tokens with short-lived, brokered credentials the agent never holds
• What the holiday project showed us about forged identities, copied keys and how they get caught
• What to ask before your teams connect the next AI tool to company data

We’ll also walk through a live demo showing how Smallstep’s MCP gateway uses hardware-bound device identity to verify every connection, so only trusted devices can put AI tools to work on your data.