What the Rise of AI Agents Means for IT Leaders

For most of the profession's history, IT's authority rested on owning the means of building. Agents have moved that capability onto a business unit's expense card, and the function's relevance now depends on supplying what nobody else can.

Somewhere in the middle of a quarterly business review, a director of revenue operations shares her screen and demonstrates something nobody in the room commissioned. It reads the previous quarter's contracts, reconciles renewal dates against the CRM, flags the accounts where the terms and the billing record disagree, and drafts the outreach. She built it over three weekends with two curious people from her team, it runs on a subscription paid with a corporate card, and it has been in daily use for a month. The CIO's first reaction is a question about how it obtained access to contract data. The second reaction, which arrives more slowly and matters far more, is the recognition that nothing in a decade of carefully constructed governance would have prevented any of it, and that the only reason he is hearing about it at all is that the work went well enough to be worth showing.

That second recognition is the real subject of this essay, because it is not a story about one team going around the rules. It is a story about what happens to a function whose authority was never really rooted in policy in the first place. IT could enforce architecture standards, procurement gates, and change control because building software required inputs that IT alone controlled: infrastructure, licenses, engineering time, database credentials, a release process. The rules had teeth because they were attached to a chokepoint on supply. Take the chokepoint away and the rules do not become wrong, they become optional, and a function that has confused the two will spend the next few years being surprised.

The chokepoint was doing the argument's work

It is worth being honest about how much of IT's institutional weight came from scarcity rather than from persuasion. Architecture review boards did not survive because business leaders found them enlightening; they survived because the road to production ran through them. Procurement gates worked because software arrived as a contract with a vendor and contracts had to be signed by someone. Every governance instrument the function holds is, structurally, a tollbooth on a road that IT built and maintained, and the tollbooth's authority was always borrowed from the road's exclusivity. Agents dissolve the exclusivity, not by making enterprise-grade engineering easy, but by collapsing the threshold for producing something that works well enough to be used on Monday. The gap between describing an outcome in plain language and having a rough version of it running is now short enough that a motivated non-engineer can cross it in an afternoon, and a motivated team can cross it repeatedly.

The reflex, when a leader first sees this, is to reassert the gate: block the domains, tighten card controls, mandate an intake form for anything involving AI. The trouble is not that this is unfair or that people will revolt, but that it does not stop the work; it stops the reporting of the work. The people building these things are not shadow operators with a grudge against governance. They are conscientious employees with a number to hit and a quarter to get through, and when the sanctioned path costs six weeks and the unsanctioned one costs a weekend, the sanctioned path loses on merit. Every additional degree of prohibition trades a governance problem you can see for one you cannot, and the second kind is strictly worse, because the version you cannot see is also the version nobody thought to give a service account, a log, or an owner. The answer to this is emphatically not to go looking harder — building an apparatus to catch employees using tools is a way to guarantee that the next capable person simply never mentions what they made.

The function has been here before, which should be reassuring rather than embarrassing. Spreadsheets, then departmental SaaS, then employee-owned mobile devices each arrived as an ungovernable incursion, each was met with a period of futile prohibition, and each ended with IT recovering its standing by supplying something the incursion could not supply for itself. Single sign-on and contract leverage did more to bring SaaS back into the fold than any policy about unapproved vendors, and device management did more for mobile than any memo about corporate hardware. In each case the function's authority was reconstructed downstream of adoption rather than upstream of it, and it proved sturdier that way, because it rested on being needed instead of on being unavoidable.

What a business unit genuinely cannot build for itself

The useful question, then, is not how to stop the weekend project but what the weekend project structurally cannot do, and the list is both short and unglamorous. It begins with identity, because an agent that acts has to act as someone, and a departmental build almost always acts as whoever's credentials were nearest to hand. That means the thing inherits a specific human's access, in full, permanently, and the audit record shows a named employee performing hundreds of operations at three in the morning. Nobody outside IT is positioned to give software its own identity, with its own lifecycle, that can be revoked without revoking a person.

Entitlement is the second thing, and it is harder than it looks because it is not a property of any one team's project. What an agent should be permitted to see is a question about the whole organization's data — which fields carry personal information, which records are subject to a legal hold, which contract terms cannot leave a region, which approvals are required before a customer-visible action goes out. A revenue operations team can reason well about its own data and has no basis at all for reasoning about everyone else's, which is precisely why entitlement has always been a central function and why it becomes more central, not less, when the number of things asking for access multiplies.

Integration is the third, and it is where the real cost hides. Getting one system's data into an agent is a solved afternoon; the value almost always lives in the join across three or four systems, and each connection past the first brings credential custody, rotation, rate limits, schema drift, and the quiet obligation to fix it when the vendor changes something. A curated, governed connection surface — the direction the Model Context Protocol and the platforms built around it are pushing toward — is an asset no single department can justify building and every department wants to use. Finally there is the ability to survive scrutiny, which sounds like a compliance concern and is really an operational one: when a customer's security questionnaire, a regulator, or an incident review asks what a system did, on whose behalf, and who approved the consequential steps, an answer has to exist. A decision an agent makes on the company's behalf is still the company's decision, and the org will be asked to defend it as such.

This is also why the failure rate matters more to IT than the adoption rate. Gartner has predicted that more than forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Departmental builds tend to hit that wall first, not because the people are less capable, but because a prototype that works is a small fraction of a system that keeps working, and the remainder is almost entirely the substrate a business unit has no way to provision. The projects that survive are disproportionately the ones that acquired an identity, a scoped entitlement, a maintained integration surface, and a record. Being the reason a project lands in the surviving fraction is a far stronger position than being the reason it never started.

Authority moved downstream, and now has to be re-earned

What follows from this is a change in posture rather than a change in principles. The function stops being the body that approves work and becomes the body that supplies the conditions under which work can last: a place where an agent is issued a machine identity rather than borrowing a person's, where entitlements are scoped by policy rather than by whatever the credential happened to reach, where model traffic passes through a gateway that logs and costs it, where the connections to core systems are maintained by people whose job that is, and where human sign-off is wired into the actions that touch money, customers, or anything regulated. Enterprise platforms are organizing themselves around exactly this division of labor — StudioX's model of an LLM gateway, enterprise deployment, a governed MCP integration surface, and human-in-the-loop checkpoints is one expression of it — and the reason the division holds is not that it is elegant but that it maps onto who can actually be accountable for what. This is the argument running through the growing body of work on how autonomous enterprise operations are governed: the constraint on autonomy at scale is rarely the model, and almost always the unglamorous scaffolding around it.

The uncomfortable implication is that this authority is not granted, and it does not renew itself. If the sanctioned path is slower than the corporate card, people will keep choosing the card, and no amount of organizational insistence will change an outcome that is being decided on convenience. IT is now in a position of competing for internal adoption, which means the metric that matters is how long it takes someone with an idea to get a governed version of it running, and the honest test of whether the function has made the transition is not whether people ask for permission. It is whether they show up before they need it — whether the platform team hears about the contract reconciliation project in week one because that is the fastest way to get to something real, rather than in month three from a slide.

The mental model worth carrying out of this is that the gate did not disappear; it moved. It used to sit at the front of the work, where it determined whether something could be built at all, and that position is gone and not coming back. It now sits at the far end, where it determines whether something gets to persist — to be trusted with real data, to run without a specific person's password, to still be there after the person who built it changes teams, to be defensible when someone asks. IT no longer decides what gets started. It decides what gets to last, and that turns out to be the more durable form of authority, provided the function notices the shift in time to claim it.