A company can pay for AI work it never requested. If criminals obtain the credentials used by an application to access an AI service, they may run their own requests on the company's account. An unusually high invoice can be the first indication that something is wrong.
This is a security and business-continuity decision, not just a question of setting an AI budget. Norwegian management teams should know which services can generate charges, who receives unusual-usage alerts and who can suspend access without waiting for the next working day.
What investigators found
In a report published on 2 November 2026, Google's Mandiant team describes investigations in which attackers hijacked organisations' access to large language models. Mandiant says it observed fraudulent consumption charges exceeding USD 100,000 in a day in individual incidents, with cumulative charges at some organisations reaching USD 1 million before access was revoked.
Those are Mandiant's observations from incidents it investigated. The report does not establish how common such losses are, what every customer ultimately paid, or how likely a particular Norwegian business is to be affected. It describes incidents across several providers and regions, not a representative survey of Norwegian companies. The large figures are a reason to check exposure, not a forecast for an ordinary account.
The team calls the practice LLMjacking. In the cases it investigated, stolen or exposed cloud identities and credentials were a dominant route into the environment. Attackers could use that access to reach AI resources or create additional access. A stolen key can therefore be both an unexpected cost and a sign that a wider account needs investigation.
This risk especially concerns services that call models through an application programming interface, or API. An API key is a secret that allows software to make those calls. A company that only uses an ordinary employee chat subscription should still protect its accounts, but should not assume the same billing or technical controls apply to every product.
A spending alert is not necessarily a spending limit
The distinction is easy to miss. A notification says that a threshold has been reached. It does not necessarily stop the service.
Google Cloud's billing documentation says an alerts-only budget does not automatically cap usage or spending. Microsoft's Azure budget guidance similarly says budget notifications do not themselves stop consumption. Both providers describe additional measures and automation that may be available, depending on the service and setup.
OpenAI's API documentation distinguishes an alert from an optional enforced monthly spending limit. When an applicable hard limit takes effect, affected requests fail. Enforcement is not instantaneous, so recorded spending can exceed the configured amount slightly. Controls, billing scopes and contract terms differ. Verify the actual product and account your company uses rather than assuming another provider's setting works the same way.
A hard stop has a business cost: a legitimate customer service may stop too. The right choice is not automatically the lowest limit. Management should decide which services need a hard limit, who may change it, how quickly alerts are acted on and what happens to customers if the service becomes unavailable.
Test a decision before the bill arrives
Consider a hypothetical Norwegian company that uses an AI API to draft responses for its customer service team. Its normal expected cost is 15,000 kroner per month. Management sets an internal alert at 20,000 kroner and an enforced limit of 30,000 kroner, if the provider and account support such a limit. These are illustrative amounts, not recommended thresholds or Mandiant's incident figures.
The provider's alert is sent to a shared finance inbox. On Friday evening an API credential is stolen and usage rises quickly. If no one reads that inbox until Monday, the alert does not produce a response. If the hard limit is reached, the drafting service may stop, and the final amount may differ because of reporting and enforcement delays.
A better arrangement starts before that happens. The service owner and finance team should agree who receives an alert, who can reach the technical provider, who can disable the affected credential and what customer service does while access is restored. Test the notification route with a safe, authorised test. Do not expose or send an actual secret in an email to prove the route works.
An alert at 20,000 kroner is not a guarantee that losses stop there. Equally, a limit at 30,000 kroner is a deliberate availability trade-off, not proof that the underlying account is secure. Check what it covers and how fast it takes effect under the actual agreement.
Limit what one stolen credential can do
Ask the technical owner or supplier to identify the AI services used for production and the credentials or cloud identities that can operate them. Record an owner and the business service dependent on each one. Separate development from production where practical, remove access that is no longer needed, and give each workload only the permissions it needs.
Do not put live API keys in a browser application, a public code repository or ordinary documents. Use the provider's supported secret-management approach and restrict access to the people and services that need it. A key that was briefly exposed in code should be treated as compromised even if the text was later removed.
Prepare replacement as well as revocation. OpenAI's API key guidance describes issuing a replacement, updating the workload, verifying it and revoking the old key. During an active compromise, the incident team may need to revoke access immediately before replacement is ready. The safe order depends on the situation and the cost of leaving access active.
If unusual usage is suspected, preserve relevant logs securely, contact the provider and follow the incident plan. Investigate whether the compromised identity also opened access to data, other credentials or additional services. Changing a single key is not evidence that the original access route has been closed. Contact customers or authorities when the circumstances and applicable duties require it; the financial alert alone does not establish a reportable personal-data breach.
Put a named owner between finance and technology
Management should give finance and the technical owner a shared view of the important accounts: expected spend, who can approve higher usage, which alerts are active and who can act outside office hours. Ask the supplier whether charges can continue after an alert, whether there are delay or scope limitations, and how to suspend and restore each affected service.
For a small AS, start with the account behind one important customer-facing workflow. For a business using several cloud providers, do not assume one budget covers every subscription, model or supplier. Include the cost of investigating alerts and maintaining a fallback when assessing the business case. The guide to AI usage allowances addresses a different problem: legitimate usage exhausting a product allowance. Both ordinary demand and misuse can interrupt work.
The board should ask whether management can demonstrate that material AI spending and access have owners, that a serious anomaly reaches someone able to act, and that critical services have a workable response. It should not manage individual keys or approve every threshold.
At the next supplier meeting, ask for one demonstration: If this AI account starts generating unexpected charges tonight, who is alerted, who can stop it and what happens to customer work?
Sources checked 4 November 2026. The Norwegian company and NOK amounts are hypothetical. Mandiant's figures are attributed to its investigations, not a national estimate. Product settings and contracts can change. The illustration is AI-generated.