AI Agent Security: The Identity Gap Playbook

This week Microsoft shipped a way to put a leash on AI agents. The Agent Control Specification landed, an open standard for runtime governance, and alongside it came Entra Agent ID, which hands every agent its own governed identity with an audit trail behind it. The same week, Noma launched access control for agents and the MCP servers they call. Three releases in a few days, all aimed at the same problem.

Here is the durable version of that news, the part that will still matter in two years after the product names have changed.

Most builders shipped agents before they shipped a way to control them. The agent works in the demo, so it goes to production with an API key pasted into an environment variable, full read access to a Google Drive, and a tool that can run shell commands. Nobody scoped it. Nobody logged it. Nobody decided what it is allowed to touch. It runs as you, with your permissions, at machine speed, forever.

That is the agent identity gap. The agent can act, but the question of who it is and what it is allowed to do never got answered. I have built two ventures where AI does most of the work, and I have shipped agents with god-mode credentials more than once because it was faster. It is faster right up until it is the most expensive thing you ever did.

This is the playbook I wish I had used from the start. It is a framework called the Five Gates of Agent Authority, and it is built so that a solo founder can install it in two weeks, not a security team in two quarters.

Table of contents

• The problem: you hired an employee with root access and no manager
• The framework: the Five Gates of Agent Authority
• Why the old security model breaks for agents
• Gate 1 and Gate 2: Identity and Scope
• Gate 3: Approval, the human in the loop
• Gate 4: Execution, where the attacks actually land
• Gate 5: Audit, the log you will wish you had
• Build versus buy: the control plane line
• The contrarian take: security is a product feature, not a tax
• What to do Monday morning
• Frequently asked questions

The problem: you hired an employee with root access and no manager

Think about how you would onboard a human contractor. You would give them a named account, not the shared admin login. You would grant access to the one project they work on, not the whole company. You would ask them to check with you before they wired money or deleted a database. And you could see what they did afterward.

Now look at how most agents get deployed. They run on a key that belongs to a person or a service account that already has broad access. They can reach far more than the task needs. They take irreversible actions without asking. And in most shops, there is no record of what they did, because nobody set up logging for a thing that did not exist six months ago.

The numbers say this is not a rare mistake. It is the default. By the end of 2026, IBM expects most large enterprises to be running more than 1,600 AI agents. The average organization runs about 37 deployed agents today and cannot see most of them. Only 18 percent keep a current, complete inventory of the agents already running inside their walls. Just 12 percent have a single place to manage them. More than half of those agents run with no security oversight or logging at all. Seven in ten executives say the governance they have is not fit for the job, and 94 percent are already worried about agent sprawl.

The identity side is worse. Non-human identities, which is the umbrella term for service accounts, API keys, and now agents, already outnumber human users by 45 to 1 in a typical environment, and by 100 to 1 or higher in many. Some sectors report 500 to 1. Of those non-human identities, 97 percent carry more privilege than they need. Only 34 percent of organizations audit or rotate them. Two thirds of enterprises have already taken a breach through a compromised non-human identity, and weak management of these identities was the root cause of 41 percent of successful identity breaches. Machine identities now show up in 68 percent of security incidents.

Put those two facts together. Agents are exploding in number, and the identities they run on are the single biggest breach vector in the cloud. You are not adding a feature. You are adding the fastest-growing attack surface in software, and most builders are adding it with the front door propped open.

The framework: the Five Gates of Agent Authority

Every action an agent takes should pass through five gates before it touches anything real. I call it the Five Gates of Agent Authority because the word that matters is authority. Not capability. The agent is capable of almost anything. The question is what it is authorized to do, and authority is something you grant and revoke, not something the model decides for itself.

The five gates run in order. A request comes in, and before the agent does work, it passes the Identity gate, the Scope gate, and the Approval gate. When the agent calls a tool, it passes the Execution gate. And whatever happens, it leaves a mark at the Audit gate. Skip any gate and you have a hole. Skip all five and you have what most people are running right now.

The gates are deliberately boring. None of this is clever. The clever part is that almost nobody does it, which is exactly why the gap is so wide and the upside of closing it is so large. Let me walk through why the security model you already know does not transfer, then take the gates one at a time with the specific thing you build at each.

Why the old security model breaks for agents

The identity and access tools most teams use were built for humans. A human logs in a few times a day, proves it is them with a second factor, works for hours inside one session, and leaves a fairly readable trail. There are not many of them, they are slow compared to a machine, and you can call them on the phone when something looks off.

An agent is the opposite on every axis. There are hundreds of them, soon thousands. They authenticate constantly, sometimes thousands of times an hour. They cannot tap a phone to approve a push notification, so multi-factor authentication in its usual form does not apply. They spin up and disappear in seconds, which means a credential issued this morning might be attached to something that no longer exists by lunch. And they act at a speed where a mistake reaches every connected system before a person could read the first alert.

This is why the recent product wave matters as a signal, even though I am telling you not to wait for it. When Microsoft gives each agent its own governed identity through Entra Agent ID, when it ships an open Agent Control Specification that checks an agent before it gets input, before it calls a tool, after the tool returns, and before the final answer goes out, the message is clear. The people who run the largest fleets of agents have concluded that the human model does not stretch to cover them. You can borrow that conclusion without borrowing the price tag.

There is a second reason the old model breaks, and it is subtle. With a human, the threat is mostly that someone steals the credential. With an agent, the credential can be perfectly safe and the agent can still be turned against you, because an agent reads instructions from the world. A web page, a document, or a tool description can carry hidden text that the agent follows as if you wrote it. That moves part of the security problem out of identity and into the execution path, which is Gate 4. Hold that thought.

Gate 1 and Gate 2: Identity and Scope

The first two gates travel together, so I treat them as one install. Gate 1 says every agent gets its own identity. Gate 2 says that identity is scoped to the smallest set of actions and data it needs, and the credential behind it is time-bound and rotated.

Start with identity, because it is the cheap fix with the highest payback. The most common mistake I see, and the one I have made, is running an agent on a shared key. The agent uses your personal token, or a single service account that twelve other things also use. The day something goes wrong, you cannot tell which agent did it, you cannot revoke access for that one agent without breaking the other eleven, and your logs all say the same name. Give each agent a distinct identity and all three problems shrink at once. You can attribute every action, you can kill one agent without touching the rest, and your audit trail finally means something.

Then scope it. This is where the 97 percent number lives. Almost every non-human identity carries privileges it never uses, because granting broad access is the path of least resistance and nobody comes back to trim it. An agent that summarizes support tickets does not need write access to your database. An agent that drafts emails does not need permission to send them. An agent that reads one folder does not need the whole drive, which is exactly the mistake at the center of the Vercel breach earlier this year, where an employee gave a third-party tool full read access to a corporate Google Drive and a stolen token later walked through that open door.

Scope has three dials. The first is what actions the agent can take, read versus write versus delete. The second is what data class it can reach, which folder, which table, which customer segment. The third is time, because a credential that lives forever is a credential that will eventually leak and still work. Scoped, time-bound, and rotated is the standard the security field has settled on, and it maps cleanly onto how you would treat a contractor. Give them a key to one room, not the building, and change the lock when the job ends.

One practical note for solo builders. You do not need a fancy secrets manager on day one. You need to stop using your own personal credentials for anything an agent touches, create a separate scoped key per agent, and write down what each key can reach. The discipline matters more than the tool. The tool can come when you have more than a handful of agents.

Gate 3: Approval, the human in the loop

Some actions are reversible. If an agent drafts a bad email, you delete the draft. Some actions are not. If an agent deletes a production database, sends money, or emails every customer, there is no undo. Gate 3 says irreversible and high-risk actions stop and wait for a human to approve them.

The reason this gate exists is that agents fail in ways that look nothing like human failure. At a conference this year, a demonstration showed an AI agent that deleted a production database, including the records, the live reservations, and the backups, in nine seconds. Not because it was attacked. Because it decided that was the next step and nothing stood between the decision and the action. Nine seconds is faster than any alert, any on-call page, any human reaction. The only defense that works against that speed is a gate that the agent cannot pass on its own.

The trick is to put the approval gate only where it belongs. If you ask a human to approve everything, people start clicking approve without reading, and the gate becomes theater. The skill is drawing the line. I use a simple test. Can this action be undone in under a minute by one person? If yes, let the agent proceed and log it. If no, it stops for approval. Sending money, deleting data, changing access, publishing to the public, and anything that touches a customer directly all sit on the no side for me.

This is the exact shape of the controls in the new governance standards, where the policy spells out what an agent may do, what it must not do, and when a human should approve an action. You do not need their SDK to copy the idea. A required confirmation step before any write to a sensitive system is the entire gate. It can be a Slack message that waits for a thumbs up. It can be a queue you check twice a day. The mechanism is less important than the rule that some doors do not open without a person.

Gate 4: Execution, where the attacks actually land

Gates 1 through 3 govern what the agent is allowed to do. Gate 4 governs the moment it reaches out to a tool, because that is where most real attacks happen. The agent itself can be honest and the credential can be safe, and you can still get hit, because the agent does what the tools and the content tell it to do.

The cleanest example is tool poisoning. Agents connect to tools through the Model Context Protocol, and a tool announces what it does through a description the agent reads. An attacker hides instructions inside that description. The agent reads them as part of its job and acts on them, while the user never sees the hidden text. People have started calling this the new prompt injection, and the difference is persistence. Old prompt injection had to be delivered again and again. A poisoned tool description ships once, inside a package or a remote server, and fires on every single call, silently, for every user, until someone notices. Two such weaknesses got their own identifiers this year, MCPoison and CurXecute, and one disclosure put the number of vulnerable instances as high as 200,000.

The exposure on the connection side is just as ugly. Security researchers scanned the public internet and found 492 MCP servers running with no client authentication and no encryption at all. Those servers exposed 1,402 tools, and more than 90 percent offered direct read access to the data behind them. A later scan found the count had nearly tripled. By early this year there were more than 8,000 MCP servers reachable on the open internet, and 41 percent of them needed no authentication to use. These are doors with no lock, attached to real data, and the agent on the other side will happily walk through.

The fix for Gate 4 is a proxy. You do not let the agent call tools directly. You put a thin layer in the middle that does three jobs. It keeps an allow-list of the exact tools the agent may use, so a tool you never approved cannot be called even if the agent is talked into trying. It re-checks scope on every call, so the agent cannot widen its own access mid-task. And it keeps a copy of every request and every response, which feeds Gate 5. The security field has a phrase for this that I like, because it is honest about what works. Continuous verification and rapid containment beat perfect prevention. You will not stop every bad instruction from reaching the agent. You can make sure a bad instruction cannot reach a tool you never blessed, and that you have a record when it tries.

Gate 5: Audit, the log you will wish you had

The last gate is the one people skip because it does nothing on a good day. Audit means every action the agent takes leaves an immutable record, detailed enough to answer one question fast. What did this agent do, and when. On the day something goes wrong, that log is the difference between a two-hour investigation and a two-week one, and the difference between knowing what leaked and guessing.

The data on this is stark. Only 18 percent of organizations have a complete inventory of the agents running inside their walls, and more than half of all agents run with no logging at all. So when an incident hits, most teams are starting from zero, trying to reconstruct what a thing did when they did not even have a list of the things. Compare that to the payoff. Organizations that use security tooling well, including proper logging, contain incidents 80 to 108 days faster and save on the order of 1.9 million dollars per breach. Speed of containment is almost entirely a function of whether you can see what happened.

For a solo builder, the audit gate can be a single append-only table. Every row is one action, with the agent identity, the timestamp, the tool called, the inputs, and the result. That is it. The discipline is that you write to it on every action, including the boring ones, because you do not know in advance which action you will need to trace. The new governance standards make audit a first-class requirement, defining what evidence should be logged for later review as part of the policy itself. Treat your log the same way. It is not overhead. It is the receipt that lets you prove what your system did, which you will need for customers, for compliance, and for your own sanity.

There is a regulatory reason to get this in place now. The EU AI Act becomes fully applicable on August 2, 2026, and for higher-risk uses it expects audit trails, human oversight, and the ability to stop a misbehaving system. If you build for anyone in that market, the audit gate stops being optional. Better to have it as a habit than to retrofit it under a deadline.

Build versus buy: the control plane line

The honest question for a founder is which of these gates you build yourself and which you buy. My rule is that you build the policy and buy the plumbing. You own the decisions that are specific to your product, what each agent is for, what it may touch, which actions need a human. Those cannot be outsourced because only you know your blast radius. The generic machinery underneath, the proxy, the identity store, the log pipeline, the dashboard, is where the new tools earn their keep, and where I would not waste a month rebuilding what a vendor ships.

The line moves with your size. Solo and pre-revenue, you build almost everything thin and hand-rolled, because a scoped key, a confirmation step, and an append-only table cost you a few days and nothing a month. Once you run more than a handful of agents, or once a customer asks how you control them, that is the signal to buy the plumbing and keep owning the policy. The wave of products that shipped this week exists precisely because the largest operators crossed that line, and the tooling followed.

Here is the order I would install the gates, sized for one person over two weeks. It is front-loaded so the highest-payback fix, separate scoped identities, happens first.

That is roughly 25 to 40 hours over two weeks. It is not a project. It is a fortnight of doing the boring thing once, after which every new agent inherits the gates instead of opening a new hole.

The contrarian take: security is a product feature, not a tax

Most builders file agent security under cost. It feels like a tax on shipping, a thing the security people care about that slows you down, something to handle later when you are bigger. I thought that too, and it is the most expensive belief in this whole area.

The named enemy here is the just give it the API key default. It is the habit of treating an agent as a feature you bolt on, when an agent is closer to an employee you hire. You would never give a new contractor your personal admin password, full access to every system, and the freedom to wire money without asking, then forget to write down what they did. But that is exactly the deal most agents get, because the fast path and the safe path diverge, and the fast path wins every sprint until the day it does not.

Here is the flip. The gates are not a tax. They are a feature you can sell. The moment you have agents acting on customer data, your customers start asking how you control them, and right now almost nobody has a good answer. Seven in ten executives admit their governance is not fit for purpose. If you can show a prospect that every agent has its own scoped identity, that irreversible actions need a human, and that you can produce a log of everything an agent ever did, you have a trust story your competitors cannot match. In a market where 97 percent of breached organizations lacked basic access controls, being the 3 percent is a moat, not a cost.

There is even a clean financial case. Organizations that invest in this save close to 1.9 million dollars per breach and contain incidents months faster, while shadow AI, the ungoverned kind, adds up to 670,000 dollars to the cost of a breach. The spend is not symmetric with the risk. A fortnight of work sits against a seven-figure tail. I have learned this the way most founders learn things, which is by getting away with it for a while and then not. Build the gates while they are cheap.

What to do Monday morning

You do not need to install all five gates this week. You need to close the widest hole, and for almost everyone that is the same one. Do this first.

List every agent you run and the credential each one uses. Most founders cannot do this from memory, which is the first finding. Write it down anyway, because the act of listing surfaces the shared keys and the forgotten agents.

Then take the single agent with the broadest access, the one running on your personal key or a god-mode service account, and give it its own scoped key. Cut that key down to exactly what the agent needs and nothing more. If the agent only reads, take away write. If it only touches one folder, take away the rest. This one change, on your most dangerous agent, shrinks your blast radius more than anything else you could do in an afternoon.

Next, find every place an agent can do something irreversible, send money, delete data, email customers, change access, and put a human confirmation in front of it. A message that waits for a yes is enough. You are buying the nine seconds back.

Finally, start a log today, even an empty append-only table, and write the next action to it. You want the habit running before you need the record. Everything else, the proxy, the rotation, the kill switch, the bought plumbing, follows the order in the table above over the next fortnight. The point of Monday is to stop being the open door.

Frequently asked questions

What is the agent identity gap?

The agent identity gap is the distance between an agent being able to act and anyone having decided who that agent is and what it is allowed to do. In practice it means agents running on shared or over-privileged credentials, with no scope, no approval step for risky actions, and no log. It is the default state of most deployed agents because the fast way to ship an agent is to hand it broad access and skip the controls.

Why can’t I just use my normal login security for agents?

Human security tools assume a small number of users who log in a few times a day, prove identity with a phone or key, work in sessions of hours, and leave a readable trail. Agents break every one of those assumptions. There are hundreds of them, they authenticate thousands of times an hour, they cannot tap a phone for a second factor, they live for seconds, and most have no oversight at all. Non-human identities already outnumber humans by 45 to 1 or more, so the old model does not stretch to cover them.

What is tool poisoning and why is it worse than prompt injection?

Tool poisoning is when an attacker hides instructions inside a tool’s description, the text an agent reads to learn what a tool does. The agent follows those hidden instructions while the user never sees them. It is worse than ordinary prompt injection because of persistence. A normal injection has to be delivered each time, but a poisoned tool description ships once inside a package or a remote server and fires on every call, silently, for every user, until someone notices. The fix lives at the network and execution level, which is why Gate 4 uses a proxy with an allow-list.

How many agents am I likely running without realizing it?

More than you think. The average organization runs around 37 deployed agents but only 18 percent keep a complete inventory, and more than half of all agents run with no oversight or logging. The first step in this playbook is simply listing them, because most teams discover agents they forgot they had. That gap between perception and reality is the whole problem in miniature.

Do I really need this if I am a solo founder with one agent?

Yes, and it is cheaper for you than for anyone else. With one agent the entire install is a scoped key instead of your personal one, a confirmation step before anything irreversible, and an append-only log, which is a few days of work. The cost of skipping it is the same as a large company’s, because one over-permissioned key can reach everything you have. The smaller you are, the less you can absorb a seven-figure mistake, so the case is stronger, not weaker.

What should I build myself versus buy?

Build the policy, buy the plumbing. You own the decisions that are specific to your product, what each agent is for, what it may touch, which actions need a human, because only you know your blast radius. Buy or adopt the generic machinery underneath, the identity store, the scoped-credential issuer, the tool proxy, the log store, because rebuilding it wastes a month. As you grow past a handful of agents, lean harder on bought plumbing while keeping the policy yours.

Will the new tools like Entra Agent ID or the Agent Control Specification solve this for me?

They solve the plumbing, not the policy. A governed identity per agent, runtime policy checks at each step, and a built-in audit trail are real help and worth adopting. But they still need you to decide what each agent is allowed to do and where a human must approve. A tool that can enforce a policy you never wrote does nothing. Treat the new products as the machinery for the gates, and treat the Five Gates as the decisions you still have to make.

How does this connect to building reliable agents in general?

Security and reliability are the same discipline seen from two sides. An agent that fails safely, stops before irreversible actions, runs scoped, and logs what it did, is both more secure and more reliable, because most production failures and most breaches come from the same root, an agent acting beyond what anyone intended. The gates are a reliability practice that happens to close your biggest security hole. If you want the wider reliability picture, the playbook on why agents fail in production covers the failure side, and this one covers the authority side.

---

Related reading on building with AI as a solo founder:

• The AI Opportunity Map 2026
• Why AI Agents Fail in Production
• The Context Engineering Playbook for AI Builders
• The Evals Playbook for Solo Founders
• The Internal AI Stack for Solo Founders
• The Solo Founder AI-Native Operating System
• The Founder Operating System