Which lifecycle stage accounts for the most real-world incidents?

Input-time attacks, primarily prompt injection, dominate the disclosed incident record so far, largely because they require the least specialized access: an attacker who can get content in front of a deployed system, a document, a web page, an email, has a viable attack path without needing infrastructure access or model internals. Infrastructure-time attacks are growing quickly as a category as AI supply chains mature and attract more attacker attention, but the barrier to attempting them is currently higher than the barrier to attempting a prompt injection.

Can a single attack chain span more than one lifecycle stage?

Yes, and the most damaging documented incidents usually do. A campaign might start with an input-time prompt injection that manipulates an agent into taking an unauthorized action, which then produces an output-time information disclosure as the consequence, all against a target whose infrastructure-time posture, an overprivileged service credential, is what turned a contained manipulation into a serious breach. Mapping an incident to the stages it touched, rather than filing it under one category, is usually more useful for the post-incident fix than a single label would be.

Does this lifecycle framing apply to agentic systems the same way it applies to simple chat models?

The four stages still apply, but agentic systems add more surface at each one. Input-time expands to cover every tool result and sub-agent message the primary agent processes, not just the user's own prompt. Output-time expands to cover every action the agent's output triggers, not just what a user reads. Inference-time and infrastructure-time stay conceptually the same but multiply across however many models or agent instances are involved in a single task. The framing scales; the surface at each stage grows with the system's complexity.

Where does a denial-of-wallet or resource-exhaustion attack fit in this framework?

It is primarily an input-time attack, since the attacker's advantage comes from the volume, size, or recursive structure of requests sent into the system, and the fix, rate limiting and consumption policy, is enforceable at the same request-path point that other input-time controls operate at. Its consequence, however, plays out at the infrastructure and billing layer, which is why it sometimes gets miscategorized as an infrastructure-time issue when the actual point of control is upstream, at the request that should never have been allowed to start consuming resources in the first place.

LLM Attacks Sorted by Where in the Request They Actually Happen

MITRE ATLAS catalogs adversary tactics and techniques against AI systems the same way MITRE ATT&CK catalogs them against conventional IT, and OWASP's Top 10 for LLM Applications ranks risks by severity and prevalence. Both are the right reference for what they are built for. Neither answers the first question a security team actually asks when a new AI deployment lands on their desk: where in this system do I even start looking. A prompt injection attack, a training data poisoning attack, and an unbounded consumption attack do not just differ in mechanism. They fire at completely different moments in a request's life, and that difference determines which team can fix them.

TL;DR

LLM attacks are usually catalogued by objective or by CVE, but sorting them by lifecycle stage shows which team owns each fix.
Input-time attacks happen before the model runs, inference-time attacks happen during generation, output-time attacks happen after the model responds, and infrastructure-time attacks target what surrounds the model entirely.
Most identity-aware policy gateways, including DeepInspect, are positioned to act on input-time and output-time attacks, because those stages are visible on HTTP traffic.
Inference-time and infrastructure-time attacks require model-layer and platform-layer controls that sit outside any request-path tool.

Input-time: the attack arrives inside content the model will process

Input-time attacks compromise what the model sees before it starts generating. Prompt injection is the dominant example: instructions hidden inside a document, a web page, or a tool result that the model reads and follows as if they came from the legitimate operator, rather than from whatever untrusted content carried them in. Data poisoning aimed at a retrieval index, planting malicious content into a knowledge base a RAG system will later fetch and feed to the model, is the same stage attacked further upstream.

This stage is visible on HTTP traffic, because the prompt, the retrieved context, and any tool results all travel as part of the request the model receives. An inline policy layer sitting on that traffic can inspect what is actually entering the model's context window and evaluate it against classification and origin before the request proceeds. MITRE ATLAS's own prompt injection case studies sit almost entirely at this stage.

Inference-time: the attack targets the model while it is generating

Inference-time attacks work on the model's behavior during the forward pass itself: adversarial suffixes engineered to shift the model's internal representations toward an unsafe completion, jailbreak techniques that exploit how the model was trained to refuse, and side-channel attacks like the KV-cache timing techniques documented in recent multi-tenant serving research that extract information from how the model processes a request rather than from the request's content.

Nothing about this stage is visible from outside the model. It happens inside weights, attention computation, and serving infrastructure that only the model provider or a self-hosted platform's own inference stack controls. Model-layer defenses, refusal training, constitutional methods, cache-partitioning at the serving layer, are the only controls that operate at this stage, and no request-path tool, including DeepInspect, has visibility into it, a boundary argued in full here.

Output-time: the attack rides out in what the model returns

Output-time attacks use the model's response as the delivery mechanism. Insecure output handling, where an application renders or executes model output without validating it, turns the model into an unwitting conduit, as the well-documented 2023 markdown-image exfiltration technique demonstrated: a model faithfully generating markdown syntax an attacker had planted upstream, rendered automatically by an interface that trusted the output. Sensitive information disclosure, a model returning data in a response that the requesting identity was never entitled to see, is the same stage from a different angle.

Like input-time attacks, this stage is visible on HTTP traffic, because the response the model returns is the same response a policy layer sitting on that traffic observes before it reaches the calling application.

Infrastructure-time: the attack never touches a live inference call at all

Infrastructure-time attacks compromise something adjacent to the model rather than the model interaction itself: a poisoned package in the training or serving pipeline, a backdoored model file distributed through an open model hub, a compromised MCP server installed with broad host privileges, a stolen credential reused to replay a hijacked session. None of these require a single successful inference call to succeed, because they compromise the environment the model runs in or the identity that calls it, before or entirely apart from any specific request.

This stage sits outside HTTP AI traffic by definition, since the compromise happens during installation, deployment, or credential theft rather than during a model call. Supply chain review, dependency scanning, and endpoint security own this stage, not an AI traffic control layer, and five real 2026 CVEs show what that stage looks like when it fails.

Why the lifecycle framing matters more than the objective framing

An attack objective (steal data, cause harmful output, exhaust a budget) can be achieved through attack classes at any of the four stages, which is exactly why sorting by objective alone leaves the "who fixes this" question unanswered. A data-theft objective might be pursued through output-time sensitive disclosure, input-time injection that manipulates what gets retrieved and returned, or infrastructure-time credential theft. Each of those three needs a different owner and a different control. The lifecycle framing forces that assignment explicitly, instead of leaving three different teams each assuming someone else has the stage covered.

DeepInspect

DeepInspect's enforcement boundary maps cleanly onto two of the four stages. It sits inline on HTTP AI traffic between authenticated users or agents and the LLM APIs they call, which means it evaluates input-time content, classification, origin, injected instructions arriving in a request, before that content reaches the model, and it evaluates output-time content, sensitive data, policy-violating patterns, before a response reaches the calling application. Every evaluation writes a signed, per-decision record.

Inference-time and infrastructure-time attacks sit outside that boundary by design, and DeepInspect does not claim otherwise. Inference-time defenses belong to the model provider's training and serving stack. Infrastructure-time defenses belong to the platform's dependency management and endpoint security. A control mapping that claims coverage across all four stages from one product is a mapping nobody should trust, and stating the boundary plainly is what makes the two-stage claim credible.

If your security team has an attack taxonomy but no map of which stage each item sits at, and therefore no map of who owns the fix, that gap is worth closing before the next tabletop exercise. Let's talk today.