How should organisations control AI usage when token-based pricing starts driving up cost and risk at the same time?

Organisations should treat AI usage as both an expense and a control surface. Start by measuring where AI is used, who is using it, and which workflows consume the most tokens. Then enforce governance around approved tools, usage thresholds, and human review for high-risk outputs. Visibility is the foundation for controlling AI cost, reducing waste, and limiting hidden security exposure.

Why This Matters for Security Teams

Token-based pricing turns AI usage into a direct financial control problem, but it also changes the security profile of every workflow that touches a model. High-volume prompting, uncapped agent loops, and shadow AI tools can burn budget quickly while also expanding the surface for prompt injection, data leakage, and uncontrolled retention. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames governance, inventory, and continuous monitoring as operational requirements rather than optional hygiene.

NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly uncontrolled technology usage creates hidden exposure, and the same pattern applies to AI consumption when teams adopt tools faster than policy can follow. When organisations treat token spend as a billing issue alone, they miss the fact that spend often rises because the wrong people, systems, and workflows are using AI in the first place. In practice, many security teams discover runaway AI cost only after sensitive content has already been sent to unapproved services.

How It Works in Practice

Effective control starts with visibility: identify which employees, applications, and automated workflows are calling AI services, then map those calls to business purpose, data sensitivity, and owner approval. That inventory should include direct user prompts, API-driven integrations, agentic workflows, and any middleware that brokers model access. Without that picture, token pricing becomes a proxy for hidden risk rather than a manageable metric.

From there, organisations should define usage guardrails that are both financial and security-oriented. That usually means approved model catalogues, per-team or per-workflow token budgets, alerts for unusual spikes, and review steps for prompts that involve regulated or confidential data. Cost controls work best when paired with data loss prevention, logging, and access controls, so that the same event that triggers a budget alert can also trigger a security review. NHIMG’s 2025 State of NHIs and Secrets in Cybersecurity is a useful reminder that identity and token governance are already weak points in many environments.

For higher-risk uses, organisations should require human approval or stepped-up review before the model can act on customer data, production changes, or external communications. Cost allocation also matters: chargeback or showback helps reveal which teams are consuming tokens efficiently and which are generating waste through repeated re-prompting or poorly scoped agent tasks. The strongest programmes tie usage policy to identity, so that service accounts, application tokens, and human users all have separate limits and audit trails. NHIMG’s Salesloft OAuth token breach is a practical example of how token abuse can become both an access issue and a business disruption. These controls tend to break down when AI is embedded in unmanaged browser extensions, ad hoc scripts, or third-party connectors because usage then escapes central logging and ownership.

Common Variations and Edge Cases

Tighter AI controls often increase friction for teams that rely on rapid experimentation, so organisations have to balance cost containment against developer productivity and business agility. Current guidance suggests using tiered controls rather than a single global restriction: low-risk internal drafting can be governed with light monitoring, while customer-facing, regulated, or agentic use cases need stronger approval, shorter session limits, and mandatory logging.

One common edge case is shared service usage. If a single application or automation platform fans out to multiple models, the organisation may see one large token bill without clear attribution to the real business owner. Another is “helpful” re-prompting by users who are trying to get around poor output quality; this drives spend up without improving outcomes and often signals a workflow design problem rather than a training problem. The same applies to agentic systems that loop until they reach a goal: they can consume tokens unpredictably and require explicit ceilings, cancellation rules, and escalation thresholds.

There is no universal standard for token thresholds yet, so organisations should calibrate limits to data sensitivity, user role, and workload type rather than copying a generic industry benchmark. The practical goal is to make every expensive AI action visible, attributable, and reviewable before it becomes both a cost overrun and a security incident.

Related resources from NHI Mgmt Group

• What should organisations do when software sprawl starts driving cost and risk?
• Why do token-based leaderboards create risk when organisations try to measure AI productivity?
• What breaks when organisations rely on ad hoc access control for APIs and AI agents?
• Why does data lineage matter when organisations are trying to control sensitive data risk?