Governance at Machine Speed: Why the Approval Workflow Is the Wrong Unit of Control

FinOps Had a Framework. The Framework Has a Problem.

The FinOps Foundation published four substantial documents on AI cost management in early 2026: a flagship article on agentic AI use cases drawn from practitioners at major financial services firms, followed by working papers covering AI business value, infrastructure strategy, and investment management.

The papers are thorough, grounded in real practitioner experience, and  reflect genuine engagement with how AI workloads are changing the cost management challenge. They are also, collectively, a description of how to make the existing framework slightly more AI-assisted. Which is not the same thing as solving the problem.

Here is what is absent from all four documents:

• Any mechanism for governing GPU costs at the moment they are incurred
• Any discussion of policy enforcement at provisioning, before the resource exists
• Any framework for agentic AI workloads that provision, scale, and decommission without human involvement
• Any acknowledgment that a token cost spike can exceed a monthly budget in a single afternoon

The infrastructure strategy paper recommends choosing between Fully Managed, Partially Managed, and Self-Managed AI infrastructure using the Crawl/Walk/Run maturity model. The managing AI value paper proposes establishing a cross-functional AI Investment Council. Better tagging is mentioned throughout.

The Foundation’s own framework documentation acknowledges that many cloud providers create new AI SKUs without native tagging support, and that engineering teams remain immature in their use of AI services. This is the community’s own published material noting that the tools it recommends do not fully work yet.

The most senior practitioners in the FinOps community are aware of the gap. The Foundation’s flagship agentic AI article quotes one of them directly: discussions about shifting FinOps left still do not feel like they are going to have the impact. The instinct is right. The mechanism does not exist inside the current framework.

The FinOps Foundation’s own State of FinOps 2026 opens with: “FinOps is no longer just explaining past spend.” That sentence is the community acknowledging, in its own flagship publication, that for most of its existence the practice has spent its time explaining past spend without preventing future waste.

The question is not whether FinOps practitioners are skilled or committed. They are. The question is whether a framework built around retrospective reporting can govern infrastructure that is provisioned and consumed by machines, at a speed that makes retrospective anything irrelevant.

It cannot, and at machine speed, it never will.

The Governance Model Needs to Move Where the Decision Is Made

The approval workflow was always a proxy for something more fundamental: the requirement that infrastructure decisions be authorized before they take effect. The workflow was the mechanism. The requirement remains.

What has to change is where that requirement is enforced. In a human-paced model, enforcement happened at the decision point, a human who had to make a request and wait for approval. In a machine-speed model, there is no decision point. There is only the infrastructure itself.

This is not a new insight in computer science. It is how security evolved from perimeter defense to zero-trust: when the perimeter became unmaintainable, the enforcement moved to the resource level. Infrastructure governance is undergoing the same transition. When the human checkpoint becomes unmaintainable, the enforcement has to move to the provisioning layer.

Governance cannot be a human checkpoint at machine speed. It has to be a property of the infrastructure itself.

Concretely, this means five things:

• What can be deployed and under what constraints, enforced at the point of deployment, not in a meeting before it.
• Budget guardrails: hard cost limits applied per environment, per team, or per workload, enforced before spend occurs, not flagged after it already has.
• Tagging and attribution: automatic metadata attached at provisioning so every resource is accountable from its first second of existence.
• Lifecycle policies: defined expiry for every environment, with automatic decommissioning when it ends, no extensions without deliberate action.
• Drift detection: continuous comparison between intended and actual configuration, with automated remediation when they diverge.

None of these mechanisms live in a dashboard. None of them require a FinOps practitioner to act before they function. They are properties of the infrastructure provisioning layer, enforced automatically, at the speed at which infrastructure moves.

That is the architectural shift. Not faster reporting. Not more meetings. Governance embedded in the substrate.

The Environment Is the Right Unit of Control

There is one more reframe worth making explicit, because it changes how you think about both governance and cost.

Most enterprises try to govern AI infrastructure resource by resource: this GPU cluster, this inference endpoint, this token budget. In a multi-agent deployment, that approach breaks down almost immediately. An agent orchestration framework spawning sub-agents, each making its own API calls, consuming its own tokens, and provisioning its own compute, produces a cost and governance surface that no resource-level tool can see across.

The right unit of control is the environment: a complete, bounded collection of resources assembled for a specific purpose, with an owner, a declared intent, and a lifecycle with a defined start and end.

When governance is applied at the environment level, four things become possible that are impossible resource by resource: budget by purpose, time-to-live enforcement, audit by intent, and governed replication across teams and clouds. These are not nice-to-haves. For enterprises running multiple agent frameworks simultaneously, they are the difference between a governable deployment and one that is fundamentally out of control.

How Torque Operationalizes This

Torque is built around governed, self-service environments. Every environment is defined as code, a blueprint specifying every component, configuration, policy, and integration required for a complete, purpose-built deployment. When a team or an agent deploys from a blueprint, governance is not added afterward. It is embedded from the first second the environment exists.

The five infrastructure governance mechanisms described above are core Torque capabilities, not future roadmap items:

Torque also provides the MCP server integration that enables AI agents to interact with infrastructure directly, within policy-defined boundaries. Agent RBAC distinguishes between agent roles and human roles, applying a bounded blast radius so that an agent acting autonomously cannot exceed the permissions defined for its role. Multi-agent conflict orchestration, currently in active development, extends this to arbitrate between competing agent actions on shared infrastructure.

The result is a platform where agents can operate at machine speed without governance becoming an afterthought. The speed is preserved. The accountability is not sacrificed to get it

The Practical Implication

The enterprises that will lead in the agentic era are not the ones that move fastest. They are the ones that move confidently, because their governance infrastructure is as advanced as their AI capability.

Confidence at machine speed requires three things:

• Define the environment before the workload. Governance is the container, not an audit of what the container held after it was emptied.
• Govern the aggregate, not the component. In multi-agent deployments, resource-level governance does not scale. The environment is the right boundary.
• Make lifecycle enforcement the default. Every AI environment should have a defined expiry. Indefinite operation should require a deliberate extension, not a forgotten shutdown.

FinOps as a discipline has earned genuine organizational influence.  78% of FinOps practices now report into the CTO or CIO organization, and practitioners with VP-level executive engagement have two to four times more influence over technology selection decisions than those engaging at Director level only. That influence is valuable. The question is what it is applied to.

Applied to making retrospective reporting faster and more AI-assisted, it will continue to explain waste after it has already occurred. Applied to driving the architectural shift toward provisioning-layer governance, it could eliminate the category of problem it was built to manage.

The governance model that was built for humans operating at human speed is not broken. It is just working exactly as designed in an era it was never designed for.