The Agent You Didn't Know You Deployed

The short version

Workforce interaction with AI agents grew roughly 14x between January and June 2026. Enterprises now commonly run close to one agent — live or in draft — per employee. Around two-thirds of those agents were built by people outside engineering: GTM, customer success, and operations teams who were never given a provisioning discipline because nobody expected them to be building anything.

A large majority of them are over-permissioned.

None of this shows up in your existing security tooling, because the risk is not a vulnerable dependency. It is a correctly-functioning agent with far more access than its job requires, driven by a prompt somebody else controls.

Why the usual controls miss it

Application security assumes the thing you are securing is code, written by developers, shipped through a pipeline you own. Every one of those assumptions breaks here.

An agent built in Copilot Studio or Agentforce by a revenue ops manager has no repository, no pull request, and no security review. It was assembled in a browser in an afternoon. It authenticates as that manager, or worse, as a shared service account, and it inherits whatever that identity can reach — which in most enterprises is dramatically more than any single task needs.

And the failure mode is not a crash. It is the agent doing exactly what it was asked, by someone who should not have been able to ask.

Three attack surfaces, all real:

• External — content the agent processes contains instructions it follows. An email, a support ticket, a document, a web page.
• Internal — the agent has permissions far beyond its task, so any manipulation has a large blast radius.
• Autonomous — the agent chains tools in a way nobody designed and reaches something it was never meant to reach.

Start with a count, not a policy

The instinct is to write an AI policy. Resist it for two weeks and go count instead. Policy written against an imagined population is policy that gets ignored.

Enumerate agents across every surface they get built on — Copilot Studio, Agentforce, Power Automate, low-code platforms, custom deployments, browser extensions on endpoints. Agent security posture tools do this continuously; a manual census is a legitimate start but decays inside a quarter.

Then, for a sample of about 20, do the thing that actually funds the program: compare permissions granted against permissions the task requires. That gap converts an abstract risk into a sentence a board understands — "31 of our agents can read HR records and 3 of them need to."

Bring that table to your steering committee. Do not bring a framework diagram.

Classify by blast radius, not by builder

The instinct here is to triage by who built it — engineering good, business unit suspicious. Wrong axis. What matters is what the agent can reach.

• Tier 1 — touches customer-facing or regulated data, moves money, or takes irreversible outbound actions. A marketing agent that can email your entire customer list is Tier 1 no matter how casually it was assembled.
• Tier 2 — reads internal sensitive data or writes to internal systems.
• Tier 3 — reads public or low-sensitivity data, no writes.

The part most governance programs get wrong

Here is how this fails, and it fails the same way every time:

Security discovers the agent sprawl. Security is alarmed, correctly. Security institutes a review process. The review process takes three weeks. Business units — who were shipping agents in an afternoon — route around it. Six months later there is a governance function, a policy document, and an inventory that is wrong again.

A slow paved road is how shadow agents get built. The control that matters is not the review board; it is the speed of the approved path.

What works:

• Tier 3 self-registers and goes live immediately. Audited quarterly by sample.
• Tier 2 gets a 48-hour review against a published checklist. Named owner and logging required. No board.
• Tier 1 goes to the review board with human-in-the-loop on every write, full prompt and tool-call logging, and a documented rollback.

And publish a service commitment on the Tier 2 SLA, with a stated fallback if you miss it. Holding yourself to it is what keeps builders inside the system.

Enforce at runtime, not only at review

Design-time review catches the agent that was submitted. It does nothing about the one that was not, or the one whose behavior drifted after somebody edited a prompt.

Two controls do the heavy lifting:

• Identity scoping. Agents act with least-privilege delegated credentials, never a shared service account. Shared-account usage should be an automatic finding, because it makes attribution impossible and attribution is the whole game during an incident.
• Runtime monitoring on intent and execution path, rather than isolated alerts. The question is not "did an anomalous API call happen" but "is this agent doing something outside what it exists to do."

The four metrics that survive a board meeting

1. Total agents discovered 2. Percentage with a named owner 3. Percentage over-permissioned against task requirement 4. Mean time from registration to approval

The fourth is the one people leave off, and it is the one that keeps the program funded — because it is the only metric that proves you are an enabler rather than a bottleneck. Security functions that only report risk reduction get budget once. Ones that report faster sanctioned delivery get budget every year.

When you do not need any of this

If you have a few dozen agents and they are all built by one engineering team under existing SDLC controls, extend that process. Do not build a parallel one, and do not buy a posture platform — a maintained spreadsheet with a named owner per agent genuinely covers you at that scale, and the budget is better spent later.

The full implementation, with a registration record template, a permission delta assessment, and the tiered approval path, is written up as a workflow: AI Agent Inventory & Governance Program. If your problem is proving the agents work rather than finding them, the companion piece is the agent evaluation and regression harness.