Agentic AI Under the Microscope

1. The Problem: "Agentic AI Security" Is Not a Category

The cybersecurity industry has a new favourite buzzword: agentic AI threats. Vendors publish reports on "AI-powered attacks." Regulators call for "AI-specific security frameworks." Conferences dedicate entire tracks to "securing AI agents."

All of this commits the same foundational error that has plagued cybersecurity for decades: classifying threats by their technology label rather than by the generic vulnerability being exploited.

TLCTC Axiom III states: Threats are causes, not outcomes. Axiom IV adds: Threats are not defined by actor identity or tooling. "Agentic AI" describes a technology stack, not a cause. Labelling it a "threat category" is exactly as useful as labelling "cloud" a threat category—which is to say, not useful at all. It conflates fundamentally different generic vulnerabilities under a single marketing-friendly umbrella, guaranteeing that the resulting controls will be misaligned, incomplete, or both.

This paper applies the TLCTC v2.0 framework to systematically decompose agentic AI threats into their actual causal components. The result is not a new framework—it is a demonstration that the existing 10 clusters already cover the entire agentic AI threat landscape, provided we ask the right question: What generic vulnerability does the attacker exploit?

2. Two Fundamental Scenarios

Every agentic AI threat scenario reduces to one of two structurally distinct cases, determined by a single binary question: Is the AI agent legitimate software or is it foreign executable content?

This distinction is not academic. These two scenarios require entirely different control families positioned at different points on the Bow-Tie model. Conflating them under "AI security" guarantees control gaps. Organisations that treat prompt injection (Scenario 1) and trojanised AI tools (Scenario 2) as the same category will deploy the wrong defences for at least one of them.

3. The Two-Layer Attack Surface

A critical insight that the "AI security" discourse consistently misses: the agent runtime is software first. Before any AI-specific attack vector comes into play, the agent is subject to every generic vulnerability that applies to any software asset. TLCTC Axiom I (no system-type differentiation) mandates this: "AI agent" is a technology label, not a threat class.

3.1 Layer 1 — The Agent as Generic Software

The agent runtime parses external files, handles HTTP responses, deserialises data structures, manages memory, opens network connections. These operations expose the same generic vulnerabilities as any client/server application:

3.2 Layer 2 — The AI-Specific Flavours (Novel Manifestations of #1)

Now the genuinely interesting part. These attack vectors exist because the software asset is an LLM-based agent. But they are novel manifestations of existing generic vulnerabilities—not novel clusters. The TLCTC axiom system remains complete.

Prompt Injection — Direct and Indirect

The industry treats "prompt injection" as a vulnerability class, but TLCTC forces the causal question. The LLM is designed to follow instructions in its context window. There is no implementation flaw. The model's inability to reliably distinguish between legitimate instructions and injected instructions is not a bug—it is a fundamental architectural characteristic. The trust placed in all context-window content is the generic vulnerability.

• Direct prompt injection: The attacker manipulates the agent through its designed input interface. This is pure #1—the attacker uses the standard interface with expected input types (natural language) to subvert the intended purpose.
• Indirect prompt injection: Malicious instructions are embedded in documents, emails, web pages, or API responses that the agent is designed to ingest. The agent's data-reading function works perfectly—the file is parsed correctly, the text is extracted accurately. The extracted content simply contains instructions the agent follows. No implementation flaw is required. The functional scope is the problem.

Training Data Poisoning

When an attacker poisons training data to embed backdoor behaviours, the data ingestion pipeline works as designed. The training function accepts data and adjusts model weights—exactly as intended. The scope and trust placed in that training process is the generic vulnerability. This maps to #1, potentially with a #10 (Supply Chain) dimension if the training data comes from third-party sources. The attacker exploits the trust dependency on the data provider:

Model Extraction and Inference Abuse

An attacker queries the agent's API using legitimate interfaces to extract model weights or proprietary knowledge. Every query is a valid API call processed through standard interfaces. Pure #1, consequence Loss of Confidentiality (LoC). The boundary test confirms: a perfect implementation of the same query interface would still be vulnerable, because the functionality itself is being abused.

Hallucination Exploitation

An attacker crafts inputs that cause the agent to produce specific manipulated outputs. The model functions exactly as implemented; the statistical nature of its designed inference process is exploited. The scope of what the model will generate is the generic vulnerability. Downstream systems that consume the agent's output without validation suffer a Loss of Integrity (LoI).

4. Attack Path Catalog

4.1 Scenario 1: Legitimate Agent Compromised

The following paths all begin with an authorised agent already operating within the target environment. The primary cluster is #1 in various forms.

• Path A — Direct Prompt Injection: #1 →[0s] #1 → [LoC/LoI]
  Attacker manipulates agent through its designed input interface ('first #1'). Agent abuses its own tool-use capabilities ('second #1') to exfiltrate data or modify systems. Both steps exploit functional scope, not implementation flaws.
• Path B — Indirect Prompt Injection via Data Sources: #1 →[0s] #1 →[0s] #1 → [LoC]
  Malicious instructions embedded in documents, emails, or web content the agent is designed to ingest. Agent's data-reading function ('first #1') encounters injected instructions, triggering abuse of action capabilities ('second #1'), leading to unauthorised operations ('third #1').
• Path C — Social Engineering of Human Operator: #9 →[Δt=variable] #1 →[0s] [LoC/LoI]
  Human is manipulated into instructing the agent to perform actions counter to security interests. Classic #9 (Social Engineering) enabling #1.
• Path D — Credential Access to Agent Interface: #4 →[0s] #1 →[0s] #1 → [LoC]
  Stolen credentials grant access to the agent's interface. Every subsequent agent action is pure #1—legitimate functions being abused via a stolen identity.
• Path E — Agent as Execution Vector: #1 →[0s] #7 → [LoC/LoI/LoAc]
  If the agent has designed code-execution capabilities (many agentic frameworks do), function abuse (#1) enables the agent to generate and execute Foreign Executable Content (#7). This is the LOLBAS pattern with the agent itself as the LOLBin.
• Path F — Layer 1 Exploit of Agent Runtime: #3 →[0s] #7 →[0s] #1 → [LoC]
  A crafted external file triggers an implementation flaw in the agent's parser (client-role → #3), enabling code execution (#7), followed by lateral function abuse (#1). This is a generic software attack that happens to target an AI runtime.

4.2 Scenario 2: Malicious Agent Introduced

Here the agent itself is Foreign Executable Content. The generic vulnerability is the environment's designed capability to execute untrusted code.

• Path G — Social Engineering to Install Rogue Agent: #9 →[hours–days] #7 →[0s] #1 → [LoC]
  User is tricked into installing what appears to be a helpful AI agent. Once executing (#7), it abuses legitimate system functions (#1) for reconnaissance, lateral movement, and exfiltration.
• Path H — Supply Chain: Trojanised Agent via Marketplace: #10 ||[dev][@AgentVendor→@Org]|| →[weeks] #7 →[0s] #1 → [LoC/LoI]
  Trojanised agent delivered through trusted vendor channels or AI marketplaces. This is the SolarWinds pattern adapted for the AI agent ecosystem. The trust dependency on the agent vendor/marketplace is the #10 generic vulnerability.
• Path I — Rogue Agent as Persistence Mechanism: #7 →[0s] #4 →[0s] #1 →[weeks] [LoC]
  The malicious agent harvests credentials (#4 acquisition as consequence), then uses them (#4 application) for persistent, stealthy operations (#1). The agent's autonomous nature makes this an APT-in-a-box.

5. The Velocity Revolution

Here is where the operational consequences become decisive. TLCTC's Attack Velocity concept (Δt) measures the time between attack steps, determining which Velocity Class (VC) applies and therefore which control types are structurally viable.

Agentic AI is an attack-velocity compressor. A traditional attack chain like phishing → credential theft → lateral movement → data exfiltration contains human-speed velocity gaps—hours and days where VC-2 and VC-1 controls (analyst triage, threat hunting) are viable intervention points. An agent-mediated attack chain compresses these gaps to machine speed:

6. Control Implications: The Bow-Tie View

The TLCTC Bow-Tie model separates cause-side prevention from consequence-side mitigation. For agentic AI, this separation reveals the full control landscape:

6.1 Scenario 1 Controls (Agent as Authorized Software)

Cause-side (Prevent #1): Constrain the agent's functional domain.

• Capability restriction: Define explicit allow-lists for tools, APIs, and actions the agent may invoke. Every capability not explicitly permitted must be denied.
• Instruction hierarchy: Enforce privilege levels in the agent's context window—system instructions must override user input, which must override ingested data.
• Context isolation: Separate data channels from instruction channels where architecturally feasible. Treat all external data as untrusted input to the instruction processor.
• Human-in-the-loop gates: Require human approval for high-risk operations (financial transactions, credential operations, external communications, code execution).
• Output filtering: Validate agent outputs before they reach downstream systems or external interfaces.

Consequence-side (Mitigate impact): Limit the blast radius when #1 succeeds.

• Least privilege: Agent service accounts should have minimal permissions, scoped to specific resources and operations.
• Audit logging: Every agent action must produce an immutable audit trail—essential for the post-event investigation that VC-4 velocity makes inevitable.
• Rate limiting: Cap the volume and velocity of agent actions to create detection windows.

6.2 Scenario 2 Controls (Agent as Malware)

Cause-side (Prevent #7): Block execution of unauthorized agent code.

• Allow-listing: Only approved agent runtimes and plugins may execute in the environment.
• Code signing: Require cryptographic verification of agent packages before installation.
• Marketplace governance: Vet third-party agent sources; treat AI marketplaces with the same supply-chain rigor as software repositories (#10 controls).
• Sandboxing: Execute agents in isolated environments with controlled system access.

Consequence-side (Mitigate impact): Contain damage when #7 succeeds.

• Network segmentation: Prevent lateral movement from agent execution environment.
• Behavioural monitoring: Detect anomalous patterns in agent operations (unusual API calls, data access patterns, communication endpoints).
• Kill switches: Implement immediate agent termination capabilities—essential at VC-4 speeds.

7. What the Industry Gets Wrong

The current discourse around agentic AI security commits several taxonomic errors that TLCTC makes visible:

7.1 Conflating Technology Labels with Threat Categories

Calling "agentic AI" a threat category is equivalent to calling "cloud computing" a threat category. The label describes the technology stack, not the generic vulnerability being exploited. An AI agent is a software asset. It can be abused (#1), it can have implementation flaws (#2/#3), its credentials can be stolen (#4), its communications can be intercepted (#5), it can be overwhelmed (#6), it can be or execute malware (#7), it can be physically accessed (#8), its operators can be manipulated (#9), and it can arrive via compromised supply chains (#10). All ten clusters apply. Treating "AI" as an eleventh category adds confusion, not clarity.

7.2 Treating Prompt Injection as a Novel Vulnerability Class

Prompt injection is a novel manifestation of an existing generic vulnerability: the scope, complexity, and inherent trust designed into software functionality (#1). The mechanism is new—instruction confusion in a language model—but the structural relationship between the attacker and the vulnerability is identical to any other case of function abuse. The attacker uses the standard interface with expected input types to achieve outcomes the designers did not intend. This is #1.

Treating prompt injection as its own category would be like creating a separate threat class for SQL injection, XSS, and buffer overflows. These are all specific manifestations of #2 or #3 (implementation flaws). The generic vulnerability is what determines the control family, not the specific technique.

7.3 Missing the Two-Layer Decomposition

Most AI security guidance treats the agent as a purely novel asset class. In reality, it is a software application with AI-specific features. The Layer 1 attack surface (generic software vulnerabilities) is often larger and more immediately exploitable than the Layer 2 surface (AI-specific attack vectors). Organisations that focus exclusively on prompt injection while ignoring the agent's unpatched parser vulnerabilities, exposed API endpoints, or misconfigured service accounts are securing the skylight while leaving the front door open.

7.4 Ignoring the Velocity Dimension

Most AI security frameworks prescribe controls without considering attack velocity. TLCTC's velocity classes reveal that many prescribed controls—manual review, analyst triage, incident response procedures—are structurally nonviable against agent-mediated attack chains operating at VC-4 speeds. Only architectural, automated controls survive the velocity test. Any framework that does not account for this is prescribing controls that cannot work.

8. The Real Insight: An Abnormally Large #1 Surface

The deepest insight from this analysis is not that AI agents face new threats. It is that the generic vulnerability surface of #1 for LLM-based agents is abnormally large compared to traditional software.

A conventional application has a bounded set of functions with well-defined input types and expected behaviours. An LLM agent's "functional scope" is, by design, essentially unbounded—it is a general-purpose instruction follower with tool access. The "inherent trust, scope, and complexity designed into software functionality" (the generic vulnerability of #1) is maximised by architectural choice.

This does not create a new cluster. It does not require a new framework. But it dramatically increases the attack surface area within #1, and it means the #1 controls must be proportionally more aggressive. The principle of constraining functional scope—which has always been the core defence against #1—becomes both more critical and more difficult to implement when the software's entire value proposition is its broad functional scope.

This is the genuine challenge of agentic AI security: not a new category of threat, but a familiar category of threat at unprecedented scale and velocity.

9. Conclusion

The cybersecurity industry does not need an "AI security framework." It needs to apply existing cause-based reasoning to a new technology stack. TLCTC demonstrates that the entire agentic AI threat landscape decomposes cleanly into the established 10 clusters, with two primary scenarios (#1 and #7) covering the vast majority of practical attack paths.

What organisations actually need:

• Scenario awareness: Know whether you are defending against function abuse of legitimate agents (#1) or introduction of malicious agents (#7). Deploy the corresponding control family.
• Two-layer thinking: Secure the agent as software first (Layer 1), then address AI-specific attack vectors (Layer 2). Do not skip Layer 1.
• Velocity-aware controls: Test every proposed control against the actual Δt of agent-mediated attack chains. If the control requires human decision-making at VC-4 speeds, it will fail. Replace it with architectural controls.
• Proportional #1 defence: Recognise that the agent's unbounded functional scope demands aggressive capability restriction, context isolation, and human-in-the-loop gates for high-risk actions.

The threats are not new. The generic vulnerabilities are not new. What is new is the scale of #1's attack surface and the velocity at which it can be exploited. Understanding this clearly—rather than reaching for new buzzword categories—is the first step toward actually securing agentic AI.