The part of the MCP story that keeps me up at night is not the tools, the prompts, or the discovery. It is authentication and authorization, because that is the part where the gap between how it should be done and how it is actually being done right now is widest, and the consequences of getting it wrong are the most severe. We are wiring language models into production systems at a speed that would have been reckless even for human-driven integrations, and a large share of the MCP servers going live are handling identity and access in ways that range from naive to genuinely dangerous. This is the corner of MCP where the industry is writing checks its security posture cannot cash.
Let me describe the gap plainly. Done well, an MCP server sits behind real, modern authorization. It uses OAuth properly. It supports Dynamic Client Registration so that clients can be provisioned and identified without a human pasting secrets into a config file. It uses token exchange so that the agent acts with a token scoped precisely to what it is allowed to do, on behalf of a specific identity, for a bounded purpose — not with a god-mode credential that can do anything the server can do. That is the good version, and the standards to build it have existed for years. Done badly — which is a lot of what is shipping — the MCP server takes a long-lived API key stuffed into an environment variable, hands the agent the full authority of that key, and calls it a day. No scoping, no delegation, no real notion of who the agent is acting as or what it is allowed to touch. Just a bearer of enormous, undifferentiated power sitting one prompt injection away from misuse.
The reason this matters so much more for agents than it did for traditional clients is that the client in the middle is now a probabilistic system that can be talked into things. My friend Mike from Curity gave a talk this year whose title I have not been able to put down — when AI agents start acting, APIs become execution contracts — and that is exactly the shift. When a human held the API key, the authorization model could lean on the human’s judgment as a backstop. When an agent holds it, the judgment backstop is gone and replaced by a model that will do what its context tells it to do, including context an attacker slipped in. So the token the agent carries has to be the control. It has to be narrowly scoped, tied to a real identity, exchangeable for exactly the authority the current task requires and no more. The whole burden of “should this action be allowed” moves from the human onto the authorization layer, and if that layer is a static all-powerful key, there is no layer at all.
I have been making a version of this argument all year in the governance context, that governing what agents are allowed to consume is the actual frontier. Authentication and authorization is where that governance either exists or does not, in the most concrete possible terms. All the careful context engineering in the world does not help if the token behind the tools can do anything the account can do. Scoping the tools an agent sees is the governance conversation; scoping the token those tools act with is the enforcement. You need both, and right now the industry is doing a passable job on the first and a frightening job on the second.
The frustrating thing is that none of this is unsolved. We are not waiting on new standards. Dynamic Client Registration, token exchange, fine-grained scopes, proper OAuth flows — these are mature, they are documented, and the identity vendors who have spent years on exactly this problem know precisely how to do it. The gap is not a knowledge gap. It is a speed-versus-diligence gap, the same one that produced the throwaway API pattern: a static key wired into an env var demos today, and doing authorization correctly takes a few more days that the launch schedule does not want to spend. So the insecure version ships, and it ships a lot, and it is accumulating into a very large attack surface made of agents holding credentials far more powerful than the tasks they perform.
So if you are building an MCP server, treat authentication and authorization as the part you are least allowed to shortcut, not the part you bolt on after the tools are fun. Use OAuth properly. Support Dynamic Client Registration. Use token exchange so the agent acts with a scoped, delegated, purpose-bound token instead of a master key. Make the token, not the model’s good behavior, the thing that enforces what is allowed — because the model’s good behavior is exactly what an attacker will target. The tools are what make MCP interesting. The authorization is what makes it safe to connect to anything that matters, and closing this gap is the difference between MCP being useful infrastructure and MCP being the largest over-privileged-credential problem the industry has ever handed itself.
