Rate and cost monitoring, and auditing AI for quality and compliance

Why this matters

Lesson 15 watched individual interactions for signs of attack. This lesson watches the aggregate — how much, how fast, how expensive — and then steps back to ask whether the system is doing its job correctly, fairly and only for the people entitled to use it.

Volume and cost are security signals for AI in a way they rarely are for a web application. Every request consumes paid compute, so abuse shows up on an invoice before it shows up anywhere else. Unbounded consumption is LLM10 in the 2025 OWASP list; its 2023 predecessor was called model denial of service, and both describe an attacker, or a broken automation, driving cost and load until the service fails or the budget does. An agent stuck in a loop, calling a model and a tool thousands of times overnight, does the same thing with nobody attacking at all.

Auditing is the slower loop. A model can be secure in every sense of lessons 9 to 15 and still give wrong answers, treat groups of users differently, or be reachable by people who should have lost access months ago. Those are quality and compliance failures, and regulators, customers and auditors will ask for evidence about them. On the exam, scenarios in this area usually turn on which measurement would have revealed the problem, and who should have acted on it.

The lesson

Rate monitoring as an early warning of abuse and of runaway automation

Lesson 10 set rate limits, which stop traffic. Rate monitoring watches traffic below and approaching those limits, which is where most of the information is: an attacker who knows the limit stays just under it.

Measure rates along several dimensions, because each catches something different:

• Requests and tokens per identity — per user, API key, application and agent. A single key whose token use rises tenfold is a stolen key, a leaked key embedded in a public app, or a new integration nobody announced.
• Requests per source — address, network, device — catching distributed abuse spread thinly across many accounts.
• Requests per pattern — many near-identical prompts with systematic variations is what model extraction and guardrail probing look like (lesson 19 describes extraction); many prompts at the maximum context length is what a resource-exhaustion attempt looks like.
• Tool calls per agent run — the clearest signal of runaway automation. An agent with ticket and email tools that normally makes four calls per task and has made four hundred on one task is looping, being steered, or both.
• Errors and refusals per identity — a rising refusal rate for one user is someone testing the guardrails.

Alert on rate of change as well as on thresholds, and against the per-application baseline from lesson 15. Pair alerts with an automatic response proportionate to the risk: throttle the key, pause the agent run, require re-authentication, or cut off a session. For agents, a hard ceiling on calls and spend per run is the backstop that makes the monitoring survivable at three in the morning.

AI cost monitoring across prompts, storage, responses and processing

Cost has four components, and abuse or waste can hide in any of them.

Prompts (input). Hosted models usually charge per input token. Input cost grows with context: a RAG app that retrieves twenty chunks instead of five, or a chatbot that resends the whole conversation history on every turn, multiplies input tokens for every request. A sudden rise in average input tokens with steady request counts points at a prompt template change, a retrieval misconfiguration, or deliberate padding.

Responses (output). Output tokens are commonly priced higher than input tokens, and output length is partly under the requester's control. Prompts that induce very long or repetitive responses are a cost attack; the maximum output token limit is the control, and the share of responses that hit it is the metric.

Storage. Vector stores, embeddings of every document version, fine-tuned model copies, checkpoints, conversation history and prompt logs all cost money to keep, and they grow quietly. Storage cost rising without a matching business reason is often data being retained beyond its purpose, which is a minimisation finding (lesson 14) as much as a cost one.

Processing. GPU time for self-hosted inference, embedding jobs, fine-tuning and evaluation runs, plus the compute behind tool calls an agent makes. An embedding job re-indexing the entire corpus every night, or a fine-tuning job someone left running, appears here.

The controls are familiar from cloud financial management, applied with AI in mind:

• Attribute every cost to an application, team and identity, through tags, separate keys or a gateway that records token counts per caller. Unattributed spend cannot be investigated.
• Budgets and alerts at several levels — per key, per application, per agent run, per day — with alerts going to the owner rather than to finance at month end.
• Quotas enforced at the gateway, so a budget is a limit and not just a report.
• Unit metrics such as cost per conversation or cost per resolved ticket, which reveal waste that totals hide.

The scenario signal is usually an unexpected bill or a quota exhausted early. The answer is attribution first — finding which identity or application drove it — and then the limit that should have contained it.

Auditing for hallucinations and accuracy against a known answer set

A hallucination is a fluent, confident output that is not supported by the model's sources or by fact. Accuracy is the broader measure of how often the system's output is correct for its task. Both are audited the same way: compare output to something you already know is right.

Build a known answer set — sometimes called a golden set or reference set — of representative questions with verified answers, drawn from the application's real use. For the RAG app over HR documents, that means policy questions whose answers a person has checked against the current documents, including questions whose correct answer is "the policy does not say". Then run it:

• Before release and after every change to the model, prompt template, retrieval settings or document corpus, because any of them can shift accuracy.
• On a schedule in production, because hosted models change underneath you and documents go stale.
• On a sample of real interactions, reviewed by people, because a fixed set ages and users ask things nobody anticipated.

Measure separately: correct answers, wrong answers, answers unsupported by the retrieved documents (hallucinations proper), correct refusals, and unnecessary refusals. A system can cut its count of wrong answers by refusing more, which is why refusals are counted on both sides. Automated scoring — exact match, overlap measures, or another model acting as a judge — scales the work, but a judge model has its own error rate, so calibrate it against human-marked samples.

Results feed the confidence signals in lesson 15, and the guardrail testing in lesson 9. They are also the evidence against overreliance: if users treat the system as authoritative, the organisation needs to know how often it is wrong.

Auditing for bias and fairness, and for who had access

Bias and fairness auditing asks whether the system's outputs or error rates differ across groups of people in ways that are unjustified. The method is disaggregated evaluation: run the known answer set, or a purpose-built test set, and break results down by group. A CV-screening assistant that is accurate overall but rejects qualified candidates from one group more often has a fairness problem the overall score hides. Common fairness measures compare selection rates across groups, or compare error rates — false positives and false negatives — across groups; they can conflict, and choosing which one matters is a governance decision recorded in advance, not a technical default.

Practical techniques include counterfactual testing, where the same input is submitted with only a protected characteristic or a proxy for it changed, such as a name or a postcode, and the outputs are compared. Bias can enter through training data, retrieval sources, prompt templates and feedback loops, so a finding needs tracing to its source. Lesson 30 covers the principles behind fairness; lesson 18 covers bias introduced deliberately.

Access auditing asks whether the right people, and only they, used the system and its data. It draws on the logs from lesson 15 and the controls from lessons 11 and 12:

• Who used each model and application, compared with who is entitled to. Leavers, role changes and expired contractors with live keys are the classic findings.
• Who retrieved which classified documents through the AI system, which is often the only record of that access, because the user never opened the document directly.
• Which agents and service identities called which tools, and whether the approvals required for sensitive actions were actually given.
• Who read the prompt logs, since those reads are access to sensitive data too.
• Which API keys exist, enumerated from the platform rather than from the record, with an owner and expiry for each.

Compliance obligations, including those under the EU AI Act for high-risk systems (lesson 32), make this evidence something an organisation must be able to produce, not merely something good practice suggests.

Turning monitoring findings into tickets somebody owns

Monitoring that produces dashboards and no action is the most common failure in this objective, and scenarios describe it often: the cost alert that went to a shared mailbox, the accuracy drop on a dashboard nobody opened, the bias finding in a report with no recipient.

Every AI application needs a named owner — the person accountable for its behaviour — and every alert and audit finding needs a route to that owner as a ticket with:

• What was found, with the evidence: log references, the failing test cases, the cost breakdown.
• Severity, set by agreed criteria, so that a data disclosure outranks a formatting regression.
• An owner and a due date, which is what separates a ticket from a note.
• The control to change: a rate limit, a prompt template, a retrieval filter, an access group, a retraining job.
• Verification: the test that will show it is fixed, ideally added to the known answer set so the regression cannot return silently.

Security-relevant findings — disclosure, injection, abuse — go into the incident process as well. Recurring findings feed the risk register and the governance reviews in lesson 28. The test of the whole system is simple: for any alert, can you name who acted on it and what changed as a result?