9. The AI Application Security Continuous Loop

Introduction

A guardrail rule set is the only control in the Blueprint with a shelf life.

Every other control you have built holds its value while you leave it alone. An encrypted volume stays encrypted. A signed model artifact stays signed. An egress allowlist keeps denying the same destinations next quarter. But a filter is a description of attacks that were known when it was written, and Chapter 2 Section 2 spent a whole section on why that description is never finished: encoding, Unicode and token smuggling, language switching and cross-modal payloads each defeat a filter that was correct the day it shipped. Section 7 put a number on the residual – the best-instrumented production guardrail on record still leaves a low-single-digit bypass rate against dedicated attackers, and that figure came from a frontier lab spending 1,700 hours of red-teaming on it.

So the operational question is not “is the filter good?” It is “what process keeps it aimed at the attacks that actually arrive, and how would I know if it stopped being aimed?” That process is what this section covers.

Two TrendAI Vision One components instrument it. AI Scanner probes an AI application before and during deployment and reports what it was able to make it do. AI Guard sits in the live request path and inspects prompts and responses as they flow. Neither is interesting on its own – Scanner produces a report nobody actions, Guard produces rules nobody updates. They are interesting as a loop: scan, protect, validate, improve, with each phase producing the input to the next.

The loop is not a product feature. MITRE ATLAS names the same cycle as a mitigation in its own right – AML.M0035 AI Red Team – and specifies that red-teaming is “a continuous process” whose findings must be converted into “regression tests, evaluation datasets, detection logic, monitoring requirements, or deployment criteria.” Read this section as that practice, with two products supplying the instrumentation. The practice is what transfers if you buy neither.

What the Loop Owns – and What It Cannot Stop

The loop is presented in most vendor material as closing a gap. It is worth being precise about which gap, because two of the three things people expect it to cover are covered elsewhere in the Blueprint, and one of them is not covered at all.

What the loop genuinely owns is decay. A control that was correct at deployment drifts out of alignment with the traffic in front of it: the model gets updated, the application gains a new retrieval source, a technique that did not exist last quarter starts arriving. Nothing else in the Blueprint notices that. Layer 5’s filter does not know its own bypass rate. Layer 6’s baseline does not know it was built during an attack. The loop’s product is evidence about your own controls – and evidence is the thing an AI security program is usually shortest of.

What it cannot do is find a technique nobody has described. This is a property of the design, not a maturity gap. Scanner assesses by running a library of known attacks; a technique absent from the library returns clean, and a clean result means “none of these worked,” never “nothing works.” That is precisely the boundary Section 8 is built on: Layer 6 exists because signature-shaped controls need the attack to be described first, and the honest reading of a Scanner report is that it is a signature-shaped control with the same limit.

And it cannot bound consequence. This is the one that gets missed, and the case study below is an entire incident built on it. Scanner and Guard both operate on text – prompts in, responses out. An attack whose damage is done by an action the agent was permitted to take passes both of them cleanly, because at no point is there a hostile-looking string to catch. Bounding consequence is Layer 4’s human gate and Layer 3’s permission scoping, and no amount of loop maturity substitutes for either.

The residual, then, is not a defect of the tooling. It is the operating assumption. Design the system so that a bypass costs you an unhelpful answer rather than an unrecoverable action, and the loop’s job becomes what it can actually deliver: keeping the bypass rate low, and telling you when it starts climbing.

Which Loop Responsibilities Are Yours

Chapter 1 Section 3 promised that “the layers stay constant, but which ones are yours is set by the choice you make here.” For the loop the split does not run along deployment patterns – it runs between what a product performs and what only you can supply, and the second column is the larger one.

Three readings, and they are why this table is here rather than a feature list:

1 · The purchasable half is the middle of the loop. Detectors, libraries and dashboards are products. Scoping at the front and remediation at the back are not, and a program that buys the middle and skips both ends produces a great deal of telemetry and no change in risk.

2 · The bottom row is the one that decides outcomes. Every other row makes detection better. That row is the only one that can move an incident from “detected late” to “not possible,” and it is the row a tool cannot even suggest, because it requires knowing what the application is for.

3 · The failure is silent. A loop where nobody owns the last two rows still runs. Scans complete, Guard blocks, dashboards populate. Nothing signals that findings are accumulating without being converted into anything. Assign those rows to a named owner before you tune a single detector.

AI Scanner: Proactive Assessment

AI Scanner assesses AI applications – not only models – for exploitable weaknesses, and ranks what it finds. Point it at an application or model endpoint and it probes with known attack techniques, then reports what succeeded. Its documented scope includes prompt injection susceptibility, data leakage, and authentication bypass, which is worth noting because it is the one class that is not a model property at all: it is a finding about the application wrapped around the model, and it is the reason the tool is scoped to applications rather than weights.

What AI Scanner Does

• Attack technique testing. Known injection variants, jailbreak patterns and adversarial inputs, run against the target rather than reasoned about. The deliverable is a transcript of what worked.
• Vulnerability identification and ranking. Which categories the target is susceptible to, mapped to OWASP, with severity – so that a susceptibility reachable by a first-time user is separated from one that took a chained multi-turn setup.
• Data leakage probing. Whether the model has memorised and will reproduce sensitive training data, which is the extraction route of LLM02: Sensitive Information Disclosure. Layer 1 owns the fix: by the time this fires the data is already in the weights, and the remediation is upstream in corpus curation.
• Harmful content generation. Whether safety alignment holds under adversarial pressure, which is a Layer 4 design input – it tells you how much verification the humans downstream will need.
• Configuration and access findings. Authentication and authorisation weaknesses on the serving endpoint itself, which belong to Layer 3 and are where a scan most often produces something immediately fixable.

This is ATLAS AML.M0016 Vulnerability Scanning applied to a running application rather than to an artifact – the artifact half sits at Layer 2, and the two answer different questions about the same model.

When a Scan Runs

Scanning is worthless as a one-off and cheap as a trigger, so define the triggers explicitly:

• Pre-deployment, as a pipeline gate. This is the Validate stage of the AI-SDLC from Section 1, and the gate should fail the build on a finding above an agreed severity – otherwise it is a report, not a gate.
• On model version change, including a provider’s silent update to a hosted model. A model you did not change can behave differently next month, and this is the trigger teams most often lack.
• On surface change – a new retrieval source, a new tool binding, an edited system prompt. Each of these changes what an injection can reach, which changes the meaning of the last clean scan.
• On a schedule, to catch library growth. A quarterly re-scan against an unchanged application still finds things, because the library moved even if you did not.

AI Guard: Runtime Protection

If Scanner asks “what can this system be made to do,” Guard asks “is someone doing it right now.” It reached general availability on 1 December 2025 as an API endpoint within TrendAI Vision One that inspects AI system inputs and outputs in real time.

What AI Guard Does

• Inbound guardrails. Injection detection on prompts and on the retrieved content, tool output and documents that enter the context alongside them – which, as Section 7 establishes, is where the payload actually arrives in every case study in this course.
• Sensitive information leakage prevention. Outbound scanning for PII, credentials and system prompt fragments, with blocking or redaction.
• Harmful content filtering. Responses that are violent, illegal, abusive or policy-violating, refused before delivery.
• Policy and compliance enforcement. Organisational content policy applied consistently across every application that routes through it, which is the property that makes a central inspection point worth having at all.

In ATLAS terms this is AML.M0020 Generative AI Guardrails: “safety controls placed between users, tools, and generative AI models to evaluate prompts, retrieved context, model outputs, and agent actions before they are accepted, executed, or shown to a user.” Note the four objects in that sentence. A deployment that inspects only the user’s prompt is implementing one of them.

Where Guard Sits in the Request Path

Guard is consumed as an API endpoint – Trend-hosted at a regional address (api.<region>.xdr.trendmicro.com), or self-hosted in your own environment. Either way it does not intercept traffic by itself: something in your path has to call it, and that something is your Layer 5 gateway or LLM proxy. TrendAI documents the pattern with LiteLLM: the proxy sends each incoming request to AI Guard for scanning before forwarding it to the target LLM provider, and sends the provider’s response to AI Guard again before returning it to the caller.

Hold on to that sentence, because it is the part people get wrong when they compare deployment options. Self-hosting Guard changes where the inspector runs; it does not make the inspector a network device. The gateway is still yours, the call is still explicit, and coverage is still a property of your routing.

That architecture has a consequence the product literature does not dwell on, and it is the most important operational decision in this section.

A second consequence: because inspection is a call your gateway makes, coverage is a property of your routing, not of the product. Section 7’s finding applies unchanged here – “a correctly configured gateway that 40% of traffic never traverses” protects 60% of your traffic, and a Guard subscription does nothing about the other 40%.

What Guard Does Not Change

Guard is a guardrail, and Chapter 2’s verdict on guardrails stands: a cost-raiser, not a boundary. The four evasion families are not addressed by procuring a better one, the measured residual in Section 7 is low single digits under sustained attack, and the OWASP LLM01 entry states outright that there is no fool-proof prevention. Deploy it – raising attack cost is a real outcome – and size the blast radius as though it will occasionally fail, because it will.

Deployment and Data Flow

Objective 5 is a decision, so here is the decision rather than a menu. Both AI Scanner and AI Guard ship in two deployment modes – Trend-hosted, using TrendAI’s cloud infrastructure, and self-hosted, deployed and run in your own environment, on-premises or in a private cloud. TrendAI’s own documentation states the deciding axis in one line: “If your data needs to remain local, choose self-hosted instead of hosted by TrendAI.”

So the question people ask – “cloud or self-hosted?” – has a documented answer, and the question that produces it is: what is the maximum sensitivity of the content that will cross the inspection boundary, and does your jurisdiction, contract or classification permit it to cross? Everything else follows.

Note what makes inspection different from every other AI service you evaluate: to inspect a prompt, the inspector must receive the prompt. A guardrail service therefore sees, by construction, one hundred percent of your AI traffic – including the traffic your DLP policy exists to keep in-house. It is one of the highest-sensitivity data flows in the architecture, and it is routinely approved as a security tool without the review a data flow of that sensitivity would otherwise get.

Where that leaves the hard cases. If content sensitivity and connectivity both pass, Trend-hosted at the region that satisfies your obligations is the straightforward answer, and the remaining work is placement and tuning. If either fails – classified material, a residency rule no region matches, a disconnected environment – the control does not disappear with the hosted mode. Self-hosted is the documented answer to exactly that case, and the price of it is the Operational ownership row: you now run, patch and update the inspector, and the detection content that made it worth having is on your maintenance schedule.

There is a third case the product cannot answer, and it is the one to plan for. Where neither mode is available to you – no budget for the component, an environment nothing may be deployed into, a platform decision made elsewhere – the requirement still does not disappear. It has to be met another way: a locally-run guardrail model in your own serving stack, deterministic policy checks at the gateway, and correspondingly more weight on the controls that do not require inspection at all – action scoping, least-privilege tool credentials and human gates on the irreversible subset.

That is the transferable lesson, and it is why the axes matter more than the modes. When the inspecting control is unavailable to you, the answer is not a weaker inspector – it is an architecture that needed the inspector less.

The Continuous Loop

Each phase exists to produce a specific artifact that the next phase consumes. Name the artifact and the loop is auditable; leave it unnamed and the loop degrades into four activities that happen near each other.

The Scan-Protect-Validate-Improve Cycle

graph LR
    S["<b>SCAN</b><br/><small>Probe the application<br/>with known techniques.<br/><i>Artifact: ranked findings<br/>with transcripts</i></small>"]
    P["<b>PROTECT</b><br/><small>Configure rules and<br/>bound consequence.<br/><i>Artifact: rules, plus a<br/>scope or gate change</i></small>"]
    V["<b>VALIDATE</b><br/><small>Measure the controls,<br/>not the threat.<br/><i>Artifact: detection and<br/>false-positive rates</i></small>"]
    I["<b>IMPROVE</b><br/><small>Convert failures into<br/>permanent tests.<br/><i>Artifact: regression suite,<br/>new detection logic</i></small>"]

    S -->|"Ranked<br/>findings"| P
    P -->|"Runtime logs,<br/>blocked patterns"| V
    V -->|"Measured<br/>gaps"| I
    I -->|"Regression tests,<br/>new techniques"| S

    style S fill:#1565c0,color:#fff
    style P fill:#2d5016,color:#fff
    style V fill:#7a6a00,color:#fff
    style I fill:#6a1b9a,color:#fff

1 · SCAN – Produce Ranked Findings

Scanner runs its library against the target and reports which probes succeeded, how hard they were, and what the successful prompts were. Read the output against two questions rather than one:

• What worked? – the finding, with its transcript. This is the strong evidence.
• What could it reach? – not in the report, and not knowable by the scanner. A susceptibility in an application that can only return text is a different risk from the same susceptibility in an application holding a write-capable tool.

The second question is why a Scanner report should never be triaged by severity alone. Severity describes how easily the model was manipulated; impact is set by the permissions on the other side of it, and those live in your architecture.

2 · PROTECT – Configure Rules and Bound Consequence

Guard rules are configured against what Scanner actually found, which is the property that makes them better than defaults: if the finding was a role-play jailbreak, the detection targets that pattern; if the finding was training-data reproduction, output rules target the specific data classes that came back.

But a phase that only writes rules has already conceded the point made at the top of this section. Every finding gets two responses: a detection change and a consequence change. The detection change lowers the odds. The consequence change decides what happens on the occasion the detection loses – narrower tool credentials, a human gate on the irreversible subset, a scope reduction on what the compromised path can reach. A loop whose PROTECT phase only ever produces rules is a loop that will keep detecting the same class of incident more accurately and never stop one.

3 · VALIDATE – Measure the Controls, Not the Threat

This is the phase that is most often skipped, because it produces no artifact anyone is asking for until an incident. Four measurements, and each has a decision attached:

Two things make this phase real rather than nominal.

Replay, don’t assume. A detection rate you have not measured recently is a detection rate from the day you deployed. Maintain a corpus of attacks that previously succeeded and replay it against the current configuration on a schedule. This is where AML.M0035 is explicit: convert confirmed failures into “regression tests, evaluation datasets, detection logic, monitoring requirements, or deployment criteria.” A failure that becomes a permanent test can only regress once.

Automated assessment is not red-teaming, and the gap is the interesting part. ATLAS scopes an AI red team across “models and data, agents (including memory and tools), data flows, decision processes, application logic, retrieval systems, identities and permissions, software dependencies, non-AI system components, infrastructure, user interfaces, and human workflows.” A scanner covers the first item and part of the second. The rest – the chained, multi-step, human-in-the-workflow attacks that produced every case study in Chapter 2 – needs people. Section 11 covers how that team is scoped and run; the loop’s job is to make sure their findings do not stay in a report.

4 · IMPROVE – Make the Failure Permanent

The improve phase has one test of success: something changed that cannot silently revert.

• A regression test exists for every confirmed failure, running in the pipeline.
• Guard rules updated from novel patterns in the blocked logs.
• Scanner’s library extended, where the technique is new rather than merely new to you.
• Thresholds retuned from false-positive analysis, with the new rate recorded so the next cycle has a comparison.
• Findings routed to the layer that owns them. A volume of exfiltration attempts is a Layer 1 data-classification signal. A cluster of tool-call anomalies is a Layer 6 baseline input. A finding that keeps recurring after two cycles of rule tuning is telling you the fix is architectural.

That last item is the loop’s exit condition, and it deserves stating plainly: if the same class of finding survives two full cycles, stop tuning. The loop has done its job – it has produced evidence that detection is the wrong control for this problem. What follows is a permission change, a gate, or a design change, and it belongs to a different layer.

Scanner and Guard Across the Blueprint Layers

Neither tool belongs to a single layer. What each contributes per layer is worth stating precisely, because the contributions are uneven and the uneven ones are where the misconceptions live.

The Layer 2 row is the one that teaches the distinction, and it is worth reading twice. It is not that Guard is weaker at Layer 2; it is that Layer 2’s subject does not exist at runtime. A signature on a weights file is either valid or not before a single request arrives, and there is no prompt that can be inspected to establish it.

Defense Perspective: GitHub Copilot CVE-2025-53773

The Loop → OWASP Mapping

Scanner and Guard are named in the course-wide mapping against a specific set of categories. For each one, the same two-part honesty applies as in every layer section – what the loop does, and what it does not reach.

Read the third column down and the pattern is consistent: the loop’s limit is always the same limit. It acts on text, and in every row the thing it cannot reach is either a property fixed before runtime or an action taken after the text was accepted. That is not a gap in the tooling – it is the definition of where assessment and filtering sit in a defense-in-depth architecture, and it is why this section comes after the six layers rather than instead of them.

Note also which categories are absent. LLM03: Excessive Agency and LLM04: Supply Chain have no row, because there is no prompt or response whose inspection establishes anything about either. The Copilot case above is exactly what an LLM03 incident looks like from inside a loop that has no LLM03 row.

TrendAI Vision One Integration

Scanner and Guard are GA components of TrendAI Vision One, and the integration argument is about correlation rather than features. Scanner runs from CI/CD as a pre-deployment gate; Guard is called inline by your gateway; both report into the Vision One console alongside AI-SPM posture findings and Layer 6 network detections.

The value of that convergence is the same one Section 2 works through: single-layer signals that are individually unalarming and jointly unmistakable. A Scanner finding that a model leaks its system prompt, a posture finding that the same endpoint is reachable without authentication, and a Guard log showing extraction attempts against it are three low-priority tickets in three consoles and one incident in one timeline.

Read that against the ownership table before sizing the investment. The platform correlates and detects; the scoping at the front of the loop and the remediation at the back are yours in every deployment pattern, and a console arrives configured for neither.