TMG Agentic AI Risk Classification Framework

A structured way of classifying the security risks introduced when an AI system moves from producing text to taking autonomous action.

TMG Security Research Team  ·  Version 1.0  ·  Published 07 Sep 2026  ·  Last updated 07 Sep 2026

Executive summary

Agentic AI systems don’t just answer questions — they take actions on systems, with credentials, memory, and plans they generate themselves. That shift changes what can go wrong: a compromised agent can perform an unauthorized action, not just produce a wrong answer. The TMG Agentic AI Risk Classification Framework organizes this risk into eight classes — from goal hijacking to cascading failure — each traced to a specific way the attack surface expands (tool access, memory, autonomous planning, delegation, and inter-agent communication), and each mapped to a concrete defensive control and test. It builds on established work from OWASP, MITRE ATLAS, and NIST — it is TMG’s own organizing lens on that shared foundation, not a replacement for it or a claim of an industry standard.

Framework overview

Why agentic AI changes the attack surface

The difference between a chatbot, an LLM application, and an AI agent is not just capability — it’s what each one holds, and what a failure in each one can actually do:

Each stage inherits the risks of the one before it and adds its own.

The 5 attack-surface-expanding properties

Five properties do most of the work in enlarging what an agent can affect:

1. Tool access — the agent’s effective privilege is the union of all tool privileges available in the current conversation. If tools execute under one service account, that union is the same for every user, regardless of who is asking.
2. Persistent memory — memory turns a transient influence into a durable one. Content injected in one session and stored can shape behaviour in later sessions, potentially for other users if memory is shared.
3. Autonomous planning — the agent decomposes a goal into steps nobody wrote and nobody reviewed. A control applied at the point of the user’s request doesn’t necessarily apply to a step the model generated at runtime.
4. Delegation and identity — when an agent calls a tool, which identity does that call carry? If the answer is the agent’s own, user-level authorization has been lost at the first hop.
5. Inter-agent communication — multi-agent systems pass content between components. Without preserved provenance, an agent has no way to distinguish a peer’s reasoning from content that peer merely retrieved from an untrusted source.

The 8 risk classes

Each class below is defined, traced to the attack-surface property it originates from where the source article establishes that connection, and mapped to its primary defensive control(s) and testing consideration(s).

Defensive model

Design principle: a fully compromised model — one following an attacker’s instructions perfectly — should still be unable to perform an action the requesting user was not entitled to perform. If that property doesn’t hold, the authorization boundary is in the wrong place.

1. Least privilege at the tool layer — scope each tool to the narrowest capability that satisfies its purpose.
2. Propagate user identity — tool calls should carry the requesting user’s identity so downstream authorization evaluates the correct subject.
3. Deterministic policy enforcement — whether an action may proceed is decided by a policy engine, not the model’s judgement. The model chooses intent; policy decides permission.
4. Human approval for high-impact actions — irreversible, financial, or externally-visible actions should require confirmation showing the concrete action and parameters.
5. Validate at both ends — treat tool inputs as untrusted because the model produced them, and tool outputs as untrusted because an external system produced them.
6. Segment memory — scope by user and tenant. Be explicit about what may persist and for how long.
7. Preserve provenance — track where each piece of context originated so trust decisions can be made on the source rather than the format.

Plus two operational controls:

• Audit every invocation — log the tool, parameters, requesting identity and outcome. Without this, incident response has no reconstruction path.
• Constrain the blast radius — rate limits, spend caps and per-session action budgets bound the damage of a plan that goes wrong.

Testing considerations

1. Inventory tools per conversation state; availability often changes as a plan progresses.
2. Test each tool directly, with a low-privilege account, bypassing the agent entirely.
3. Determine which identity reaches the downstream system on a tool call.
4. Establish whether memory is scoped per user, and whether it survives a session boundary.
5. Trace content provenance through multi-agent hops.
6. Confirm approval gates cannot be satisfied by the agent itself.
7. Review logs for whether a full action chain could be reconstructed after an incident.

Risk class → defensive control → testing consideration

This is TMG’s proposed mapping, built by matching each control’s own stated purpose in the source article to the risk class it addresses.

Hypothetical worked example

A support agent is given three tools: look up a customer’s order, issue a refund, and send an email. It reads incoming customer emails, plans a response, and can act without a human reviewing every step.

Applying the framework:

• Attack-surface properties in play: tool access (three tools, one shared service identity), autonomous planning (the agent decides which tools to call and in what order), delegation and identity (do the order-lookup and refund calls carry the customer’s identity, or the agent’s own?).
• Risk classes this raises: a crafted email could attempt goal hijacking (instructions embedded in the email body redirect the agent toward issuing a refund it wasn’t asked for); if the refund tool call carries a shared service-account identity rather than the specific customer’s, that’s identity and privilege abuse; if the agent can call the refund tool for any order rather than only orders tied to the requesting customer, that’s excessive agency.
• Defensive controls that apply: human approval for high-impact actions (a refund is exactly the kind of financial, externally-visible action the framework flags for confirmation); propagate user identity (the refund call should carry the customer’s identity, not the agent’s); least privilege at the tool layer (scope the tool to that customer’s own orders rather than any order in the system).
• Testing considerations that apply: test the refund tool directly with a low-privilege account to see whether it enforces the same restriction the agent is assumed to enforce; confirm the approval gate for issuing a refund cannot be satisfied by the agent itself acting alone.

This example exists only to show how the framework’s own vocabulary applies to one hypothetical system. It introduces no new risk class, score, or statistic beyond what is defined above.

Framework limitations

• TMG-ARC does not provide a severity score or maturity model. Classification describes the mechanism of failure and the relevant controls and tests — it does not assign a numeric risk score.
• It does not replace OWASP, MITRE ATLAS, NIST AI RMF, or any other applicable standard or framework a team may be required to follow.
• It reflects the concepts already established in TMG’s own published research (linked below) and has not been independently validated against a large sample of real agentic deployments.

References / grounding

• OWASP GenAI Security Project — agentic security work
• OWASP Top 10 for LLM Applications
• MITRE ATLAS
• NIST AI Risk Management Framework

Relevant TMG Security links