AI governance belongs in software

Ask who owns AI governance in a room of IT leaders and you get four answers: IT, security, a data or AI office, or “we haven’t decided.” The fourth answer is more common than anyone likes to admit.

The first three usually share a deliverable: a policy. An acceptable-use document, an approved-tools list, a risk framework that went through legal.

Those documents are worth having, and they’re the part of a governance program that does the least work. The research on what separates mature programs from the rest says so plainly.

AI is already running where IT can’t see it

Start with what’s in production now. Governance is a response to something that has already happened.

Gartner reported in February 2026 that a majority of the IT and security leaders it surveyed either had evidence of unsanctioned AI agent automation in their organizations or suspected it.¹ A separate Gartner team reached a similar finding later in the year. The document doesn’t state its sample size in the body, so treat the finding as directional. The direction is clear enough: agents are being built and run outside the line of sight of the people responsible for them.

The Cloud Security Alliance put a sharper edge on it.

The interesting number is the gap between the two.² Most of the people who found an unknown agent also believed their visibility was strong. Confidence ran ahead of what they could see. A policy document does nothing to close that gap, because the person building the agent never consulted it.

Deployment is outrunning governance

The second piece of evidence comes from the people whose job this is. Gartner’s newest survey of AI governance leaders, people who sit on or lead their organization’s AI governance committee, asked what stands in the way of effective governance. Two of the barriers at the top of the list were AI deployment moving faster than technical governance requirements can follow, and public policy and regulation changing faster than teams can track.³ The same research found that the complaint governance leaders most often take to their boards is the low maturity of their own program.

Put those together and you get a familiar shape. The speed of deployment is set by the people building with AI, and that speed went up sharply when AI coding assistants and agent frameworks made building cheap. The speed of governance is set by the number of people reviewing, and that number didn’t change. Every process that depends on a human reading something before an AI system goes live scales with headcount. Deployment no longer does.

Regulation makes the problem worse. A policy written against last quarter’s rules has to be rewritten, re-approved and re-communicated, and each of those steps takes weeks. A control enforced in software can be changed once, in one place, and applies to everything that runs through it from that moment on.

Mature programs build oversight into systems

So what do the organizations that are ahead actually do differently? Gartner’s research on AI governance checklists, based on a survey of senior AI leaders at organizations with AI in production, compared high-maturity programs with the rest.⁴ The biggest differences were in technical work: designing and deploying oversight systems for AI, and monitoring and auditing AI continuously. Writing policy showed the smallest difference of the activities compared.

That finding deserves a moment, because it runs against how most programs are staffed. Writing policy is where a new governance team usually starts, and it’s a reasonable place to start. Everyone does it: low-maturity and high-maturity organizations write policy at similar rates.

What the mature ones add is the machinery underneath: oversight that runs whether or not anyone remembers the rule.

The same research lays out a maturity path, and the goal it sets for organizations that are scaling AI is that governance becomes automatic, with enforcement keeping pace with delivery and applying consistently across models, apps and agents. At the most mature level, it asks for full telemetry and governance evidence. A document can’t meet any of them.

Policy does not make anything happen faster

Gartner’s authors are blunt about the document approach. Their point, in paraphrase, is that organizations put real care into long policies that are never read again, and that a policy on its own doesn’t make anything happen faster.⁴ They go further for the AI building that happens outside engineering: its guardrails have to be established in the software, because governance policies alone won’t shape it.

That’s the argument of this whole post in one line. A policy states what should happen. Software decides what can happen. When the two disagree, software wins every time, because the builder at their desk at 6pm with a working prototype isn’t going to reopen the acceptable-use policy before shipping it.

Here’s what “in the software” means in practice, taking the controls most programs care about:

• Access. An agent reaches a system through a gateway that checks which tools it may call and logs every call. Today, the way in is often a token someone pasted into a config file.
• Apps. An app built with an AI assistant reaches production through a path that attaches identity, managed credentials and an owner. The usual alternative is a personal cloud account.
• Data. Sensitive fields are masked in the pipeline before they reach a model, so people don’t have to remember what’s safe to paste.
• Cost. Spend is recorded against an app, a team and an owner as it happens. Otherwise you find it on next month’s invoice.
• Evidence. One record of who did what, as whom, against which system, written as it happens. After an incident, there’s nothing to reconstruct.

Every one of those holds whether or not anyone read the policy. That’s the test worth applying to each control you have.

What tooling does not replace

The same Gartner research is clear that buying tools covers only part of the job.

Policy decides the tiers: what is allowed, what needs review, what is off-limits. People own the decisions and the exceptions. Software enforces the tiers on every request, for everyone, without needing a reminder. A program with only the first two is a request. A program with only the third enforces rules with no author. The mature version has all three, and the research says the third is where most organizations are furthest behind.

Where Tray fits

This is the problem we build for at Tray. Tray Helix deploys, runs and governs the apps people build with Claude Code, Codex and Cursor: one command takes an app to a managed runtime with SSO, scoped roles, managed credentials so no secrets sit in the code, an audit trail, a named owner and a registry entry, with execution logs and AI and compute spend visible for every app. Tray also has a full iPaaS on the same foundation, where the Agent Gateway exposes more than 700 Tray connectors as governed MCP servers with an audit of every call. Both put the controls in the path, which is where the research says they need to be.