FinOps Stalls When Decision Rights Stop at the Dashboard

FinOps has run on partly informal authority: reputation and a record of good calls. An agent cannot be authorised by any of that, so tacit authority must become written policy before an autonomous identity acts. My client’s request, queued 16 working days, shows the gap before any agent arrives.
In an engagement running now, I asked a client for access to their cost data, in two parts in two places. The first was the AWS billing read-only policy in the management accounts of more than one AWS Organization. The second was permission to deploy CloudFormation stacks and author QuickSight dashboards in a separate, dedicated cost-data account that holds billing exports and nothing else. No account holding customer workloads was requested or visible. The second part is the larger ask: deployment rights are write rights, even in an account with no workloads.
Both parts went in on one ticket, into the same queue as third-party access to customer data, and security is assessing them as one package that has sat there for 16 working days. The client promises its customers that no third party touches their data, and nobody can say without full due diligence whether this request falls under that promise, because nobody has classified what the billing export contains. With no documented classification and no stated turnaround, the only safe route is the one built for the customer database. Sixteen working days is how long it took to discover that nobody had written down who classifies a billing export, or how long that decision may take.
The 2026 State of FinOps records organisations asking their practices to self-fund AI investment from optimisation savings, inside a model the Foundation describes as centralised enablement with federated execution. That is cost outcomes expected across decisions the practice does not control. The gap between the expectation and the control shows in four places: access to the evidence, authority to make the decision, permission to execute it, and accountability for the result. If those boundaries stay implicit, FinOps depends on repeated approvals and escalation before a finding becomes an action.
Frank Contrepois argued in January that sponsorship without explicit decision rights leaves FinOps able to observe and report but unable to act. Dean Oliver of the FinOps Foundation listed the authority gap in August as one of five reasons agentic FinOps adoption is slow.
Four authority boundaries
Call them See, Decide, Act and Answer. See is the billing-viewer grant. Decide is whether a particular non-production environment may be stopped; a platform owner may hold it. Act is the identity that carries the stop permission. Answer is who owns availability if the decision was wrong.
FinOps can hold See without Decide. It can recommend without Act. An automation role can hold Act while the organisation has never assigned Decide or Answer. Handing the central FinOps team engineering’s stop button would fix the wrong problem. In the Foundation’s 2026 survey, 60 per cent of practices use centralised enablement and another 21 per cent use hub-and-spoke models (657 respondents). The Framework’s Usage Optimization capability says the work “is primarily done by Engineering”. Rate Optimization is the exception, naming the central FinOps team “the primary driver coordinating purchases” of commitments.
The Framework’s Executive Strategy Alignment capability lists “clarify decision rights and guardrails” as an executive activity: define who can approve spend changes, commit capacity, and accept cost, risk and performance trade-offs. The same page tells practitioners to earn their place by delivering trusted data rather than “seeking a ‘seat at the table’ through mandate”. Oliver carries that advice into the agentic world: earn bounded action, one use case at a time. It works while the actor is a person. A practitioner accumulates authority informally, through judgement, relationships, sponsorship and a record of good calls, and much of it never gets written down because it never has to be. An agent cannot be authorised by any of that. Its authority has to be a policy somebody can encode and revoke, so Oliver’s progression exposes the limit of earned authority rather than solving it.
The Foundation is right about federated execution and right about earning trust, and the two ideas leave a gap once execution moves to an autonomous identity. Federation between people tolerates ambiguous authority, because people negotiate around it. Machine delegation has to encode the boundary. Oliver writes that most practices still lack the authority to move from reporting to fixing. My contention is that practitioners have worked around part of that deficit through relationships and a record of good calls, and that an autonomous identity forces the workarounds into the open.
Billing access exposes the first gap
All three hyperscalers provide a dedicated role or policy for the viewing half of a request like mine: AWS’s AWSBillingReadOnlyAccess, Google’s Billing Account Viewer and Azure’s Cost Management Reader.
Security is right to classify the data behind those roles. All three providers warn against putting personal or confidential values in tags. The export carries account identities, resource identifiers, enabled tag values, and effective rates after discounts and commitments, and each of those fields can be classified. For my client it shows what each customer costs to serve, which is commercially sensitive, and whether that falls inside the customer promise is the classification question still open.
The governance question is whether anyone did. What classification was assigned, what exposure justified it, and what turnaround follows from it? Routing an unclassified dataset to the strictest process is a defensible default under uncertainty. The failure is leaving the uncertainty unresolved: nobody is assigned to classify the export, and no clock runs on the decision.
An external adviser is a different principal from an employee, and that justifies a different process with a stated turnaround. Separate the read grant from anything else in the request. Then record the working days from that request to the first usable billing record, and compare the count with the organisation’s approved turnaround for data of that classification. For an APRA-regulated reader, CPS 234 requires the classification half of that diagnosis (information assets classified by criticality and sensitivity) and says nothing about turnaround.
Automation cannot resolve an undefined decision right
Oliver’s model of agent autonomy runs from a static rule at level 0 through read-only, analysis-only and drafts-only levels to level 4, Acts within Limits. Only the fourth changes production infrastructure under delegated authority, and delegated by whom is the question a roadmap has to answer.
Microsoft’s Entra Agent ID documents two models. A delegated agent cannot exceed the consenting user’s access. An autonomous agent holds application permissions an administrator granted directly, which means an agent can hold a permission no FinOps practitioner holds. NIST’s February 2026 concept paper on agent identity still lists delegation of authority and human-in-the-loop authorisation as open questions.
Technical permission and organisational authority are different things. An administrator can attach a stop-instances permission to an agent role before lunch, and the attachment says nothing about who decided the agent may stop instances, which instances, below what cost threshold, who owns an erroneous shutdown, or who can withdraw the mandate. Those are the Decide and Answer boundaries, and the agent has been handed Act without them.
AWS’s own preview FinOps Agent carries wide investigation rights across Cost Explorer, Compute Optimizer, CloudTrail and CloudWatch, plus bounded write rights over its own EventBridge rules. Its published IAM policy includes no workload-remediation actions such as stopping EC2 instances or modifying RDS instances. Act is scope specific, which is why the register needs a scope beside each row rather than a bare yes.
I do not know how wide a bounded mandate can safely be. The platform team’s existing unattended automation marks the consequence envelope the organisation has accepted. The decision envelope is a separate question, because a deterministic script and an agent choosing its own path fail differently. I would take the automation boundary as the outer ceiling, start the agent narrower, and widen its Act scope one register row at a time. Until the register has at least one row where Act is delegated to automation, an agentic cost tool improves your analysis and leaves your authority problem where it was.
Put the authority register on the next governance agenda
The diagnostic is a table with the four boundaries as columns. For each decision that matters to cost, record who may See the evidence, who may Decide, which identity may Act and who will Answer. Add the guardrail, the escalation path, and the scope an automated identity may hold.
My client’s first row is already filled in. See is pending. Decide is unresolved: the organisation has not named anyone to interpret the customer promise for this dataset. Act was never requested for any account with customers in it. Answer is unassigned. That is the row a bounded request has spent 16 working days sitting in, and the queue was built for something else.
An agent should hold Act only where an accountable role holds Decide and Answer for the same row, with a named current owner.
Then take every ambiguous row to the technology governance forum you already run and name the decision owner, the delegated scope, the limit, the escalation path, and whether an automated identity may act. The Foundation’s Executive Strategy Alignment capability asks the executive sponsor for this, so you are completing the Framework’s executive half. A register goes stale the month after whoever built it leaves, unless the forum that owns it sets the review cadence and keeps it. Every decision right FinOps depends on should be explicit before a person or an agent is expected to act on its findings.
Who holds Decide for your cost decisions?
Bring one cost decision that stalls between the finding and the fix, and we will work through who holds See, Decide, Act and Answer for it.
Book a Conversation