API keys: the access nobody is governing

Every API key is a standing grant of access to your data, packed into a string anyone can copy. Most never expire, and nobody tracks where they end up. Now that employees are wiring keys into AI agents and local MCP servers, those places are multiplying fast.

‍

If that sounds like the OAuth problem, it is. API keys raise the same questions about scoping, permissions, delegation, and lifecycle. The difference is that OAuth comes with infrastructure to manage them. Nudge Security data shows the average employee creates 88 OAuth grants, and each one at least leaves a trail. That infrastructure is imperfect (anyone who's tried to inventory OAuth grants across an enterprise knows it), but it beats what API keys offer, which is nothing.

‍

Think about what an API key is: long-lasting, delegated access to your data, represented by a secret string. Most platforms don't expire them by default. You can't see where they live or who has touched them. Once issued, a key exists wherever it's been pasted, for as long as it stays valid, doing whatever the issuing platform allows.

‍

The propagation method is copy and paste

The way an API key moves from one system to another is that a human opens two browser tabs. Want to hook a GitHub key into your secrets infrastructure in AWS? Open the AWS console, open the GitHub console, copy from one, and paste into the other. That's the entire protocol.

‍

It's a legacy method. Modern protocols like OAuth provide real lifecycle management and a trust relationship between the parties. But nearly every application still offers API key access, for a simple reason: the activation energy for the user is close to zero. Paste in a secret string and the integration works. Compare that to the two-way handshake OAuth requires, with client secrets to manage and flows to implement, and you can see why API keys refuse to die.

‍

That convenience is the problem. What's easy for the user is just as easy for an attacker.

‍

You have almost no options for managing them

When you try to manage API keys across an enterprise, you run into a wall. Most applications don't show you which keys have been issued, let alone where they went afterward. A few platforms do this well. GitHub, notably, lets organizations see the fine-grained tokens that have been issued and scope what each one can do and what data it can touch. Most platforms offer nothing close to that granularity. A key is a key, and it can do whatever the account can do.

‍

So what does API key governance look like in practice today? It looks like hoping your employees tell you when they configure a key and where they put it. That's the control: best effort. And it doesn't scale, because the people creating these keys are trying to get an integration working, not maintain an inventory.

‍

Reuse is easier than issuance, so reuse is what happens

There's a second-order problem that shows up in almost every incident we dig into: it's simpler to reuse a key you already have than to generate a new one. Generating a new key means going back to the issuing platform, creating it, scoping it if the platform even supports scoping, and getting it into the right place to store it. Reusing an existing key means pasting a string you already have.

‍

So we see production keys reused in testing infrastructure. We see one key shared across three integrations because it was sitting right there. Every reuse widens the blast radius of that one secret, and nobody is tracking any of it.

‍

A few platforms are closing this gap by expiring keys by default. At Nudge Security, any API key that goes unused for a rolling three-week window expires automatically. Forgotten keys just stop working instead of sitting around as access nobody remembers granting. It's a small design choice that removes a whole category of risk, and more platforms should make it.

‍

The vault isn't where the problem is anymore

There are good companies providing secret vaults and key rotation for production infrastructure, and if you have that problem, you should use them. But the frontier has moved. The bigger challenge today isn't how secrets are managed inside your production environment. It's how they spread into local MCP connections, into agents wired across your SaaS applications, and into the growing layer of AI tooling that runs on pasted credentials.

‍

That layer sits at the Workforce Edge: the everyday decisions employees make about which tools to connect and how. Your vault doesn't see it. Your CASB doesn't see it. Neither does the platform that issued the key. An employee pastes a key into an MCP config or an agent integration, and from that moment you have durable, delegated access to your data with no inventory, no owner, and no expiration.

‍

What you can do now

You can shrink the problem today without new tooling:

• Inventory the keys you know about. Start with platforms that let you list issued keys, like GitHub, and record an owner for each one.
• Turn on expiration and scoping wherever a platform supports them.
• Keep production keys out of test environments. Issue separate keys per environment and integration, even when reuse is easier.
• Set a policy for AI tools. Decide whether employees can paste keys into MCP configs and agent integrations, and tell them which keys are off-limits.
• Revoke keys nobody claims.

Each of these steps depends on knowing where your keys already are. That's the hard part.

‍

What we built at Nudge

This is why we built API key propagation detection into Nudge. Because keys move through the browser, Nudge can detect when one is copied from one platform and pasted into another. You see when it happened, who moved it, and where it went.

‍

That turns one of the least visible kinds of access in your environment into something you can act on. You don't have to block the workflow or make employees fill out a form every time they connect an integration. You watch the propagation path instead.

‍

API keys aren't going away. They're too easy to use, and too many tools depend on them. But hard to govern doesn't have to mean invisible. Once you can see where your keys go, you can manage them like the standing access they are.

‍

Start a free trial to see where API keys are moving in your environment.