You Can't Contain an Agent You Haven't Found: Treating AI Agents as Insiders, Starting With the Inventory

The views expressed are my own and do not represent those of my employer.

Picture a CISO in a Monday leadership meeting. The CFO asks a simple question: how many AI agents are running inside the company, and who is responsible for them? The CISO has a dashboard for endpoints, a register for third parties, and a count of privileged human accounts. For this question she has nothing. She says she will get back to them, and everyone in the room understands what that answer means.

That moment is arriving at a lot of organizations right now. On October 19, 2026, Hayete Gallot, Executive Vice President of Microsoft Security, published a post called "Securing the agentic insider" on the Official Microsoft Blog. Her opening observation is one every security leader should sit with. Most of us have worried about threat actors using powerful models to attack us. We have paid less attention to the agents inside our own walls, and because we deployed them ourselves, we implicitly trusted them.

One independent write up from WindowsForum calls the post a vision statement rather than a product spec, and that is a fair read. I am not using it as a product pitch. I am using it for the premise, which I think is correct, and because it points to a first step that costs almost nothing: find every agent, identify it, and put a human name next to it. This is Part 1 of a four part series on securing the agentic insider, and it covers the work that has to happen before anything else.

Nobody Has to Be Malicious for This to Hurt

Insider risk programs were built around people. We screen them, give them access based on role, watch for unusual behavior, and pull their access when they leave. Underneath all of it sits an assumption that trust is conditional and has to be earned.

Agents break that assumption quietly. Gallot's argument is that no attacker is required. According to coverage of her post, models are optimized to attain results rather than to follow organizational norms, which is the root of reward hacking: the system finds a path to the goal that nobody intended. Agents also adapt as context changes and may not behave as designed. As ANI reported her words, they can collaborate and collude with other agents, "without needing to be compromised."

Think about what that does to your threat model. Our usual question is who got in. The agentic insider question is different: what is already inside, what can it reach, and what will it do when its goal and our policy disagree?

"It's our agent" is a statement about who signed the purchase order. It is not a trust decision.

We do not hand a new hire domain admin because we ran a background check. We scope access, assign a manager, and review it. Agents deserve at least the same treatment, and most of them are getting less, because nobody has written them down.

What the Numbers Say, and What They Do Not

Here is the data point everyone will be quoting this month, so let me handle it carefully. Trellix released a survey of 600 CISOs on October 13, 2026, run by the research firm Vanson Bourne. It found that 95% of respondents had an AI agent or autonomous system linked to an insider incident in the past 12 months, and that 78% now count AI agents and machine identities as part of insider risk.

This is vendor research, and Trellix sells security products. Help Net Security pointed out that the 95% counts any linked incident, so it says nothing about how many were serious. Treat it as one data point, not proof that the problem is universal.

The more useful numbers are underneath. Among the 587 companies that reported an insider incident, Help Net Security's summary says accidental or careless actions by employees and trusted users made up 43% of incidents on average, deliberate abuse by those same people made up 29%, and AI or autonomous systems made up 28%. Most of the damage is still human. But more than a quarter is a share you plan for. The same survey found that 63% of CISOs lack sufficient visibility into how employees use AI tools.

Credential practice tells a similar story. A Cloud Security Alliance research note from May 2026 cites the CSA Agentic Identity Survey from 2025: 44% of organizations rely on static API keys for agent authentication, and 35% use shared service accounts. Those are credential models built for human scale operations, and they make it nearly impossible to say which actor did what.

You do not need a survey to know whether you have this problem. You need to try to answer the CFO's question. If you cannot, you have your answer.

Use the Anatomy as Your Search Warrant

The most practical thing in the Microsoft post is a simple description of what an agent is. In the post's words, an agent brings together a model, a harness that orchestrates its work, an action space of tools and resources, and a runtime in which it executes. I find that useful as a discovery checklist, because each layer is a place to look and each leaves different evidence behind.

Model. Which foundation models and providers is the agent calling? Include the quiet ones. Vendors are embedding agents inside products you already own, and the model call happens on their side of the contract. Your question for each business application is whether it now acts on its own.

Harness. This is the orchestration layer: agent frameworks, agent builders, low code automation platforms, SaaS copilots, and coding agents. Business teams build agents here without filing a ticket, because the tooling is designed to make that easy. If you have only looked at what engineering built, you have looked at a fraction of this layer.

Action space. This is where the risk lives. List the tools the agent can call, the MCP and API connections it holds, the OAuth grants it received, the service accounts it runs under, and the data stores it can read or write. An agent with a clever model and no access is a toy. An agent with a mediocre model and a broad OAuth grant is an incident waiting for a trigger.

Runtime. Where does it actually execute? It could be a SaaS tenant, a cloud workload, an employee endpoint, a browser session, or a CI/CD pipeline. The runtime determines what telemetry you can get and what you can shut off.

An agent you can describe in four layers is an agent you can find in four places.

I covered what to do in the first hour after something unapproved happens, in my playbook for when a coding agent does something nobody approved. This post is about the step before that one. You cannot run a playbook against an agent you do not know exists.

Where the Evidence Hides

No single tool finds everything, so you triangulate. These are the sources I would start with, and each one maps back to a layer of the anatomy.

Network egress to AI provider domains. Your proxy or DNS logs show which internal systems are talking to model providers. A server that calls an AI API every few seconds at 3 a.m. is not a person typing into a chat window.

OAuth and app consent logs. Agents get their reach through grants. Review which third party apps hold access to your mail, files, code repositories, and ticketing systems, and who approved each one. This is often the fastest way to find the action space.

Secrets and service account scans. Search code repositories, pipelines and configuration stores for model provider keys and for service accounts with names nobody recognizes. Zenity's CISO guidance on coding agents makes a good point here: a real inventory needs active scanning of developer endpoints, repository configurations and MCP server registries, not just a review of what IT formally provisioned.

SaaS admin consoles. Most major platforms now have an agent or copilot section in the admin center. Open each one. Count what is there. You will likely find agents built by people who left the company.

Employee self reporting. Technical telemetry finds what is connected. People tell you what it is for. You need both, and I will explain how to get honest answers in the 30 day plan below.

If your concern is unsanctioned tools in general, I wrote about that in Shadow AI: What New CISOs Need to Do Before It Bites Them. Here the target is narrower and more serious: software that takes actions with access you granted, whether or not you approved the tool.

Four Attributes and One Row Per Agent

Discovery gets you a list. A list is not an inventory until every entry carries the same minimum set of facts. Here is the record I would require for every agent.

A unique identity. The agent has its own identity, not a developer's personal token and not a shared service account. The Five Eyes guidance, "Careful Adoption of Agentic AI Services," published May 1, 2026 by CISA, NSA and their counterparts in Australia, Canada, New Zealand and the UK, tells organizations to treat each agent as a distinct principal. The Cloud Security Alliance's analysis of it notes that it also calls for a trusted registry reconciled against the live set of agents. That reconciliation is exactly what we are building toward.

A named human owner. A person, not a team alias. Propelcode's inventory guide suggests two forms of ownership: a business owner accountable for purpose and the decision to keep the agent running, and a technical owner responsible for access, monitoring and safe retirement. I like that split because it answers who approves a change and who can pull the plug.

A stated purpose. One sentence on what the agent is supposed to do. If the owner cannot write it, that is a finding in itself.

An applicable policy. Which rules govern this agent: data handling, allowed tools, whether it may act or only recommend. An agent with no policy attached is running on assumptions.

Add two more fields as soon as you can: a risk tier and a retirement condition. One CISO guide recommends exactly this combination, with a human owner, business purpose, risk tier and retirement condition for every agent. The retirement condition matters more than it sounds. Agents outlive projects. A sunset trigger, such as the owner leaving or a review date passing without renewal, keeps your registry from becoming a graveyard of live credentials.

Here is the template in text. One row per agent. Columns for agent name, owner, technical owner, stated purpose, model and provider, harness or platform, tools and connections, credential type, data classification reached, runtime location, policy reference, risk tier, last review date and retirement condition. Build it in a spreadsheet this week. You can move it into a real platform later, and by then you will know exactly what you need the platform to do.

Two conditions go to the front of your remediation queue: an agent with no owner, and an agent running on a shared or borrowed human credential. The second one is the worst of both worlds. Every action looks like a person did it, and nobody can say which person.

The identity side of this is bigger than a registry, and I went deeper on it in IAM for AI Agents: Why Your Identity Program Isn't Ready. For this post, you only need to get the record started.

Thirty Days to a First Pass Inventory

I am going to be honest about scope. Thirty days gets you a first pass inventory and a registration gate. It does not get you control. That is what Parts 2 through 4 are for. But a first pass is far better than a quarter spent planning the perfect one.

Week 1: Sponsor, schema, scope. Get an executive sponsor, ideally someone from the business side whose teams are likely running agents. Agree the record schema above and decide what counts as an agent. My working definition: anything that can take an action in a system without a human approving each step. Writing that down early prevents a month of arguments.

Weeks 1 and 2: Run a no blame amnesty. Technical discovery will miss things, and people will hide what they fear you will shut down. A CISO governance guide published on guptadeepak.com suggests a no blame amnesty: agents disclosed during the first 30 days face no punitive action, and agents found afterward are treated as policy violations. The guide says this produces more complete inventories than adversarial discovery. That matches my instinct. Announce it plainly, from the sponsor, and mean it.

Weeks 2 and 3: Reconcile what people say against what the logs show. Compare the self reports to your egress data, consent logs, scans and admin consoles. The gaps are your most valuable output. An agent in the logs but not in the reports needs a conversation. An agent in the reports but not in the logs may be running somewhere you are not looking yet.

Week 3: Triage. Escalate any agent that touches privileged access, regulated data, or irreversible actions such as deleting records, moving money or deploying code. Escalate anything with no owner. Everything else goes into a provisional registry with a low risk tier and a review date.

Week 4: Assign, record, gate, report. Assign owners to every row you can. Record identity and policy for the escalated agents first. Publish a one page intake rule with a single sentence at its center: no registry entry, no production access. That is your registration gate, and it is what keeps the inventory from decaying the day after you finish it. Then report the first metrics.

The Four Numbers Worth Reporting

Resist the urge to build a thirty slide deck. Four numbers tell the story.

Agents found. The raw count. It will be higher than anyone expected, and that is the point.

Percent with a named owner. This measures accountability. Anything below 100% for production agents is a gap with a name on it.

Percent with a unique identity. This measures attribution. If an agent runs on a shared credential, you cannot investigate it properly.

Shadow to sanctioned ratio. How many agents did nobody approve compared with how many went through intake. Watch the trend, not the first reading. The first reading will look bad because you are seeing everything for the first time.

Take these to your AI governance forum if you have one. If you are building that forum, my post on building the committee that actually governs covers how to give it real authority. Numbers like these give that group something concrete to decide on.

A note for those earlier in their careers. This is a project you can own, and it requires no special budget. A spreadsheet, access to a few consoles, and the willingness to ask people uncomfortable questions will get you through the first pass. I know analysts who built their reputations on exactly this kind of unglamorous visibility work.

Key Points

• Agents inside your walls are insiders by function. They hold access, act on their own, and need no attacker to cause harm.
• The Trellix survey of 600 CISOs (2026) is vendor research. Use it as one data point, and note that the 28% share of insider incidents is more informative than the 95% headline.
• The four layers of agent anatomy (model, harness, action space, runtime) work as a discovery checklist.
• Every agent needs a unique identity, a named human owner, a stated purpose and an applicable policy, plus a risk tier and a retirement condition.
• Agents with no owner, or with a shared or borrowed human credential, go to the front of the remediation queue.
• Thirty days gets you a first pass inventory and a registration gate, not full control.

Pro Tips

Start with the action space, not the model. The model is interesting, but the damage comes from what the agent can touch. When time is short, sort your list by the reach of its credentials first.

Make the amnesty visible and specific. Put the end date in the announcement. People respond to a deadline with a clear consequence on the other side of it.

Ask owners to write the purpose themselves. You learn a lot from how long it takes. A purpose that is vague or contested often means the agent was built to solve a problem nobody formally owned.

Reconcile on a schedule. The Five Eyes guidance points toward a registry checked against the live set of agents. Set a monthly job that compares the two, and treat any difference as an event worth a ticket.

Pitfalls to Avoid

Do not wait for a perfect tool before you start. A spreadsheet and a few consoles will tell you more in a week than a vendor evaluation will tell you in a quarter.

Do not accept a team alias as an owner. When something goes wrong, a distribution list cannot explain what the agent was supposed to do.

Do not treat the amnesty as a trap. If anyone is disciplined for disclosing an agent during the window, the next inventory will be empty by design.

Do not assume vendor agents are safe because the vendor is trusted. An embedded agent inside a product you bought still holds access you granted, and it still belongs in the registry.

Do not report the 95% as a fact about your industry. It is one vendor survey, and the people who counted incidents did not all count the same way.

Final Thought

The agentic insider is not a new kind of adversary. It is a familiar problem arriving without the controls we spent twenty years building around people, and the first of those controls is knowing who is on the premises. In the next three parts I will cover what comes after the inventory. Part 2 is least privilege and containment: how to shrink what each agent can reach and what to do when one misbehaves. Part 3 is continuous monitoring, including the supervisory "guardian agent" concepts the industry is starting to discuss. Part 4 is governance and board reporting, where the numbers from this post turn into decisions.

If you try the 30 day sprint, tell me what you find. How many agents did you discover compared with what you expected, and which layer of the anatomy surprised you most? Leave a comment or send me a note. I read every one.