AI application security architecture: Building defense-in-depth for AI-powered applications

Updated August 10, 2026

TL;DR: Perimeter-based AI gateways fail audit requirements because they route telemetry outside your trust boundary and enforce nothing at the moment of the model call. Defense-in-depth implementations vary by framework and threat model, but a practical self-hosted stack addresses four boundaries: input filtering, output validation, role-based access control, and SIEM-integrated runtime logging. A self-hosted control plane enforces each layer deterministically at the API level, keeping all data, governance logic, and audit logs within your VPC or air-gapped environment. No code rewrites required. One base_url change is all developers touch.

Your engineering team is deploying AI agents. Your compliance program documents policies in Confluence or a policy repository. The gap between those two realities is where critical audit findings are born, because a policy that exists in a document but isn't enforced at the system level isn't a control. It's a liability waiting to surface the next time a Defense Counterintelligence and Security Agency (DCSA) assessor or Federal Financial Institutions Examination Council (FFIEC) examiner asks for the evidence trail.

The answer isn't another external gateway bolted onto your network boundary. True defense-in-depth for AI systems requires stacking independent, self-hosted controls at the API level so that no single point of failure exposes your organization to model exploitation, data egress, or a compliance gap you can't document. This article builds that architecture layer by layer.

Building resilient AI through layered governance

Understanding where single-point architectures fail is the prerequisite for designing controls that hold. The risks compound in agentic workflows, where the threat surface extends well beyond the perimeter.

Single-point failures in AI application security

Most organizations treat AI security as a perimeter problem, placing a single external gateway at the entry point and calling it sufficient. If that gateway is bypassed, misconfigured, or unavailable, the entire application is exposed with no secondary control to catch the gap. In agentic workflows, the threat surface is wider still: the threat vector is often an outbound tool call executed inside your network, not an inbound payload a gateway could have intercepted. The OWASP Top 10 for Agentic Applications confirms that information crosses system boundaries in semantically opaque ways, enabling cross-layer attacks invisible to per-layer detectors.

Using OWASP to structure AI defenses

The OWASP LLM Top Ten and the OWASP Top 10 for Agentic Applications identify the risks most likely to affect AI systems and point to the integration boundaries where exploitation is most likely to occur. For agentic systems that include tool calls, MCP servers, and multi-step workflows, the agentic applications document is the primary threat model. Each item points to a specific integration boundary where exploitation is most likely: the input boundary, the output boundary, the tool execution surface, and the access control layer. Prediction Guard's episode 04 on OWASP implementation (YouTube video series) walks through how these translate to engineering decisions in production.

Standardizing AI governance for auditors

Translating these technical controls into evidence a FFIEC examiner or DCSA assessor can evaluate requires two things: deterministic enforcement at the system level and a structured audit record proving enforcement happened on every call. The AIUC-1 standard organizes AI governance across six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, and Society) and provides crosswalk mappings to frameworks including NIST AI RMF and OWASP, giving compliance teams a single lens for satisfying multiple reviewers simultaneously. The NIST AI RMF playbook details how to turn those requirements into audit-ready artifacts without assembling them manually from logs and emails.

The mapping table below shows exactly where system-level controls intersect with framework requirements. Note that OWASP item numbers follow the current published OWASP LLM Top Ten. Verify against the most recent list before citing in audit documentation.

AIUC-1 crosswalk: capability mapping to NIST AI RMF and OWASP LLM Top 10

Foundational controls for secure AI systems

Before application-layer controls can be meaningful, the network boundary must be established. Every enforcement layer above it depends on the assumption that AI traffic cannot egress to unauthorized endpoints.

Layered isolation for AI workflows

The first prerequisite is network isolation: your AI workloads run inside a defined security boundary (a VPC, a private Kubernetes cluster, or an air-gapped environment) where data cannot egress to unauthorized third-party endpoints. External AI gateways, by definition, require your AI traffic to leave your perimeter before they can evaluate it. Prediction Guard's EP12 and EP02 cover self-hosted sovereignty and air-gapped deployment patterns for manufacturing and defense-adjacent workloads in detail.

Layering independent controls across the AI inference lifecycle

A layered security model can be applied to the AI inference lifecycle, with each layer representing an independent enforcement point:

1. Physical / infrastructure: Kubernetes cluster or server hardware running inside your controlled environment.
2. Network: VPC segmentation, private endpoints, and egress controls preventing unauthorized external calls.
3. Host / runtime: Container-level isolation for model inference servers, with resource quotas preventing runaway agent workloads.
4. Application (input): Prompt injection filtering and PII redaction at the control plane, applied before any prompt reaches the model inference server.
5. Model inference: The probabilistic model layer, isolated from governance logic. Policies wrap the model externally, not inside it.
6. Application (output): Output validation, toxicity filtering, and factual consistency checking applied to model responses before they return to the calling application.
7. Logging / compliance: Structured audit log generation as a byproduct of every enforcement decision, formatted for SIEM ingestion inside the customer's own environment.

The Practical AI podcast episode 343 examines the case for model-native safety mechanisms over application-layer filters, arguing that internal signals can enable earlier interventions. The trade-off is that model-native approaches don't produce the deterministic, auditable enforcement evidence that a FFIEC examiner or DCSA assessor requires. System-level controls at the application layer answer that question directly.

Technical prerequisites:

• API compatibility: OpenAI-compatible (/chat/completions) and Anthropic-compatible (/messages) endpoints. Existing SDK code requires only a base_url change.
• Python SDK: langchain-predictionguard. A native integration package is available for teams using popular agent orchestration frameworks, installable via standard package management without changes to existing application code.
• Deployment: Hardware and infrastructure agnostic across GPU hardware generations and cloud providers. The control plane is CPU-only. Supports cloud VPC, air-gapped, and self-hosted private infrastructure.
• Model scope: Model agnostic. Governs open-source families, closed-vendor endpoints, and self-hosted models under one control plane.

Comparing static and dynamic AI controls

AI models are probabilistic by nature. The same prompt can produce different outputs across inference calls, and that variability is a property of the model architecture, not a configuration gap. The governance approach here is a deterministic policy layer wrapped around the model: regardless of what the model generates, a PII pattern triggers the same redaction action every time, a toxicity threshold triggers the same block every time, and a prompt injection signature triggers the same rejection every time. The AIUC-1 Safety and Accountability pillars do not require the model to be deterministic. They require the enforcement controls to be. Prediction Guard's video on unifying AI tool governance explains why a unified enforcement surface is operationally critical as model count grows.

Layer 1: Mitigating injection risks at the boundary

The input boundary is where adversarial payloads first enter the system. Enforcing controls here, before any data reaches the model, limits the blast radius of injection attacks and data exposure events.

Runtime prompt injection mitigation

Prompt injection attacks (direct and indirect) bypass application logic by embedding malicious instructions inside user inputs, retrieved documents, or tool responses that the model then executes as instructions. In agentic workflows, an indirect injection embedded in a web page retrieved during a browsing task can cause an agent to exfiltrate data, call unauthorized APIs, or execute commands the system prompt explicitly prohibited.

Prediction Guard intercepts incoming prompts at the control plane level, analyzing and blocking malicious payloads before they reach the model. The control plane applies this locally inside your VPC, with no external API call required to evaluate the prompt. Prediction Guard's EP03 on agentic AI threats and mitigations covers the specific mitigations that work at production scale.

PII redaction for secure AI inputs

PII redaction at the input boundary prevents your sensitive data from reaching model inference servers or from being sent to any external API endpoint your application calls. Social Security numbers, API keys, health record numbers, and financial account details are detected and masked, filtered, blocked, or replaced before the prompt is processed. For workloads subject to the Gramm-Leach-Bliley Act (GLBA), the Health Insurance Portability and Accountability Act (HIPAA), or the Cybersecurity Maturity Model Certification (CMMC), this control addresses OWASP LLM02 (Sensitive Information Disclosure) at the boundary, ensuring personal data cannot enter the model context or leave your system boundary via model inference.

Runtime defense for AI input vulnerabilities

Runtime input filtering mitigates OWASP LLM01 (Prompt Injection) and LLM02 (Sensitive Information Disclosure) by enforcing controls before any data reaches the model. Usage quotas enforce call budgets at the control plane before model calls proceed, adding a system-level check on token consumption that complements content-layer validation. The audit log records each enforcement decision as evidence, not as the enforcement mechanism itself, so security teams can trace exactly which inputs were blocked, allowed, or rewritten on every call.

Layer 2: Codifying safety controls for AI outputs

Output-side risks arise from the model's probabilistic nature, not only from malicious inputs. A well-formed prompt can still produce a policy-violating response, which is why output validation must be independent of input filtering.

Mitigating model toxicity and hallucinations

Models generate toxic, biased, or factually incorrect content because of their probabilistic nature, not solely because of malicious inputs. A well-formed, legitimate prompt can still produce a response that violates policy, reconstructs sensitive data from training, or fabricates a fact with confident phrasing. Prediction Guard's agentic AI scaling guide covers how output-side risk compounds as agent autonomy increases and response chains grow longer.

Factual consistency checking applies probabilistic verification of generated content against trusted data sources before the response reaches the end user or a downstream system. This control flags hallucinations at the output boundary and operates as one layer in a defense-in-depth architecture. It catches a significant proportion of hallucinations before they propagate, without claiming deterministic accuracy, which is why it must stack with toxicity filtering and output PII redaction.

Output filtering against downstream exploits

Output PII redaction must run on the response side as well as the input side, because models can reconstruct or generate sensitive data patterns in their responses even when the input did not contain that data. Output filtering also prevents model responses from triggering downstream vulnerabilities: generated code or structured data passed to a downstream tool can contain malicious payloads that execute in the context of the receiving system. This is the core risk addressed by OWASP LLM05 (Improper Output Handling), and system-level output filtering intercepts these responses before they reach any downstream execution context.

Layer 3: Codifying security policies for AI systems

Access control defines which users, agents, and applications are permitted to invoke registered models and tools. Without centralized enforcement, that decision is made implicitly by whoever holds an API key.

Controlling access to AI endpoints

Access controls configured in the Admin Console define which users, teams, agents, and applications may invoke which models or tools, enforced uniformly at the control plane on every request. Developers do not manage access logic inside application code, eliminating the audit gap that arises when access decisions are scattered across individual codebases. Without centralized access control, access decisions default to wherever API keys are managed, which is typically individual codebases, leaving no consistent record of which identity invoked which model under which policy.

Enforcing policy via code at runtime

The developer integration pattern is the key to making governance enforceable without blocking delivery. Existing OpenAI-compatible or Anthropic-compatible SDK calls work unchanged. Only the base_url is repointed at the Prediction Guard control plane endpoint:

# Python example using OpenAI SDK - only base_url changes from openai import OpenAI  client = OpenAI(     base_url="https://your-pg-control-plane-endpoint",     api_key="your-pg-api-key" )  response = client.chat.completions.create(     model="your-chosen-model",     messages=[{"role": "user", "content": user_input}] ) 

Every request passing through this endpoint is evaluated against the governance policies configured in the Admin Console, whether the developer knows those policies exist or not. Security teams configure policies once. The control plane enforces them on every call regardless of which framework the developer used.

Restricting agent autonomy

OWASP LLM06 (Excessive Agency) describes the risk that an agent is granted more capability than it needs and exercises it in ways the application owner did not intend. System-level constraints on which tools an agent can call and which models it can access address this risk deterministically. Usage quotas prevent runaway agent workloads from consuming model capacity in ways that violate cost governance or create availability risk for other systems.

Layer 4: Proving governance with traceable data

Enforcement is only auditable if the log record is structured consistently across every call. Unstructured or incomplete logs answer the policy question but leave the evidence question open during a conformity assessment.

Standardizing AI logs for compliance

Prediction Guard generates structured audit logs as a byproduct of active runtime enforcement. Each log entry records the enforcement decision that happened on that call, not a retrospective analysis of what might have happened. ISO/IEC 42001 conformity assessors and AIUC-1 assessors evaluating the Accountability pillar look for exactly this: proof of consistent, system-level enforcement rather than policy documents and manual review workflows. Critically, Prediction Guard generates these logs but does not store or retain them. Log retention is handled entirely by the customer's SIEM.

Exporting governance logs to SIEM

The Monitor page in the Admin Console configures how audit log output is formatted to match the native field structure of your SIEM. The workflow is:

1. Open the Monitor page in the Admin Console.
2. Click Configure under your chosen integration target type (cloud SIEM, agent-based collector, or syslog forwarder).
3. Confirm to activate the integration, signaling Prediction Guard to format output using that SIEM's expected field structure.
4. Your existing ingestion pipeline (HEC endpoint, Datadog agent, syslog collector) handles delivery under your own controls.

Prediction Guard does not hold SIEM API keys, HEC tokens, or credentials of any kind. The integration configures output formatting. Delivery is your infrastructure. SIEM-ingested enforcement logs then serve as the primary evidence trail for ISO/IEC 42001 conformity assessments and AIUC-1 evaluations, answering the assessor's core question: show me evidence that policy X was enforced on AI interaction Y at time Z.

Optimizing control flow for low-latency AI security

Deployment architecture determines whether security controls add meaningful latency to production AI workloads. The common assumption that governance and performance trade off is specific to external gateway architectures, not self-hosted ones.

Self-hosted deployment eliminates external latency

The latency argument against adding security controls assumes the controls route traffic to an external SaaS service and back before the model call completes. That assumption is correct for external gateways, and it's a real cost: every external round-trip adds network latency on top of inference latency, multiplied across every agent call in a high-throughput production workflow.

Self-hosted deployment eliminates that overhead. When the control plane runs inside your VPC or air-gapped environment, prompt evaluation and policy enforcement happen on local infrastructure with no external network call. Prediction Guard's control plane is CPU-only, so prompt injection detection, PII scanning, toxicity classification, and policy rule evaluation run locally without GPU saturation, meaning the governance layer does not compete with model inference for the most expensive resource in your stack.

The honest trade-off is that local enforcement adds some latency compared to no enforcement at all. A few milliseconds of local control plane processing is a negligible cost against the operational and regulatory consequences of a prompt injection attack that exfiltrates controlled data, a model response that reconstructs customer PII, or an audit finding that your governance program exists only in documentation.

Mitigating systemic risks in AI deployments

The most common architectural risks in production AI deployments stem from treating point-solution filters as complete governance programs. Two failure patterns account for the majority of the compliance gaps that surface during external assessments.

Over-reliance on vendor-native content filters

Hyperscaler-native content filters are point solutions for specific filter categories within their respective cloud environments. They are not governance platforms. Some automated reasoning features within these offerings have limited regional availability, excluding organizations with data residency requirements outside those zones. Organizations running models across multiple cloud providers and self-hosted infrastructure need separate safety configurations per cloud, which deepens vendor dependency and fails the portability requirements of frameworks like ISO/IEC 42001. The moment your AI traffic moves outside that cloud provider's model ecosystem, the filter coverage stops. The Prediction Guard product comparisons detail where this gap surfaces in practice.

Establishing AI asset registration as a governance baseline

AI asset registration should be established as a governance practice before production deployment becomes widespread. Registering models, tools, MCP servers, and datasets into AI Systems in the control plane defines the scope of what is governed, establishes the policy baseline for each asset, and creates the inventory record that satisfies the NIST AI RMF Map function. A typical workflow for generating a CycloneDX AIBOM includes:

1. Register: Add each model, MCP server, dataset, and tool to an AI System in the Admin Console, capturing model version, configuration, and purpose.
2. Define policies: Configure governance policies for each registered asset on the Govern page, setting input filtering, output validation, access controls, and usage quotas per asset.
3. Export: Generate the CycloneDX AIBOM from the registered AI System, producing the auditable inventory artifact that satisfies the NIST AI RMF Map function and CMMC documentation requirements for systems handling Controlled Unclassified Information.

Noblis CEO Mile Corrigan has noted the organizational imperative behind this discipline:

"This alignment offers significant opportunities for strategic collaboration on secure deployment of AI systems, including through Noblis' Artificial Intelligence Assurance Implementation (AI2) solution for AI safety, and further strengthens our ability to help customers navigate AI adoption while safeguarding sensitive data." - Mile Corrigan, CEO of Noblis

The hidden costs of custom AI controls

Build vs. buy decision matrix

Organizations building custom AI governance infrastructure typically face significant resource investments. Building a self-hosted governance stack from scratch requires sustained engineering investment before the first enforcement control is active in production. These estimates don't include the cost of keeping pace with the evolving agentic AI threat landscape, which requires continuous engineering attention to update detection logic as new attack patterns emerge.

The structural gap between a policy documented in a repository and a control enforced at the API level is where AI production deployments fail compliance reviews. Stacking four independent, self-hosted controls closes that gap with the deterministic enforcement evidence that security teams, end customers, and external examiners require. Before the next audit cycle, answer this: is your governance policy enforced on every model call, and does the evidence live inside your perimeter or outside it?

Book a deployment scoping call to assess how a self-hosted control plane fits your VPC or air-gapped infrastructure, or review the NIST AI RMF and OWASP LLM Top 10 capability mapping to evaluate which system-level controls your current architecture is missing.

FAQs

How many layers of defense are recommended for a production AI application?

A minimum of four independent layers is recommended: input filtering, output validation, role-based access control, and SIEM-integrated runtime logging. Regulated environments handling CUI, PHI, or non-public financial information should add AI System registration with AIBOM export and factual consistency checking as fifth and sixth controls.

Which OWASP LLM Top 10 risks does a self-hosted control plane directly mitigate?

A self-hosted control plane directly mitigates LLM01 (Prompt Injection) through runtime input filtering, LLM02 (Sensitive Information Disclosure) through PII redaction on input and output, LLM05 (Improper Output Handling) through output validation and toxicity filtering, and LLM06 (Excessive Agency) through role-based access controls and usage quotas enforced before model calls complete.

Can AWS Bedrock Guardrails satisfy multi-cloud compliance requirements?

No. Bedrock Guardrails are scoped to AWS infrastructure and cannot govern models running on Azure, GCP, or self-hosted infrastructure, failing the portability requirements of multi-cloud strategies. Organizations with air-gapped deployments require a cloud-agnostic control plane that governs all registered models under one policy regardless of where they run.

How do runtime security controls map to AIUC-1 requirements?

Runtime controls provide the deterministic policy enforcement and structured audit logs required to satisfy the Security, Safety, and Accountability pillars of the AIUC-1 standard. The AIUC-1 crosswalk mappings show exactly which control plane capabilities satisfy which pillar requirements across the six-pillar framework.

Does Prediction Guard store audit logs or SIEM credentials?

No. Prediction Guard generates structured audit logs as a byproduct of runtime enforcement and formats them for SIEM ingestion, but does not store or retain logs and does not hold SIEM API keys, HEC tokens, or credentials of any kind. Log retention and SIEM-specific storage is handled entirely by the customer's own infrastructure.

Key terms glossary

Control plane: The governance infrastructure layer that intercepts AI requests, evaluates them against defined policies, and allows, blocks, or rewrites them before returning a response, as distinct from the model inference layer.

Defense-in-depth: A security architecture strategy that stacks multiple independent controls so that the failure of any single control does not expose the system to the full risk it was designed to prevent.

Deterministic policy enforcement: Policy rules that produce the same enforcement action every time the rule condition is met, regardless of model output variation. Applies to PII redaction, toxicity filtering, and access control decisions.

AIBOM (AI Bill of Materials): A machine-readable inventory of AI assets in a production system, including model versions, tool registrations, and configuration state, exported in CycloneDX format for auditor review and supply chain visibility.

Factual consistency checking: Probabilistic verification of generated model output against trusted data sources to flag potential hallucinations before they reach the end user. This control is not deterministic because it operates on probabilistic model outputs.

Data sovereignty: The organizational property that data, governance logic, and audit logs remain inside the organization's own defined infrastructure boundary and do not transit third-party vendor systems.

AI Security Posture Management (AI-SPM): Continuous assessment and enforcement of governance posture across registered AI assets, identifying components operating outside defined policies and producing evidence of enforcement for compliance purposes.