The Business Case for Governing AI Agents

Part 4 of a four-part series on Joiner/Mover/Leaver for AI Agents.

The first three parts of this series made a risk argument. AI Agents join without approval, change scope without review, and leave without anyone revoking their access. Every one of those failures is an audit finding waiting to happen.

Risk is the right reason this gets attention. In a regulated institution, risk is what puts a topic on the agenda, and it should. But risk is also what gets a project scheduled for next year, because it is real and abstract at the same time, and abstract competes badly against everything else holding a budget line.

So Part 4 adds the lens that moves the work up the queue rather than off it: not what Agents might cost you on a bad day, but what they already cost you on an ordinary one. That cost is less dramatic than a breach headline and more persuasive, because it is already running through your P&L. Agents did not invent it. They are multiplying an inefficiency your organization has carried for years.

Sprawl Is Not New. The Scale Is.

Start with the part of this that predates AI entirely.

Secrets management has been an under-governed administrative burden in every engineering organization for a long time. The credentials live in too many places: API keys, service accounts, OAuth grants, config files, and the occasional environment variable nobody documented. HashiCorp's research found that developers lose roughly three hours a week to secrets management. And because the work is manual and owned by no one in particular, it does not hold. GitGuardian retested credentials confirmed valid in 2022 and found 64% still exploitable four years later, because rotation is rarely owned or automated. That was already a cost before a single Agent entered the picture.

Here is what Agents change. An Agent is a new identity that needs credentials, and the organizations deploying Agents are not deploying just one Agent. A developer with access to a general model platform can stand up dozens of Agents in an afternoon, each one acquiring its own keys and grants, each one becoming another entry in a population that was already too large to govern by hand.

The failure mode is identical to the one engineering already lives with. The difference is the rate: Agents pour volume onto a process that was already leaking, at a speed human-driven development never reached, accelerating a known, unbudgeted inefficiency past the point where manual administration can keep up.

The industry's reflexive answer to a new identity type is a protocol, and its track record on adoption is poor. SCIM was meant to make user provisioning universal more than a decade ago, and it is still absent or paywalled across most of the application landscape, governing only a fraction of the apps a real enterprise runs.

Expect a proposed Agent-identity standard to follow the same curve: real in slideware, sparse in product, with sprawl running well ahead of the protocol meant to contain it.

Sizing It for Your Own Environment

Industry averages set the shape of the problem, but don't tell you what it costs in your environment. Three rough calculations do, and none of them needs a consultant or more than an afternoon.

Engineering drag. Start with the three hours a week HashiCorp measured, multiplied by your engineering headcount and your loaded hourly cost. At a common loaded rate, GitGuardian's analysis puts the lost productivity near $17,000 per developer per year, so a 200-engineer organization is carrying somewhere around $3 million annually in time spent managing credentials instead of shipping. Your rate will differ, but the figure is calculable, sizable, and currently unbudgeted. The follow-on question this series is really about: as your Agent count climbs, does that number bend up with it, and who is watching it bend?

Audit delta. This is the calculation most worth your time, because it is the one a regulator will eventually run for you. Estimate the person-hours your last access certification cycle spent on machine and service accounts, then ask how many AI Agents were in scope at all. For most organizations, the answer is close to none. Agents are spun up outside the joiner process, hold standing credentials, and have never appeared in a certification campaign.

That absence is the exposure. An Agent that can both initiate and approve the same transaction is a separation-of-duties violation, whether or not it is software, and the auditors have started treating it that way. KPMG's 2025 SOX survey put the average program at $2.3 million and more than 15,000 person-hours a year. The cost of a finding also includes remediation under a deadline, re-testing, and an expanded audit scope that follows you into the next cycle.

The enforcement environment is not theoretical. Regulators have shown they will impose business-defining penalties for control failures they judge to be systemic. In 2024, TD Bank paid a $1.3 billion FinCEN penalty, the largest in that agency's history, for AML program deficiencies regulators called long-term, pervasive, and systemic. Access governance carries the same exposure logic. Running non-compliant has been estimated at roughly 2.71 times the cost of staying compliant, and the gap widens as scope expands.

Audit delta belongs at the center of the model because it converts cleanly. A certification gap is specific, dated, and addressed to a named officer. It is the part of your Agent sprawl that has a regulator attached to it, which turns it from a cost you can defer into a cost you have to answer for.

Agent exposure. Count the AI Agents you can confirm in production. If you cannot produce that count, that absence is itself the first finding. For the ones you can name, tally how many hold standing credentials that have never rotated and have no documented owner; each is an input to breach probability and a line in scope for your next audit. These are estimates, but they move Agent sprawl from a category nobody prices into one with a defensible figure attached, and a defensible figure is what lets Agent governance compete for budget without waiting for an audit finding or an incident to force the decision.

Governance Returns More Than It Costs

Risk remains the headline, and in a regulated institution, it should. A breach or a finding is the larger number and the one that commands attention. But risk is not the whole of the case, and treating it as such leaves the operational return sitting unclaimed.

An insurance premium pays out only on a bad day; Agent governance also pays back across normal operations. It recovers engineering capacity, the equivalent of 1.2 full-time engineers per year in one secrets-governance deployment, through faster remediation and self-service provisioning. It compresses audit costs, turning an auditor's question from a multi-week scramble into an afternoon's export once machine identities stop being a manual investigation. And it shrinks the attack surface itself: fewer ungoverned identities simply means fewer paths in for an attacker to find.

That is three returns: recovered engineering capacity, compressed audit costs, and a smaller attack surface that show up whether or not there is ever an incident, separating it from a pure risk spend. If an incident does land anyway, the math still tilts further in governance's favor: IBM found organizations using security automation extensively saved $1.9 million per breach and cut 80 days off the lifecycle.

The Path Is Not Smooth, and That Is the Point

It would be easy to end with a clean instruction: build Agent governance now, before a regulator forces it on an emergency schedule. The OCC, Federal Reserve, and FDIC have signaled plans for a joint RFI on banks' use of agentic AI, DORA already covers AI vendors under ICT third-party risk, and the EU AI Act's high-risk obligations, originally due in August 2026, are already being pushed back to 2027 and 2028 under a pending EU agreement.

But that is the wrong lesson, because it frames governance as a new and separate apparatus you must go build, and that framing both gets deferred and does not hold. Be honest about the difficulty here. Agent sprawl will not stop on instruction any more than shadow IT stopped when policies told it to. Teams with access to general model platforms will keep spawning Agents, because the value is real and the friction is low.

New governance frameworks will arrive, and they will help, but expect them to contain the problem only partway, and for two different reasons. Voluntary standards under-deliver through weak adoption incentives, a decade after SCIM promised universal provisioning, most of the application landscape still doesn't support it. Regulatory frameworks under-deliver through delay, the EU AI Act's own high-risk deadline slipped before it ever took effect. Neither pattern is an argument for waiting on the next one. This is hard, and it is going to stay hard.

Not All Agents Create Sprawl

The problem is not Agents. The challenges stem from how they are adopted. There is a difference between an agent platform and an AI-Native solution.

An agent platform is open-ended: teams spin up many Agents that act broadly on behalf of users, with thin visibility into what each one accesses, builds, and pushes back into systems. That is where sprawl comes from, and where governance becomes tricky. What work was done by the employee? What did the Agent do?

An AI-Native solution is bounded: built for a defined use case, performing specific tasks. This means the scope and reach of the Agent are easier to define, and easier to govern. Enterprises are already extracting real value from agent platforms - but the governance gap and shadow AI risk are well-documented headwinds slowing broader rollout. McKinsey's 2025 State of AI survey found 62% of organizations are at least experimenting with AI agents, but only 23% have scaled one into even a single business function. That gap is not universal, though - it is concentrated in the open-platform pattern, where governance has to be retrofitted onto something already sprawling. An AI-Native solution does not carry the same drag, because there is less to govern after the fact.

If an AI-Native solution is architected with safety and security at its core, existing governance solutions work well. An Agent can have its own identity like employees do. This means you can apply the same policies to the Agent so that it only has access to the applications and information it needs to perform the specific task it is designed for. And because safety and security are built into the design from the start, full accountability and auditability are possible. This stands in sharp contrast to the twofold challenge of unbounded platforms - sprawl by default, and governance that cannot cleanly apply after the fact. An AI-Native solution avoids both: no sprawl by design, and conventional governance works because it was built to apply from the start.

An Agent with its own identity can be a joiner, a mover, and a leaver. An Agent wearing a human's credentials can be none of those things, because there is nothing to govern that the person did not already have.

Opnova is one example of what this looks like in practice. Its Agents carry their own credentials rather than borrowing a person's, so the identity infrastructure already built for employee joiners, movers, and leavers applies to them directly. The solution is purpose-built with safety and security at its core, giving identity teams the flexibility to solve specific, high-value challenges unique to their organization, while keeping sprawl risk low: standard governance applies, and every Agent's work is auditable.

AI Agents Are a Workforce

Across four parts, this series argued one idea: AI Agents are a workforce. They get hired, they change roles, they should get fired, and today, almost none of that is governed. The first three parts framed that as risk. This part reframed it as cost, with a solution.

There is no version of this where the sprawl politely stops. There is a version where new Agents are governed from birth because they were built to carry their own identity, and a version where they accumulate inside human credentials until a finding forces an expensive reckoning. The institutions that get this right will do it by making sure their Agents were never ungoverned in the first place.

That cost is already running. It is worth knowing what it is, and worth deciding, deliberately, which side of that architectural line your Agents are going to be born on.