Mapping AI Interaction Monitoring to the OWASP Top 10 for LLMs

Interaction monitoring covers four of the ten risks in the 2025 Top 10 for LLMs and generative AI applications well, three partially and three not at all. The split is not arbitrary, and the line it follows tells a buyer more than the coverage count does.

‍

Monitoring observes systems being used. Several entries on the list describe defects in how a system was built, which no amount of observation at the point of use will surface. Knowing which side of that line each risk sits on decides what else a program has to fund.

‍

Which Risks Does Monitoring Cover Well?

‍

Four, each because the risk expresses itself as something observable in an interaction.

‍

Sensitive Information Disclosure

‍

Regulated categories appearing in a prompt are detectable before submission where classification runs on the device. The signal is content, the sources are the browser and the endpoint, and this is the single strongest case for interaction monitoring on the whole list.

‍

Excessive Agency

‍

An agent exceeding what a task required shows in the arguments it passed rather than in the tools it called. The signals are tool invocations and their parameters alongside the breadth of the grant, read from gateway logs and identity records together.

‍

Unbounded Consumption

‍

Abnormal volume is what monitoring is best at. Request rate, token counts and egress size from network and provider telemetry establish a baseline, and departures from it are visible without any semantic understanding of what was requested.

‍

System Prompt Leakage

‍

Where a leaked instruction returns in an output crossing a monitored path, content inspection catches it. Coverage is therefore conditional on the path rather than on the risk, which makes this the weakest of the four.

‍

Which Risks Are Partially Covered?

‍

Three, where monitoring sees part of the chain and something upstream stays dark.

‍

Supply Chain

‍

Which providers and components are in use is resolvable from a vendor catalog and from the grants recorded in a directory. A compromise occurring inside the supplier's own environment produces no customer-side record at all, so detection falls back to the behavior that follows it.

‍

Prompt Injection

‍

Direct injection typed by a user is content and therefore visible. Indirect injection arrives inside retrieved documents, web pages or tool outputs the monitoring layer never inspects, and that is the dominant form in practice. The mechanism itself explains why the two variants behave so differently.

‍

Vector and Embedding Weaknesses

‍

Access to a vector store is visible as identity activity. Whether retrieval returns content a requester should not see is a property of how the store was partitioned, which no interaction record describes.

‍

Which Risks Does Monitoring Miss Entirely?

‍

Three, and they share a property that explains the whole division.

‍

Data and Model Poisoning

‍

Corruption introduced during pre-training, fine-tuning or embedding happens before any interaction exists. What covers it is provenance over training data, controls on who can submit fine-tuning material, and evaluation of the model against held-out cases.

‍

Improper Output Handling

‍

Insufficient validation of model output by the consuming application is a software defect. The interaction looks ordinary from every vantage point, and what covers it is secure development practice, code review and output validation testing.

‍

Misinformation

‍

Establishing that an output is wrong requires knowing what right looks like. Monitoring records what was produced without evaluating it, so coverage comes from evaluation suites, ground truth comparison and human review designed into the workflow.

‍

What Does the Dividing Line Follow?

‍

Construction against use, which is the finding worth carrying away from the exercise.

‍

The Pattern

‍

Every risk monitoring covers well is a behavior exhibited while a system is used. Every risk it misses is a defect present in how a system was built. Partial coverage occurs where a build-side defect produces a use-side symptom, which it sometimes does and cannot be relied on to do.

‍

Why That Matters for Buying

‍

An organization consuming third-party AI has most of its exposure on the use side, so an interaction layer covers a large share of the list for it. An organization building and fine-tuning models carries exposure on both sides, and monitoring addresses only one.

‍

The Question to Ask First

‍

Which of the two you are, before asking which vendor to buy. The answer determines whether an interaction layer is most of a program or half of one.

‍

How Should the Mapping Be Recorded?

‍

As register entries with an owner each, since an uncovered risk without an owner is something nobody is working on.

‍

What Each Entry Needs

‍

The risk identifier, whether monitoring detects it, which signal and source would carry the detection where it does, and which control covers it where it does not. The fourth field is the one that makes the document useful rather than descriptive.

‍

Where It Belongs

‍

In the risk register rather than in a spreadsheet beside it, so treatment decisions and ownership sit with the entry. An AI risk register carrying framework mappings keeps the uncovered items visible at the same cadence as the covered ones.

‍

What It Prevents

‍

The common failure where a monitoring deployment is reported as framework coverage, and the three risks it never addressed quietly leave the conversation.

‍

How Does This Differ From the Agentic List?

‍

Different list, different subject, and the two get conflated frequently enough to be worth separating.

‍

What the Other List Covers

‍

Risks specific to agents taking actions rather than to applications generating output. The overlap is real at excessive agency and divergent almost everywhere else, since an agent's risk surface includes tool use, memory and coordination.

‍

Why Both Get Mapped

‍

An organization running assistants and agents faces both lists, and the monitoring coverage differs across them. Converting the agentic list into expected loss takes the same material in the direction of quantification rather than detection.

‍

What Should Be Established?

‍

Three things, and the first reframes the other two.

‍

Whether your organization primarily consumes AI or builds it, since that decides how much of the list an interaction layer can reach. Which signals and sources your current deployment collects today, checked against the four well-covered risks rather than assumed. Then who owns each of the three uncovered risks, because those need controls from development and evaluation rather than from security operations. Kovrr's AI Security and Governance Platform addresses the use side and records which sources carried each finding, which is what lets the coverage claim be checked rather than taken on trust.

‍

Monitoring Covers Use, Not Construction

‍

Four risks on the 2025 list are well covered by interaction monitoring, being sensitive information disclosure, excessive agency, unbounded consumption and system prompt leakage, each because it expresses itself as something observable while a system is used. Three are partial, where supply chain, prompt injection and vector weaknesses have upstream components no customer-side record describes, with indirect injection the most consequential of those blind spots. Three are missed entirely, since data and model poisoning, improper output handling and misinformation are defects in construction rather than behaviors in use. An organization consuming third-party AI therefore gets far more of the list from a monitoring layer than one building its own models.

‍

To see which signals and sources carry each detection in your own environment, book a demo mapped to your own estate.