"AI risk" gets used to describe everything from a chatbot giving a wrong answer to an autonomous agent draining a budget. That range is part of why security conversations about AI systems go in circles: two people can use the same phrase to mean genuinely different problems that need different owners and different controls.
A useful taxonomy does not need to be exhaustive. It needs to sort risks into groups that map to who fixes them and how. Five groups cover most of what shows up in practice: model behavior, data exposure, tool and action risk, supply chain, and operational gaps. None of these are new categories invented for AI, but each one behaves differently once a model is involved.
Model behavior risk
This is the risk that the model itself produces an output that is wrong, harmful, biased, or manipulated. It includes hallucinated facts presented with full confidence, outputs that violate a stated policy, and responses shaped by prompt injection or jailbreak attempts.
What makes this category distinct is that the failure often looks syntactically fine. A hallucinated citation is a well-formed sentence. A policy violation triggered by prompt injection can read like an ordinary, helpful answer. Traditional input validation does not catch this because nothing about the input or output is malformed. The fix lives in evaluation, output review, and constraining what the model is allowed to state or do regardless of how it was convinced to state or do it.
Teams underestimate this risk when they test only for obviously broken outputs. The more damaging failures are confident, plausible, and wrong, or confident, plausible, and exactly what an attacker wanted.
Data exposure risk
This is the risk that information ends up somewhere it should not. Sources include prompts that carry sensitive customer data into a model context, retrieval systems that surface records outside the requesting user's permissions, model responses that echo details from another user's session in a shared or misconfigured deployment, and logs that retain full prompts and responses well past any reasonable retention need.
Data exposure risk in AI systems is often worse than in conventional applications because the model concentrates data from multiple sources into a single context window, and then produces a natural-language summary of it that can be easy to misjudge as safe simply because it reads fluently. A model summarizing three internal documents does not announce which document a given sentence came from, or whether the requester was allowed to see all three.
Controls here look like data governance: classify what can enter a prompt, apply access control before retrieval rather than after generation, redact or tokenize sensitive values, and set explicit retention limits for logs and traces that capture model input and output.
Tool and action risk
Once a model can call a tool, risk moves from "wrong words" to "wrong actions." This category covers unauthorized or excessive actions taken by an agent, whether from a manipulated model, an over-broad tool permission, or a missing approval step for high-impact operations.
The severity of this category scales directly with what the tool can do. An agent that can only read public documentation carries limited action risk even if fully compromised. An agent that can issue refunds, modify infrastructure, or send messages on a company's behalf carries action risk that deserves the same scrutiny as giving a new employee production access on day one, because in both cases, the actor's judgment is the only thing standing between a request and its execution.
Mitigating this risk means treating tool calls as privileged operations: narrow scopes, server-side limits, mandatory approval for irreversible actions, and a record of what was requested, what was decided, and why.
Supply chain risk
AI systems depend on models, weights, fine-tuning data, embeddings, vector databases, prompt libraries, and third-party agent frameworks. Each of these is a dependency in the traditional software sense, and each one can introduce risk the way any dependency can: a poisoned fine-tuning dataset, a compromised model checkpoint, a vector database with weak isolation between tenants, an agent framework with an insecure default.
This risk is easy to miss because AI supply chains are newer and less standardized than package registries most security teams already monitor. There is no universal equivalent of a vulnerability database for "this fine-tuned model was trained on a dataset with a known poisoning issue." Teams have to build their own inventory of AI-specific dependencies and apply the same due diligence they already apply to software dependencies: know what you're using, know where it came from, and have a plan for when a component turns out to be compromised.
Operational risk
The last group covers the gap between a working prototype and a governed production system. It includes deploying models without monitoring, without version tracking, without a documented owner, and without an incident process that accounts for AI-specific failures. It also includes the slower failure mode where a model, prompt, or knowledge base is updated and nobody re-runs the security evaluations that passed before the update.
Operational risk is often the least technical category and the most common root cause when an incident review asks "how did this go unnoticed for so long." A system can have reasonable model behavior controls, tight data handling, and narrow tool scopes, and still fail here if nobody is watching production behavior or nobody owns the decision to intervene when something looks wrong.
Using the taxonomy
The value of sorting risks this way is assigning ownership. Model behavior risk usually needs evaluation and prompt or policy engineering. Data exposure risk needs data governance and access control work. Tool and action risk needs application security and product decisions about what autonomy is acceptable. Supply chain risk needs the same vendor and dependency management discipline already applied elsewhere, extended to cover models and AI-specific components. Operational risk needs monitoring, ownership, and a re-test process tied to changes.
When a new AI feature is proposed, running through these five groups and asking "what's our exposure here, and who owns it" surfaces gaps faster than a general conversation about "AI risk," because it forces a specific answer instead of a general worry.
Where TELEON fits
TELEON's runtime policy enforcement and audit trail are most directly relevant to tool and action risk, since that is where a policy decision at the moment of a tool call has the clearest effect. Where TELEON is deployed through the gateway or supported middleware, it can also contribute to operational risk reduction by giving teams a consistent record of agent activity to monitor and investigate.
It is not a control for model behavior, data governance, or supply chain risk on its own. Those categories still need evaluation practices, access control design, and dependency management that sit outside any single runtime tool.
A short risk-sorting exercise
- For each AI feature, list its risks under the five categories above.
- Name an owner for each category, not just for the feature as a whole.
- Check whether tool and action risk is bounded by permissions and
approval, not only by prompt instructions.
- Confirm someone re-runs evaluations after a model, prompt, or knowledge
base change.
- Confirm there is a documented way to detect and stop misbehavior in
production.
A taxonomy is only useful if it changes what a team does next. Sorting AI risk into these five groups gives teams a concrete way to divide the work, instead of treating "AI security" as one undifferentiated problem that nobody quite owns.