MCP security: secure configuration, identity and gateway authorization

The protocol is not the core problem; the risk comes from how teams wire it up. MCP standardises how an agent reaches tools and data, which is exactly why weaknesses around it scale: broad tokens, long-lived keys and tools that run with more access than the task needs are suddenly reachable through one uniform interface. In other words, MCP does not create new categories of vulnerability so much as it makes existing authorization and identity mistakes easy to commit everywhere at once. That also points to the fix. You do not make MCP safe by abandoning the standard — you make it safe with disciplined authorization: scoped, short-lived credentials, a policy decision in front of sensitive actions, and an owner and audit trail for every machine identity. Treat the protocol as plumbing and put your security effort into who is allowed to do what through it.

A non-human identity (NHI) is the digital identity of a machine actor — an agent, a service or a workload — rather than a person. Where a human logs in with a username and password, an agent authenticates with an API key, a token or a certificate, and that credential is its identity on your systems. The reason this matters is that most identity governance was built for people, around the joiner-mover-leaver lifecycle, and agents fit none of those stages while still being able to read databases or send mail. Treating NHIs as first-class identities — each with a named owner, a defined scope, a rotation schedule and an audit trail — is the heart of agent access control. Organisations that skip this end up with thousands of credentials that nobody owns and nobody can confidently revoke, which is precisely the blast radius an attacker inherits.

Start with an inventory, because you cannot govern identities you have never listed. Enumerate every MCP server, every agent, and the credentials each one holds, then flag the ones that are long-lived, broadly scoped or owned by no one — those are your immediate risk. From that list, the first concrete moves are to kill or rotate the worst static keys, scope each remaining credential to least privilege, and put a runtime authorization check in front of genuinely sensitive actions. This sequence matters: discovery first, because most organisations underestimate how many machine identities they already have, and containment second, because a scoped credential limits the damage of every future compromise. Inventory is unglamorous, but it is the control that makes all the others possible, and it almost always surfaces a few forgotten keys that should have been revoked months ago.

A long-lived API key is a standing, often broadly scoped credential that does not expire on its own, and for agents that combination is the single most common weakness. The problem is duration multiplied by reach: the key works indefinitely, so a copy leaked in a log, through a prompt injection or via a compromised dependency stays valid long after the incident, and it usually carries far more access than any one task needs. Because the same key is frequently shared across tools, a single leak compromises everything it touches at once. The fix is to replace static keys with short-lived, automatically rotated tokens scoped to a specific identity and action, so that even a stolen credential expires quickly and reaches little. Pair that with per-identity audit logging, so a leaked token can be traced and revoked rather than quietly used for weeks. Short and narrow beats long and broad every time.