Why Enterprises Need Agent Discovery

TL;DR

A discovery program's real test isn't whether it catches an agent at the moment it's created. It's whether anyone can name that agent the moment something goes wrong. Most enterprises fail the second test, and they usually don't find out until an incident forces the question.

Take a vendor-onboarding assistant a supplier embedded in its portal, granted an OAuth scope by one procurement employee who has since left the company. Nobody in security registered it, because nothing required them to. It kept running.

The failure isn't that the agent got created this way. Reasonable agents get created this way constantly, and stopping that isn't the goal. The failure is the gap between creation and anyone noticing, and how much can happen inside it.

Discovery doesn't stop that agent from being created. It closes the gap, and the gap is where nearly all of the actual risk lives.

Overview

A "why you need discovery" argument usually turns into a list of abstract virtues: faster incident response, a cleaner compliance posture, fewer duplicate agents. All true, and none of it lands the way one specific failure does. So here is one, walked through step by step: how an unregistered agent gets created, how it sits unnoticed, and what actually happens on the day someone finally has to explain it.

Take a supplier that ships an onboarding assistant embedded in its own portal. A procurement employee grants it access with a single OAuth click, because the portal asks for it and approving the grant unlocks a faster onboarding flow. The assistant now holds a standing token scoped to whatever documents and contacts that grant covers. Nobody outside procurement knows it exists, and nothing forces anyone to find out. This is a hypothetical, built to be typical rather than dramatic, and that's exactly the point: nothing about it required anyone to do something wrong.

That's the setup. What follows is what discovery is actually for.

The Agent Nobody Registered

At the moment of that OAuth click, three things become true at once. An external agent gains standing access to internal systems. No inventory entry gets created, because nothing in the flow asks for one. And the only record of the grant's existence sits inside the identity provider's consent log, a place almost nobody checks unless they already suspect something.

None of this is unusual. It's the default path for how a third-party agent enters an enterprise, and it looks identical whether the vendor is trustworthy or not. The grant itself carries no signal about which one this will turn out to be.

Where It Sat

For months, nothing happens that would draw attention. The assistant does what it was granted to do: pull onboarding documents, confirm contact details, sync a status field back to the portal. The vendor relationship deepens the way these things do, more contract terms get shared, a second contact gets added, the integration's actual footprint grows a little past what the original grant was meant to cover.

Then the procurement employee who approved it changes roles, and a few months after that, leaves the company. Nobody reassigns the agent, because nobody owned it in any record that survives the employee's departure. It isn't disabled either. An OAuth grant doesn't expire just because the person who clicked "allow" is gone.

The Day It Mattered

The vendor's own platform has an incident of its own, unrelated to anything the enterprise did. The change on their end alters what the integration requests, and the assistant starts pulling documents well outside the original relationship: contract terms across other suppliers, not just the one it was meant to serve.

A security analyst notices unfamiliar traffic hitting the contract repository at volume, tied to an OAuth client ID nobody recognizes. That's the entire signal to start from. There's no name attached to it, no owner, no record of what it was supposed to be doing in the first place.

What Discovery Would Have Caught, and When

Run the same story with a discovery process in place, and it breaks differently at every step.

Figure 1 — The same incident, run twice. Discovery doesn't stop the vendor's platform from having a bad day. It decides whether the response starts from a name or from nothing.

At the grant, the OAuth signal alone would have surfaced the assistant the same day, before it had done anything at all. When the employee left, an "owner departed" trigger would have flagged the agent for review, and that review is exactly the moment someone would have noticed its scope had quietly grown past what was approved. By the time the anomalous traffic showed up, the responder wouldn't be starting from an unfamiliar client ID. They'd be opening a record that already said who owned it, what it was supposed to touch, and what normal looked like.

Why This Isn't Rare

We don't think this scenario is unusual, and that's the uncomfortable part. Nothing about it depended on carelessness. It depended on how easy an agent is to create relative to how much friction exists around noticing one, and that asymmetry is structural, not a one-off lapse by one procurement employee.

The same shape shows up as duplication, three teams building the same triage agent without knowing about each other, and as abandonment, an agent that outlives the project it was built for and keeps its access anyway. Different surface, same root cause: nothing forced the agent into a record the moment it was created.

We think that's the detail worth taking away from a story like this one: the vendor incident is the part nobody controls, but the eight months of silence before it is entirely a design choice, made by default rather than on purpose, every time an enterprise doesn't put anything in the OAuth grant's path.

Who Feels the Gap

The gap shows up differently depending on where you sit. A security team loses the hours between "something looks wrong" and "we know whose agent this is." A compliance team loses the ability to answer, on short notice, which autonomous systems can reach regulated data. A business team loses nothing at first, and then loses a lot at once, when the agent it forgot about becomes the reason for a very uncomfortable meeting.

None of those are hypothetical costs stacked on top of each other. They're the same cost, felt three times, because the same unregistered agent is the answer to all three questions. Our view is that this is the strongest argument for building discovery before an incident asks for it: whoever ends up accountable for the answer would rather it already exist.

Conclusion

The vendor-onboarding assistant in this story didn't do anything malicious, and neither did the procurement employee who approved it. That's what makes the scenario worth sitting with rather than dismissing as an edge case. Ordinary decisions, made in good faith, produced an agent nobody could name on the day it mattered.

Discovery doesn't add a gate in front of that first OAuth click. It makes sure the click leaves a record that survives the employee who made it, so the next person who needs an answer isn't starting from zero.