Enterprise billing complexity exposes the limits of simple monetization

At a glance

What this is: This is WorkOS's ERC 2025 recap of Metronome's demo, showing how modern enterprise billing now depends on real-time usage streams, flexible contracts, and scheduled pricing changes.

Why it matters: IAM practitioners should care because the same shift from static to runtime-controlled systems is reshaping non-human identity governance, delegation, and lifecycle control across enterprise platforms.

👉 Read WorkOS's ERC 2025 recap of Metronome's enterprise billing demo

Context

Enterprise billing has moved beyond seat-based subscriptions and into hybrid consumption, outcome-based pricing, and real-time usage visibility. That creates a governance problem that looks familiar to identity teams: the system must adapt to changing state without breaking accountability or control.

In this kind of architecture, a contract is no longer a static document. It becomes a live policy surface where entitlements, timing, and business terms change continuously, which is why identity, access, and lifecycle disciplines are increasingly relevant even outside traditional IAM stacks.

Key questions

Q: How should security teams govern systems where business rules change in real time?

A: Treat them as runtime policy surfaces, not static configuration. Require versioned state, clear event lineage, and precise effective dates so every automated decision can be traced back to the rule that applied at that moment. If the platform cannot explain its timing, it cannot support reliable governance or audit.

Q: Why do scheduled changes create governance risk in enterprise platforms?

A: Scheduled changes can overlap with live activity, which means the system must know exactly which rule was active at each point in time. Without versioning and auditability, teams cannot prove why a charge, entitlement, or control decision happened. The risk is not scheduling itself, but ambiguous enforcement during the transition.

Q: What breaks when automated decisions rely on batch reconciliation?

A: Batch reconciliation is too slow for processes that affect money, access, or fraud exposure in real time. Once the active session ends, the system may already have accepted excess usage or applied the wrong term. Governance fails when the control only sees the outcome after the decision window is closed.

Q: How do teams know if runtime controls are actually working?

A: They should be able to trace a decision from source event to applied rule to final outcome without gaps. If that lineage is incomplete, the control may look correct in reports while failing in practice. Real governance shows up in explainable timing, not just in end-of-period summaries.

Technical breakdown

Real-time usage streams as the billing source of truth

Metronome's demo treated billing like an observability pipeline. Instead of issuing discrete billing commands, the platform ingests raw product events such as API calls, CPU seconds, or bytes stored, then groups and sums them into contract-specific views. That architecture matters because it separates event capture from pricing logic, allowing invoice calculation to occur continuously as usage arrives. The result is a system where state changes are always relative to the underlying stream, not a manually reconciled ledger. For identity and governance teams, the lesson is that runtime attribution depends on trustworthy event lineage, not just final outputs.

Practical implication: define which event sources are authoritative before any downstream pricing, entitlement, or access decision is automated.

Atomic contract changes and scheduled policy enforcement

The demo showed that contracts can be edited atomically and scheduled to take effect on a specific date, with discount logic changing mid-cycle and invoice calculations updating immediately. Technically, that means the platform supports versioned contract state rather than a single frozen billing rule. This is the same architectural pattern seen in policy engines and access systems that need effective dating, staged rollouts, and auditability. The hard part is not making changes possible, but preserving exactness when multiple rules overlap across time. Systems without that discipline drift into ambiguous enforcement, which is where disputes and governance failures begin.

Practical implication: require versioned policy state and effective-dated changes anywhere a runtime system can alter obligations or access conditions.

Usage-based monetization depends on fast balance calculation

Cosmo's point about real-time fraud detection and prevention highlights a key mechanism: once usage is streamed continuously, the platform can compute balances in subseconds rather than at batch close. That speed allows the system to react to thresholds while the customer session is still active, which is operationally very different from end-of-day reconciliation. In identity terms, this resembles enforcement that must occur during execution, not after the fact. When the control surface is delayed, the cost of abuse rises because the system only learns about overuse after exposure has already happened.

Practical implication: design controls that can evaluate usage and trigger action during the active session, not only in post-event reporting.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime contract systems create a governance pattern that identity teams already know from NHI management. Once entitlements, pricing, or discounts can change in-session, the control problem shifts from static approval to state-aware enforcement. That is the same basic pressure seen in service account governance, where the key question is not whether access exists, but whether it is still valid at the moment of use. Practitioners should treat live contract surfaces as governed runtime state, not back-office configuration.

Atomic and schedulable changes are only safe when the underlying policy model is versioned. The demo's emphasis on scheduled discount changes shows that business terms now need the same kind of temporal precision that lifecycle controls demand in IAM. If a platform cannot explain which rule applied at which moment, accountability collapses even if the invoice itself is technically correct. Practitioners should insist on auditable state transitions wherever commercial logic changes over time.

Usage-based models expose a broader identity lesson: policy that reacts too late is not governance. Real-time fraud prevention depends on seeing the correct event, attributing it properly, and evaluating it before the transaction closes. That mirrors modern privilege and delegation control, where delayed review cannot prevent abuse that already completed. Practitioners should align control timing with the speed of the business process, or accept that governance will lag behind impact.

Flexible monetization is becoming a proxy for broader enterprise readiness. The move from simple billing to hybrid, outcome-based, and usage-based models signals that more business systems now depend on dynamic entitlement logic. That does not make billing an IAM problem, but it does mean the same governance questions are surfacing across commercial platforms, access systems, and machine-driven workflows. Practitioners should look for shared control patterns rather than isolated process fixes.

Identity blast radius is not limited to access systems when runtime state can change the business outcome. In a live contract platform, a misapplied rule can alter revenue recognition, customer charges, or fraud exposure within seconds. The named concept here is runtime policy surface: a system where operational rules act like live authorization decisions. Practitioners should recognise that any runtime policy surface needs stronger lineage, timing, and audit discipline than static configuration ever did.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which means governance still depends heavily on behaviour as well as tooling.
• For a broader identity view, read NHI Lifecycle Management Guide for the rotation, offboarding, and visibility discipline that runtime systems need.

What this signals

Runtime billing is a useful reminder that governance is moving closer to the moment of execution. Runtime policy surface: when commercial rules, entitlements, or thresholds can change during an active session, the control model needs the same precision that identity teams demand from lifecycle-managed access. The practical signal is clear. If your programme cannot explain state at a specific moment, it is already behind the operating model.

With 27 days to remediate a leaked secret in our research, most organisations are still operating with response windows that are too slow for runtime systems. That gap matters beyond secrets alone, because the same delay problem appears wherever policy decisions are made after the business event has already closed. Teams should expect more shared pressure across IAM, PAM, and operational governance.

The next step is to treat timing as a control dimension, not an implementation detail. Once a system can schedule changes, recalculate outcomes instantly, and shift pricing or entitlement state mid-cycle, access governance and business governance start to share the same failure modes. Teams that already use the NHI Lifecycle Management Guide as a lifecycle reference should extend that discipline to any platform with live policy state.

For practitioners

• Map all runtime policy surfaces Identify where business rules can change live, including pricing, entitlements, discounts, and thresholds. Treat those surfaces as governed state and require clear ownership, change history, and rollback paths.
• Require event lineage for every automated decision Make raw event provenance visible before downstream actions are taken. If a platform cannot trace the source event to the resulting decision, the control model is too weak for audit or dispute handling.
• Version scheduled changes and effective dates Ensure that time-based changes are stored as versioned policy transitions, not overwritten configuration. That lets teams explain which rule applied during a specific customer session or billing cycle.
• Align enforcement timing with business velocity Use controls that act while the session or transaction is still active. Post-event review may support reporting, but it will not contain impact when the business process closes quickly.

Key takeaways

• Enterprise billing is becoming a runtime governance problem, not a back-office reconciliation exercise.
• The scale of the control challenge is visible in how quickly organisations still struggle to remediate secret exposure and behavioural gaps.
• Practitioners should focus on event lineage, versioned state, and enforcement timing wherever live policy can change outcomes.

Key terms

• Runtime Policy Surface: A runtime policy surface is any system area where rules can change live and immediately affect behaviour, pricing, access, or enforcement. The important feature is not the interface itself, but the fact that decisions are made against current state rather than fixed configuration, which raises the bar for lineage and auditability.
• Event Lineage: Event lineage is the trace from an originating action to the downstream decision or outcome it produced. In governed systems, it lets teams prove why something happened, which rule applied, and whether the result was consistent with policy at that moment.
• Effective-Date Governance: Effective-date governance is the practice of controlling when a rule or contract term starts and stops applying. It is essential in systems where state changes during an active cycle, because without precise timing, teams cannot separate intended change from accidental overlap.
• Real-Time Enforcement: Real-time enforcement means a system evaluates conditions while the transaction or session is still active, rather than after the fact. For governance programmes, this is the difference between preventing a harmful outcome and only reporting it later.

Deepen your knowledge

Runtime policy surfaces and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already dealing with live contract state, usage-based controls, or scheduled policy changes, this course is a practical next step.

This post draws on content published by WorkOS: Metronome's Lightning Demo on building enterprise-ready monetization in real time at ERC 2025. Read the original.