APIRE's Five-Layer AI Security Architecture Explained
- 1 hour ago
- 5 min read
Every AI API request your organisation sends carries two classes of risk simultaneously: the data inside the prompt, and the intent behind it. A WAF inspects neither. Traditional DLP inspects one, partially, after the fact. APIRE's five-layer defense pipeline was designed specifically for this gap — a transparent security proxy that intercepts every prompt and every response, inspects both inline, and makes a disposition before the AI provider ever sees the payload.
What follows is a precise, layer-by-layer account of how that pipeline works, what each stage catches, and why the ordering is deliberate.
The architectural premise
APIRE operates as a transparent proxy between your applications and AI providers — OpenAI, Anthropic, Gemini, and others. Integration is a single endpoint URL swap; no SDK changes, no code modifications, no agents required. Every prompt and every response traverses all five layers before the provider receives the input or the application receives the output.
All processing occurs in volatile RAM under a Zero-Retention Architecture: no prompt, no response, no masked value is written to persistent storage. For organisations operating under GDPR data-residency constraints or NIS2 security obligations, this is an architectural property, not a policy setting.
The five layers are not independent scanners running in parallel. They are a sequential pipeline, ordered by performance cost and threat class. High-volume, well-known attacks are eliminated at the perimeter before computationally intensive semantic analysis runs downstream.
Layer 0 — Sentinel: AI-Powered Gateway
Sentinel is the outermost perimeter — the first stage every request encounters. Its function is to identify and block well-known, high-volume attacks at scale before they consume resources deeper in the stack.
Sentinel covers 100,000+ attack vectors, updated continuously by AI rather than by manual signature release cycles. Latency impact is minimal by design: the explicit goal is to absorb the loud, recognisable attack surface so that the four specialised detection layers behind it can focus analytical capacity on subtle, semantically complex threats.
For context: AI-specific attacks increased 67% year-over-year, with 2,500+ daily threats recorded across AI API infrastructure. A significant portion of that volume consists of recognisable patterns — known jailbreak templates, repeated injection scaffolds, previously catalogued adversarial inputs. Sentinel handles that class of traffic at the gate.
Layer 1 — Content Safety Shield
Where Sentinel handles known attack patterns, Layer 1 handles content classification — determining whether a prompt or response falls within acceptable content boundaries across 14 defined safety categories.
Those categories span violent crimes, non-violent crimes, indiscriminate weapons, sex-related crimes, child sexual exploitation, hate speech, suicide and self-harm, defamation, sexual content, specialised advice, elections, privacy violations, intellectual property, and code interpreter abuse. Each request receives a binary SAFE/UNSAFE verdict with automatic severity scoring: Critical, High, or Medium.
Coverage extends across 32+ languages, which matters practically for multinational enterprise deployments where employees submit prompts in their working language. A content safety control that classifies accurately in English but degrades in Dutch, Polish, or Romanian is not a compliant control under the EU AI Act's requirements for accuracy and robustness across foreseeable use conditions.
The code interpreter abuse category deserves specific attention. As enterprises deploy coding assistants and AI-powered IDEs, prompts that attempt to weaponise the model's code execution capabilities — generating malware, exfiltrating data through generated scripts — require a classification path that doesn't exist in document-oriented DLP tools.
Layer 2 — AI Threat Protection Shield
Layer 2 is the semantic core of the pipeline. It addresses the category of threats that have no equivalent in traditional security tooling: attacks that are structurally valid, syntactically normal natural language, carrying adversarial intent detectable only through semantic analysis of the prompt's meaning and target.
This layer covers 27 threat categories in aggregate: 5 core AI threat categories and 8 advanced categories. Core threats include prompt injection, jailbreaking, and data exfiltration attempts. Advanced categories extend to model inversion, context manipulation, business logic attacks, and others that exploit the specific trust and reasoning characteristics of large language models.
Two capabilities within Layer 2 warrant precise description:
Encoding attack normalisation. Adversarial payloads are frequently obfuscated — Base64, Unicode escapes, hex encoding, homoglyph substitution, and combinations thereof — specifically to evade surface-level pattern matching. APIRE's normalisation engine handles 26+ encoding vectors across 13 normalisation stages, with support for 3 levels of nested recursion. A prompt that encodes its injection payload through two layers of Base64 inside a Unicode escape sequence does not survive this stage intact.
Multi-vector correlation. Individual threat signals are scored in isolation and in combination. When four or more threat categories fire on the same request, the composite risk score amplifies by 40%. This is architecturally significant: sophisticated, coordinated attacks deliberately stay below single-category detection thresholds. A coordinated campaign that scores a 6/10 on prompt injection, a 5/10 on context manipulation, and a 4/10 on data exfiltration simultaneously is a fundamentally different threat than any of those signals in isolation. Multi-vector correlation is the mechanism that surfaces it.
Layer 2 also supports both automatic tuning and manual tuning, with zero-day defense capabilities — the pipeline does not require a known attack signature to flag semantically anomalous behaviour.
Layer 3 — Multi-Word Pattern Protection
Layer 3 provides dictionary-based detection for organisational-specific sensitive content: proprietary project names, internal product codenames, acquisition targets, personnel identifiers, and other information that a generic threat model has no visibility into.
This is the layer where security policy becomes organisational context. A financial institution can define terms specific to an unreleased product line. A pharmaceutical company can protect molecule names and trial identifiers. The corpus of protected terms is defined at the organisational level and enforced inline on every request.
This capability is distinct from DLP in the conventional sense. Traditional DLP inspects outbound documents against pattern libraries of structured data types. Layer 3 inspects prompts in transit against organisational dictionaries in real time, before the content reaches the AI provider.
Layer 4 — Data Protection Shield: Inline Masking
Layer 4 addresses the data leakage problem that 8.5% of all prompts to AI tools represent — prompts containing PII, credentials, PHI, PCI data, API keys, or other sensitive values that should never reach an external model.
The mechanism is inline masking with role-based restoration. When a sensitive value is detected, it is replaced with a masked token before the prompt is forwarded to the AI provider. The model processes the token, not the raw value. On the response path, authorised users receive the unmasked value restored; unauthorised users receive the token. The model never processes the original data at any point.
The rule set covers 950+ DLP rules across 150+ data types. This is not a retrofit of a document-scanning DLP engine — it operates inline, bidirectionally, on prompt and response simultaneously, in a context (natural language) that structured-data DLP was not built to handle.
For EU AI Act Article 10 compliance — which imposes data governance requirements on training and operational data — and for NIS2 security measure obligations, inline masking that operates before data leaves the organisational boundary is a materially stronger control than post-hoc detection.
Compliance instrumentation across all layers
Regulatory visibility is not a separate module. Article-by-article mapping to EU AI Act Articles 10, 14, 15, and 52 runs across the full pipeline, surfaced through live compliance dashboards. Full audit trails with SIEM webhook integration are available for the 160,000+ entities within NIS2 scope — providing the continuous, documented evidence of security measures that both frameworks require.
The ordering is the architecture
The five layers are not interchangeable. Sentinel's high-volume perimeter filtering makes Layer 2's semantic analysis economically viable at scale. Layer 4's inline masking operates on content that has already been classified by Layers 1 and 2, enabling richer context for masking decisions. Multi-vector correlation in Layer 2 only becomes meaningful when multiple upstream signals are available.
This is a designed sequence, not a modular checklist. That distinction matters for CISOs evaluating purpose-built AI security against retrofitted WAF or DLP extensions: the gap is not feature coverage, it is architectural coherence.
Deployment is a single endpoint swap. Cloud, on-premises, and hybrid models are available, including air-gapped on-premises operation for data-residency-constrained workloads.
→ Request a technical walkthrough with a security architect: https://apire.io/signup
