Why Humans and Agents Must Be Governed Together: The Spare Key Problem

Where Are Your House Keys?

If you really stop to think about it, do you know everyone who has a key to your home?

You probably have one with you right now, and so does anyone you live with. Maybe a neighbor has one in case of emergencies while you're away, and the property manager (if you rent) definitely has one in case they need to let maintenance in. You gave one to the dog walker, but a few months back they moved and you never actually got your key back. Have you given one to a friend who was visiting from out of town for the week? What about outside services that the property manager or someone else gave one to for a repair? Did all those keys make it back to who controlled them when they weren't needed anymore?

What happens when you come home and something is just... off?

Maybe it's a light that you're pretty sure was off when you left, or a door ajar that you're almost certain you closed. It could be nothing, but if you try to work through a list of every person that could have been there, you hit a wall. The locks are intact, no windows are broken, but that doesn't mean someone wasn't there. Too many people have valid keys, and over time, through the busy day to day, no one was keeping track of exactly who had them, whether they still needed them, or if those people even knew where theirs were anymore.

The reality is that your locks are just fine, but they can't do their job anymore because the governance broke down.

Maybe this isn't playing out at your home. Maybe you have an exact list of how many keys to your place exist and exactly where they are. But right now, this same scenario is playing out, inside every enterprise in the world. Instead of house keys, it's OAuth tokens, API credentials, and service accounts. The "property" is your entire SaaS estate, and the maintenance person who needed a week of access is an AI agent that someone in sales spun up three weeks ago.

The Keys Are Multiplying

AI agents are the new key holders, and they're accumulating keys fast, with some organizations reporting as many as 20:1 NHIs to humans.

A marketer connects ChatGPT to Salesforce through an OAuth consent grant, and just like that, it has CRM access. A developer gives Claude Code access to Slack through MCP, and now it can read channel history across the organization. A platform team provisions a GCP service account for an internal automation bot. An ops team plugs an agent into Jira, Confluence, and Datadog simultaneously.

Each of these agents receives a valid key. Each key shows up in a different admin console. There is no central registry. No master key ring hanging by the front door with neat little labels.

Beyond having no central registry, in every enterprise we've analyzed, 95% or more of non-human identities have no assigned owner. No one who's accountable, no one who receives a notification when something changes, no one whose job it is to decide if a key is still needed. And that should keep security leadership up at night.

The industry is taking notice. Cisco's planned acquisition of Astrix sends a clear signal that this gap is real. But recognition alone doesn't solve the problem. It matters how you close it.

This isn't a future problem. AI agents are accessing your systems today. Once again, the identity surface area is expanding exponentially, and once again, that responsibility is falling to the same team that was already stretched thin. The burden of managing hundreds of thousands of human permission combinations across hundreds of apps was already overwhelming teams. As AI agents enter the mix, you won't be able to recruit your way out of an exponential problem with a linear team.

The Wrong Instinct: Build a Better Lock

Whenever a new identity category emerges, the industry has the same reflex: build new authentication infrastructure. New protocols. New identity layers. More locks, better locks, smarter locks.

But the spare key problem was never about the lock.

Authentication tells you the key is real: yes, this is a valid OAuth token. Authorization tells you it fits the door: yes, this token has Contacts.ReadWrite scope. Neither answers the questions that actually matter. Who handed out this key? Why? Do they still need it? What happens when they don't?

Consider what security researcher Johann Rehberger demonstrated with Devin, an autonomous AI software engineer. He showed how Devin could be manipulated into exfiltrating sensitive data through its own legitimate tools: rendering secrets into images, piping data through shell commands, even using its built-in browser to send information to external servers. No permission boundary was crossed. The agent used the same tools it was authorized to use, in ways its operators never intended. The intent boundary was shattered while every auth check passed cleanly.

This is the class of problem that better locks can't solve. You can build the most sophisticated deadbolt in the world, but if someone is using their valid key to enter your house and rearrange the furniture, the deadbolt isn't your issue.

The Lock Already Changed. We Didn't Notice.

Interestingly, we solved this problem a long time ago in the physical world.

Offices don’t hand you a metal key when you join the company anymore, they give you a badge that logs every door you open, expires when your employment ends, and can be deactivated remotely if something goes wrong. Hotels don't leave a key under the mat, they give you a card that stops working at checkout. Your phone doesn't need a key at all, it just needs to know it's you.

The physical world moved from keys, to key cards, to identity. The "thing you carry" gradually gave way to "who you are." Each step made access smarter: easier to track, easier to revoke, harder to copy, and fundamentally tied to the person, not the object.

Digital identity is still stuck in the spare key era. OAuth tokens, API credentials, and service accounts are essentially metal keys: copyable objects floating around with no intelligence behind them. The lock checks "is this key valid?" and opens the door. It doesn't ask who's holding it, whether they should still have it, or if what they're doing makes any sense.

The early response to the non-human identity problem is repeating an old pattern: build a separate system for a new category. Now we have standalone NHI tools, managed by different teams, disconnected from the human identities that authorized them. If the lesson of the physical world is that access converges on identity, fragmenting governance into silos is moving in the wrong direction.

The real shift isn't building a better key or even a better lock. It's recognizing that the key is dissolving into identity itself. What matters now is how you govern that identity: who it belongs to, what it's supposed to do, and whether its behavior matches its purpose. The locks will get smarter over time, but they can only be as smart as the governance system feeding them context. Without that layer, a smarter lock is still just checking tokens in a vacuum.

And this is where another identity layer, by itself, falls short. Adding a new protocol or a new standard for agent authentication is necessary work. But it's only one piece. If all you've done is give the agent a fancier key, you've upgraded the lock without addressing the pile of spare copies that no one is tracking.

What Governance Actually Looks Like

If governance is the system that makes smart locks possible, what does it actually need to do? For AI agents and non-human identities, it comes down to three things.

Intent must travel with the credential. When you hand someone a key, you write down why. "The cleaning crew needs access on Tuesdays and Thursdays." That stated purpose becomes the baseline for evaluating whether the key is being used correctly. When an agent is granted Salesforce access to "update deal stages from pipeline meetings," that intent should be recorded and linked to the credential. Without it, you have no way to evaluate whether what's happening is what was supposed to happen.

The best version of this looks like agents requesting access through a governed channel, the same way a contractor should go through a property manager to get a key, not just copy one from the lockbox. When access is requested, scoped, and approved with intent attached upfront, you've built guardrails into the system before the key is ever cut.

This is also where AI changes the game for governance itself. Historically, encoding intent into a governance system meant writing rigid rules: if-then logic that was brittle, expensive to maintain, and never quite captured the nuance. "This service account should only be used for weekly pipeline syncs" wasn't something you could express as a policy without a bunch of custom logic. Today, AI can reason over natural language. That statement becomes a piece of knowledge, applied to that credential during every future assessment, not a rule someone has to hard-code and hope doesn't break.

Remember the Devin example? A governance system that tracks intent would have flagged that behavior immediately. Not because the permissions were wrong, but because rendering secrets into images and piping them to external servers doesn't match "help the team write code." When you know what a credential is supposed to do, you can spot when it's doing something else entirely.

Every credential must have an owner. Ownership isn't a field in a spreadsheet. It's a workflow, and it's as critical to governance as the approval that granted access in the first place. When an owner is assigned, they inherit accountability: they receive review requests, get notified on lifecycle events, and are on the hook when something needs to change. Without that workflow, security findings sit in backlogs indefinitely. You've found a risky key, but who's supposed to collect it?

This is especially urgent for non-human identities. A human account has a natural owner: the human. An agent or service principal doesn't. Someone authorized it, but that person may have changed roles, left the company, or simply forgotten. Every agent they authorized, every sub-agent those agents spawned, every downstream connection in the chain, all of it needs to trace back to a human who's accountable. An unowned key is an ungoverned key. And right now, almost all of them are unowned.

This is also why non-human and human identities can't be governed in isolation. Every agent traces back to a person or team that authorized it. When that team shifts priorities, people change roles, or someone leaves the company, every agent they owned is silently orphaned. A governance system that only sees one side of that relationship will never catch it. You need the full chain in one place: the humans, the agents they own, and the permissions those agents carry.

Access must expire unless someone actively renews it. This requires more than a quarterly audit where someone rubber-stamps a spreadsheet. But let's be honest about where things stand: not every system gives you rich activity logs. Some apps tell you the last time a credential was used. Others tell you nothing at all. That's the reality of a fragmented SaaS landscape.

Even coarse signals are powerful, though. A credential that hasn't authenticated in 90 days is a strong candidate for revocation. You don't need to know exactly what it was doing to know it's not doing anything. The person who authorized it left the company? Orphaned key, needs a new owner or immediate revocation. The agent was granted scopes it has never once exercised? Candidate for scope reduction. Start with what you can see. The goal isn't omniscience. It's making sure keys don't accumulate silently without anyone checking.

One Door? Fine. 10,000 Doors? Big Problem.

The spare key problem is manageable when you're dealing with one property. A little annoying, sure, but you can knock on a few doors, change the locks, sort it out over a weekend.

Now imagine you're responsible for 10,000 doors across 200 buildings. That alone would be bad enough, but the doors also have keys that copy themselves. Agents granting sub-agents access, delegation chains three and four layers deep, each link with its own auth mechanism and its own risk profile. A user who authorized "a code assistant" ends up with an agent chain that can read infrastructure secrets, modify production configs, and post to Slack, and no single dashboard shows the composite picture.

You can't hire enough people to check every lock. The math doesn't work. You need a system that tracks every key, knows who owns it, understands why it was issued, and can act when something doesn't add up. Eventually, you'll need agents helping govern agents, the same way you need software to manage software at scale.

The spare key problem doesn't get solved by building a better key for each new category of identity. It gets solved when you can see every key, who it belongs to, why it was issued, and whether it's still needed, human and non-human, in one place.

When you take a step back, this should be obvious. Every non-human identity traces back to a human or a team. Ownership is the mechanism that makes governance work, and ownership is inseparable from your employee identities. Managing them in disconnected systems means managing ownership disconnected from the people who are actually accountable. That's not a tooling gap, it's a structural blind spot.

That's what we're building at Lumos, which I invite you to try for yourself. But regardless of what tools you use, the question is the same: how many spare keys are floating around your systems right now? And when you find them, can you actually trace them back to the person responsible?