AI FinOps should be jointly owned by finance, platform engineering, product, and security because the controls span cost, access, and usage. Security brings policy and identity context, finance brings measurement discipline, and engineering owns implementation. A siloed model creates the same fragmentation the programme is trying to remove.
Why This Matters for Security Teams
AI FinOps is not just a budgeting exercise. In a security-led programme, it is where usage telemetry, access control, and policy enforcement meet, and that makes ownership a governance decision as much as a financial one. If security is absent, cost controls often miss the real risk drivers: exposed credentials, excessive privileges, and uncontrolled tool access.
That matters because AI spend can be amplified by abuse. NHIMG’s LLMjacking research shows attackers can move quickly when secrets are exposed, and the same identity weaknesses that create fraud risk also create runaway consumption risk. Current guidance suggests cost management should be tied to identity, not treated as a standalone finance report. The NIST Cybersecurity Framework 2.0 reinforces the need to connect governance, asset visibility, and operational control rather than relying on after-the-fact reconciliation.
In practice, many security teams encounter AI cost overruns only after an abused key, an overbroad service account, or an unreviewed agent workflow has already driven the bill up.
How It Works in Practice
AI FinOps in a security-led programme works best when ownership is shared but accountability is explicit. Finance should define cost centres, forecasts, and chargeback rules. Platform engineering should instrument the workloads, because they control deployment patterns, caching, model routing, and usage metering. Security should own the policy guardrails that determine which identities, agents, and services may spend, call models, or access premium tools.
The practical model is to treat every AI workload as a metered identity-bearing service. That means mapping each model call, agent action, and external tool invocation to a workload identity, then attaching policy to that identity. Security reviews should focus on:
- who can invoke which model or agent
- what data can be sent to the model
- which spend thresholds trigger alerts or shutdown
- which secrets, tokens, or API keys are allowed for each workflow
- whether logs tie usage back to the owning team
This is where security and finance align instead of compete. Finance identifies abnormal spend patterns, while security checks whether the pattern reflects abuse, misconfiguration, or a legitimate product launch. The State of Non-Human Identity Security report is useful here because it shows how often organisations lack visibility into NHIs and how frequently poor rotation and over-privilege drive incidents. Best practice is evolving, but current guidance suggests FinOps controls should include identity review, not just budget alerts. That is also consistent with the NIST CSF 2.0 emphasis on governance and continuous monitoring.
These controls tend to break down when AI usage is spread across many teams with inconsistent tagging, because spend can no longer be attributed cleanly to an identity, service, or owner.
Common Variations and Edge Cases
Tighter cost controls often increase operational overhead, requiring organisations to balance visibility against developer friction. That tradeoff is especially real when teams are experimenting with agentic AI, bursty workloads, or shared platform accounts.
There is no universal standard for this yet, but several patterns recur. In product-led organisations, product management may own budget targets while security owns policy enforcement and engineering owns observability. In regulated environments, security may take stronger control because cost anomalies can indicate abuse, exfiltration, or policy violations. For internal platforms, a central AI platform team often becomes the operational home for spend dashboards and quota enforcement, with finance as the reporting authority.
Two edge cases matter most. First, shared model gateways can hide the true consumer unless every request is tagged at the identity level. Second, autonomous agents can generate high-frequency usage that looks like a spike but is actually normal execution. That is why security-led AI FinOps should focus on policy-based limits, exception handling, and kill switches rather than static monthly caps. The research published in DeepSeek breach also shows how quickly exposed secrets can turn into broader operational exposure, which makes ownership of usage and identity inseparable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | AI FinOps needs clear governance ownership across finance, security, and engineering. |
| NIST CSF 2.0 | DE.CM-01 | Usage telemetry and anomaly detection are central to spotting abuse-driven AI spend. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential rotation and exposure control directly affect AI cost abuse risk. |
Define AI cost governance roles and decision rights, then review them alongside security controls.
