RedLens AI → Compliance → SOC 2 & LLM Guardrails

SOC 2 and LLM Guardrails: What an Auditor Actually Expects

There is no "AI control" in SOC 2. The Trust Services Criteria predate LLMs and do not name them. But the moment you ship an LLM feature, you widen the scope of criteria you already have to satisfy — and an experienced auditor will ask how your existing controls extend to a component that is non-deterministic, takes untrusted input, and can be talked into acting against its instructions.

The mental model: LLM guardrails are not a new criterion, they are new scope

SOC 2 is organised around five Trust Services Criteria: Security (the common criteria, CC-series), Availability, Processing Integrity, Confidentiality, and Privacy. An LLM feature does not add a sixth. It stretches several of the existing five over a new kind of system. The useful question is not "is there an AI control?" but "which of my criteria now have an LLM inside their boundary, and what evidence shows the control still holds there?"

Where LLM guardrails map

Trust Services Criterion	What the LLM adds to its scope	Guardrail / evidence an auditor looks for
Security (CC)	A new input path (the prompt) that can carry instructions, and often new tool/API reach behind it.	Prompt-injection and jailbreak testing with results; input/output filtering; least-privilege on any tools the model can call; logging of model interactions.
Confidentiality	The model may hold or be coaxed to reveal system prompts, secrets, or other tenants' data.	System-prompt-extraction testing; secrets kept out of prompts; tenant isolation verified under adversarial input, not just normal use.
Processing Integrity	Output is probabilistic; "complete, valid, accurate, timely, authorised" is harder to assert for a component that can hallucinate or be steered.	Evaluation of output quality; guardrails that constrain or ground responses; a documented position on the limits of the model's reliability. (This is why some vendors scope Processing Integrity out — and must say so honestly.)
Privacy	Prompts and outputs may contain personal data; training/logging may retain it.	Data-handling for prompt/response data; no-training commitments from model providers (in the DPA/BAA); retention and deletion covering LLM logs.
Availability	Dependence on a model provider's API and its rate limits/outages.	Provider dependency in the risk register; failure behaviour that degrades honestly rather than silently.

The criterion LLMs stress most is Processing Integrity, and the honest answer is often that you cannot guarantee a non-deterministic model's output is "accurate". Auditors respect a clear scoping decision (with disclaimers and grounding controls) far more than a claim you cannot support. Overclaiming here is the fastest way to a qualified opinion.

What counts as evidence

An auditor does not accept "we have guardrails" as a control; they accept evidence that the control operates. For an LLM feature that generally means:

Adversarial test results, not a policy PDF. A record that prompt-injection, jailbreak, tool-abuse, and system-prompt-extraction attempts were run against the deployed feature, what succeeded, and what was remediated.
Repeatability. The same suite run on a cadence, so the control shows operating effectiveness over the audit period, not a one-time pentest.
Mapping to the criteria. Each finding tied to the criterion it touches (a jailbreak → Security; a leaked system prompt → Confidentiality) so the auditor can trace coverage.
Honest scoping. Where a criterion (typically Processing Integrity) is excluded, a written, defensible reason.

How RedLens produces that evidence

RedLens runs an adversarial suite against your deployed LLM feature — prompt injection, roleplay privilege escalation, tool-chain hijacking, system-prompt extraction, and more — judges which attempts actually succeeded, and maps each finding to the OWASP LLM Top 10 (2026) and to the SOC 2 criterion it bears on. The output is the kind of repeatable, mapped, results-based artifact an auditor can rely on, rather than an assertion.

On RedLens's own status, plainly: RedLens is at SOC 2 readiness stage (internal controls and policies in place; audit scheduled) — it is not itself SOC 2 certified, and this page does not claim otherwise. It describes how RedLens helps you generate evidence for your audit.

Generate SOC 2 evidence for your LLM feature

A repeatable adversarial scan of your deployed LLM application, with findings mapped to the SOC 2 criteria and the OWASP LLM Top 10 (2026), plus an exportable evidence pack. Free CI check for prompt-template exposure; the platform runs the full suite on a schedule.

Scan your LLM feature See RedLens's security posture →

Trust Services Criteria are defined by the AICPA (2017 TSC, security/availability/processing integrity/confidentiality/privacy). This page is guidance from RedLens AI Security Research, not a substitute for your auditor's judgement.