The Agent Underbed
Last year, an operations team at a midsize logistics firm noticed something odd in their software spending. A few hundred dollars here, a couple thousand there, all attributed to tools nobody could name. When they dug in, they found that the customer service reps had each quietly deployed their own chatbot helpers over the past eight months. Those bots were pulling data from vendor portals, remembering context from past tickets, and sharing patterns across the department. Nobody signed off on them. Nobody reviewed what permissions they had been granted. By the time the finance team noticed, the agents had quietly become part of how the work actually got done.
This is the new shape of the problem. It is no longer whether employees will deploy autonomous AI agents without approval. It already happens. The real question is how you control what those agents are allowed to access and learn once they go live, especially the ones nobody ever saw coming.
A New Layer for a Messier Reality
A newly funded startup called AIR is building the governance layer for exactly this messier reality. Its approach is worth unpacking because it reflects how the problem has actually changed from what executives may have imagined a couple years ago. The first job AIR does is discovery. Rather than assuming the enterprise already knows its agent landscape, the system maps the agents that are genuinely running inside the company, including the ones employees spun up on their own.
That sounds simple, but it is where most existing tools fall short. A lot of today's software governance was built to watch applications and APIs. It was never designed to watch a bot that sits between an employee and a knowledge base, learning the shape of a team's workflow and quietly taking actions on its behalf. AIR treats those agents as first-class citizens that need to be found, catalogued, and understood before any real governance can begin.
The second job is continuous vetting. This is the part that matters most. When an agent takes on a new skill, installs a new add-on, or connects to a new data source, the system checks whether that behavior is safe and authorized. It is not a one-time gate checked when the agent was approved. It is an ongoing process, because agents evolve fast. A customer support bot deployed in January can be doing something unrecognizable in March after its team added a code-execution plug-in it never should have been granted.
The third job is blocking unwanted behavior. If an agent tries to read data outside its mandate, call an external API that was not cleared, or learn something it was not permitted to, the layer stands between the agent and the action and stops it. The premise is that permission should be defined by what the agent is actually supposed to do, enforced continuously, and updated as the agent changes.
Why This Is Different from Old IT Governance
The reason executives are uneasy is that this breaks two assumptions that have held up IT for decades. The first is the perimeter. For a long time, security meant knowing what was inside the firewall and what was outside. You approved the software, you provisioned the users, and everything else was the enemy. Agents collapse that distinction, because they work in the space between systems, pulling from a dozen data stores and acting on the results. There is no neat wall around them.
The second assumption is that governance happens once, up front. You review the request, you grant access, you sign the contract, and then the system is trusted until the next renewal. That model assumes the thing being governed stays still. Agents do not. They accumulate skills. They take new actions. They build context over time that their creators may not fully understand themselves, let alone the people who were supposed to approve them.
Both of those shifts are uncomfortable, but they are not unsolvable. They just require a governance layer built for the actual conditions, not the conditions that existed when the old rules were written.
What the Executive Actually Needs to Do
The good news is that you do not need to solve this alone, and you do not need to build the capability in house. The model that is emerging is a platform that does the discovery, the vetting, and the blocking so that governance keeps pace with the agents on their own. But the executive still has three real responsibilities that technology cannot take over.
First, you must define what permission means. A governance tool can block an agent from reading payroll data, but only if someone decided that the customer support bot should not be able to read payroll data. That boundary comes from business judgment, not from the software. Decide what category of data, what systems, and what actions each type of agent is allowed to touch, and write those rules down clearly enough that a non-engineer can understand them.
Second, you must accept that discovery has to come first, even for the agents nobody approved. This is where the uncomfortable part sits. Many of these agents are already running and already working. Telling your people to shut them down is both unrealistic and counterproductive, because the productivity is real. Instead, bring them into the light. A bot that someone deployed without approval is still a known risk far safer than one that is invisible. The discovery step turns shadow agents from a liability into something you can at least evaluate and govern.
Third, you have to treat continuous vetting as the normal state, not an exception. If your governance only happens when an agent is approved, you will always be behind. The skills and add-ons an agent picks up after approval are where the risk actually grows, so the checks have to keep running the whole time the agent is live.
The Answer to the Question
So how do you govern the agents nobody approved? You govern them by making sure they can no longer hide. A governance layer like AIR turns the discovery problem into a solved problem, which is the piece most teams assumed was impossible, and then it continuously vets the skills and add-ons those agents use and blocks the behavior that goes beyond what you authorized. But the technology only does half the work. The actual answer is that you stop treating approval as a single event you missed, and start running a continuous loop of discovery, permission, and enforcement around the agents that are already working.
The ones nobody approved are not going to go away, and trying to ban them is both futile and a distraction. The move is to find them, see exactly what they are allowed to access and learn, enforce those boundaries continuously, and stop the ones that exceed them. Once you build that loop, the question stops being about the agents nobody approved, because there will no longer be any agents running that you do not at least know about. That is the governance you were missing, and it is the one you can now build.
