Nine seconds. That’s how long it took an ungoverned AI agent to find an over-scoped token and wipe a production database.
This was how Tyk’s Mark Gurvis opened our recent LEAP on Tour event in Chicago. What followed wasn’t a polite Q&A. The room split into working sessions, insurance next to consumer goods next to applied AI and banking. Fourteen people from twelve companies, from the C-suite to the teams building it, came at MCP governance from different angles and found they were circling the same problems. Then pressed each other on them.
When everyone came back together, we worked through what each table had landed on. Four questions had surfaced across every session, so we’ve written them up ready for you to share with your team.
1. How do you actually track both the human’s identity and the AI agent’s identity on the same call?
Imagine two users – let’s call them Alice and Bob – both logging in through Keycloak. Alice has read-only access to customer records. Bob’s entitlements include refunds. When either of them triggers an agent to act, the original login token, which carries a broad set of entitlements, never gets forwarded downstream. At the gateway, it gets exchanged for a new token scoped to exactly what that one action needs, reducing the blast radius to a single call.
Two claims matter here:
- sub, the subject, which is the human and stays identical across every hop no matter how many services the request touches.
- azp, the authorized party, which is whichever agent or app is currently holding the token and changes at every exchange.
aud and scope get reset the same way, narrowed down to one backend and one permitted action each time.
So, when Alice’s agent tries a refund, it gets rejected; her scope never included it. When Bob’s agent tries the same thing, it succeeds, scoped specifically to that single refund call. You always know who asked and what’s currently acting on their behalf, at every step.
We closed the LEAP on Tour Chicago event by putting exactly this scenario on screen and running it live.
2. Is securing MCP actually different from securing any other API?
Mostly no. The principles don’t change: Authenticate, authorize, scope tightly, log everything.
What does change is the blast radius. An agent can chain several tool calls on its own, in sequence, without a human approving each one. So the same API security discipline still applies, it just has to run at every hop instead of once at the front door – because the thing making the second and third call isn’t a person checking their own judgment anymore.
3. What happens when multiple teams’ agents compete for the same rate-limited tool?
This one came up at nearly every table, usually with the assumption that nothing could be done about it yet. But there is a solution, and it ties straight back to the previous question. Rate limiting is ordinary practice on APIs, but here it has to operate one level down, on the primitives themselves (tools, resources, and prompts), rather than on the MCP server as a whole.
That is what per-consumer, per-primitive rate limiting and quotas are for. You can cap how much of a shared tool any one team’s agents can consume. That means one team’s automation can’t starve another team’s access.
What we don’t decide for you is the policy at the moment a limit is hit. Whether that request queues, fails outright, or escalates to a human is a call your organization makes based on what the tool actually does. We’re extending the same model to LLM token and cost management too.
4. Could your organization actually produce a full list of every MCP server it touches today?
For most in the room, the honest answer was no. A few people pointed out that Claude or Copilot’s own admin console already gives them a list, and that’s a fair partial answer. It certainly covers what’s registered inside that one client.
But this list stops there. It won’t show you a headless agent calling a server directly with no chat client involved. It won’t reconcile across every vendor your teams use. And it’s not an audit trail anyone outside that console can check.
That’s the same blind spot API sprawl led to a few years ago, and it deserves the same fix: One living registry tied to your existing developer portal, naming what each server does and who owns it, that both your people and your agents check before a call is ever made.
Where this leaves us
As we’ve just shown, all four of these pressing questions already have an answer today. Some of that answer is product-related, while some of it needs people and processes alongside the technology.
The question that barely came up in Chicago is the one we raised ourselves, and it is where this gets hard. A token is a pass made out to one specific door. The moment one agent hands work to another agent, and that one hands it on again, the pass no longer matches the door in front of it and the service on the other side refuses to open. Identity providers are strict about this by design, Keycloak and Entra among them, and there’s no setting that waves it through. That’s the next boundary, and it’s the conversation we most want to have at the rest of our LEAP on Tour events.
The sharpest version of all these conversations happens in the room. Our next two stops are New York (nearly at capacity) on October 21 and Dallas on November 4. Book your seat now and bring your hardest questions.
