The agents nobody meant to build

This summer, our big concern as IT leaders was figuring out how to drive adoption and ROI for our AI purchases while keeping shadow AI at bay. My advice then:  Give people transparent, sanctioned tools and put in place operational discipline to ensure the right tools are being deployed at the right times and in the right places. That advice still holds up.

But once again, the market shifted. Now, even the sanctioned tools are part of the problem, as we speed towards the autonomous, agentic enterprise.

Fortune reported recently that CIOs are “racing to put guardrails” around agents that one security chief called “a new kind of insider.” Gartner forecasts that 40% of enterprise applications will carry task-specific agents by the end of this year, up from under 5% last year. In the very same report, Gartner also predicts that 40% of enterprises will have to demote or shut down agents by 2027.

We’re building agents faster than we’re learning how to govern them.

Most leaders point to this as a visibility problem. We need to be able to see all the agents running and assign ownership to them. Fair points, but they only reveal the tip of the iceberg. The agents I’m concerned with are the ones nobody knows they’re creating.

Classic shadow AI is a tool someone chose: an employee connects a hyped consumer product straight into a corporate system, and now you have an unsanctioned agent running on unsanctioned software. That’s the fix I have written about before:  give people a sanctioned version good enough that they don’t need the workaround.

The harder case is when an employee schedules a recurring job with their sanctioned AI desktop harness. Perhaps they schedule an agent to scan their email at set times, draft replies that they can send later, maybe even grant approvals on some minor things like direct report PTO requests. 

There’s nothing shadowy about the process. It’s working within a fully sanctioned tool that is being used exactly as licensed. But that employee just built an agent. And most people aren’t calling it that.

For the use cases described above, that’s a productivity tool for a specific employee. If their computer is off or the employee leaves the company and this de facto agent doesn’t run, nothing happens. But what happens if the employee builds a process that reads emails from a shared inbox and updates the ERP based on these emails? Now you have an agent that is part of the back-office automation of the company, and if this employee is off, a potentially critical process is not working. There is also an attack surface that nobody with a security mindset is aware of, a malicious email read by the agent might cause data corruption in the ERP, for example.

The problem is, there’s no owner to name and no approval to audit, because we’re not looking for that as an agent to name and label. You can’t put something on an inventory you don’t know exists. That’s a different failure mode than shadow IT, and it needs a different fix than a better registry.

This is where we begin to see the full depth and breadth of the iceberg we’re dealing with. It opens up entirely new considerations for our governance practices as well. We used to be most concerned with the browser and what employees could be inviting into our networks that way. The bigger concern now with agents is the security of the desktop itself, because that’s where they’re actually built and run. The way to mitigate it centers on two things:  placing hard limits on what any of it can actually touch, and educating employees on what they’re actually doing, at the moment they’re most likely to do it.

Finding the balance point between control and innovation

Here’s where we also come up against the push and pull dynamic that rules our world as IT leaders, especially in the age of AI. Sometimes it seems like we have just two options:  We can lock down the enterprise and hinder productivity and creativity for our employees, or we can make things easy for our employees and put our enterprise security at risk.

The first rule I go by here is embracing the chaos and discomfort. We don’t have this all figured out yet and that’s okay. Where I see my peers fail is when they try to force a process into place in these situations. You end up pushing the behavior you’re trying to manage outside of your area of control, making your employees even more likely to turn to unsafe workarounds.

The better approach is to put in place guardrails that allow your employees some space to experiment but limit the risk. This allows you to have some control while also being able to observe the actions your employees take, and reach out to move local processes to the corporate level.

For example, you can put in place controls directly into systems like CRM or ITSM or the MCPs used to interact with them. For example, make them read-only by default, and put in place rate limits at a more “human level”:  a few hundred records a day, not the few hundred thousand that AI can process. Limit the fields and tables that can be edited, and rate limit them as well.

Then, if an agent misbehaves, whether due to malicious instructions or just a human guidance mistake, you catch the issue after a few dozen records get overwritten, rather than a thousand and retrace your steps to rebuild the files. You’re protected whether an agent is part of a central agent registry or not.

Governance is a literacy problem now, not a policy one

The other half of this has to educate the employees and designated power users, which we call AI Champions that are proxies of the CIO office in the various departments. You need to provide guidance the moment someone starts using it, not filed away in a policy no one reads. Every employee who gets a license for a sanctioned agentic tool at WalkMe takes a short course in basic agent concepts before their license activates.

Most organizations try to launch a full corporate AI training program, where research shows that only about a third of what employees learn is still being used a year later. The training fails because it teaches AI in the abstract, disconnected from the moment someone actually sits down to use it. Gate your training to the access itself, and it lands in the moment it’s most relevant.

The goal in the training isn’t to turn every employee into a developer. That’s not realistic, and I don’t think it’s the right goal either. What you’re aiming for is an understanding of what AI tool to use when: do you need a full-blown agent or just an agentic workflow, or maybe just good old deterministic integration, and the advantages, risks and limitations for each. They walk away knowing what an agent looks and acts like in the moment it’s most relevant, not months later when it’s done something they didn’t intend or expect.

Put those two fixes together and you’re solving a different problem than the one most governance conversations are stuck on. You don’t need a complete agent inventory to navigate this. You need defaults that are forgiving, and employees who recognize the moment they’ve crossed from using a tool to operating one.

AI didn’t just hand every employee a better tool this year. It handed a lot of them some of the responsibilities that used to belong to IT alone. Our job isn’t pretending that didn’t happen, or trying to claw it back. It’s making sure nobody has to become an IT admin to carry that responsibility safely.