EU AI Act Compliance Mapping - Pipelock#
How Pipelock's runtime security controls map to the EU AI Act (Regulation 2024/1689) requirements for high-risk AI systems, with a NIST AI RMF 1.0 crosswalk.
Scope: Pipelock is an application-layer firewall for AI agent deployments. It covers network egress filtering, content inspection, audit logging, and human oversight. It doesn't cover model training, data governance, or full-lifecycle AI management. Coverage gaps are documented below.
Disclaimer: This document maps Pipelock's security features to EU AI Act requirements for informational purposes. It does not constitute legal advice or guarantee regulatory compliance. Organizations should consult qualified legal counsel for compliance obligations specific to their AI systems.
Last reviewed: August 2026 against v3.4.0. This mapping describes current
behavior; see CHANGELOG.md for release history.
Recent control additions reviewed:
-
Art. 12 / 15: v3.4 distinguishes policy findings from incomplete scan results and blocks unscanned oversized reverse-proxy media bodies.
-
Art. 13 / 14: v3.4 removes configuration fields that had no runtime consumer, reducing the chance that an operator mistakes inert configuration for enforcement.
-
Art. 12: block-reason receipts, scan API tool-call findings, and file_sentry skip visibility improve operator records for mediated decisions and uninspected local files.
-
Art. 13:
request_policy_denyblock reasons and explicit scan-cap failure behavior make denial causes more transparent to operators and agent clients. -
Art. 14:
verify-installWebSocket coverage and file_sentry block mode give deployers more concrete checks and controls over protected agent runtime behavior. -
Art. 15:
request_policyoperation rails, per-frame WebSocket enforcement, header-DLP parity, and submit-profile SSRF-safe dialing strengthen runtime robustness against unsafe egress. -
Art. 15(4)/(5): redaction passthrough hardening, media canonical-end truncation, and response scan-cap fail-closed behavior reduce avoidable corruption while keeping cybersecurity controls fail-closed.
Fleet control-plane documentation ships in v2.7: see the
Conductor guide.
Coverage Summary#
Coverage levels: Full = Pipelock feature directly implements the requirement with automated enforcement. Partial = feature contributes to the requirement but doesn't fully satisfy it alone. Moderate = multiple features partially address the requirement.
| Article | Topic | Coverage |
|---|---|---|
| Art. 9 | Risk Management System | Partial (runtime controls only) |
| Art. 12 | Record-Keeping | Partial (mediated events; core delivery is best-effort) |
| Art. 13 | Transparency | Moderate |
| Art. 14 | Human Oversight | Moderate (terminal-only HITL) |
| Art. 15 | Accuracy, Robustness, Cybersecurity | Moderate |
| Art. 26 | Deployer Obligations | Moderate |
EU AI Act Article Mapping#
Article 9 - Risk Management System#
Article 9 requires a continuous, iterative risk management process throughout the AI system lifecycle. This includes risk identification, mitigation through design, prior-defined testing metrics, and post-market monitoring.
| Requirement | Pipelock Feature | Coverage |
|---|---|---|
| Identify and analyze known risks (Art. 9(2)(a)) | Ordered scanner pipeline classifies mediated network risks through URL validation, destination policy, DLP, entropy analysis, SSRF/rebinding protection, rate limiting, and data budgets | Partial |
| Evaluate risks under foreseeable misuse (Art. 9(2)(b)) | Adversarial testing of bypass attempts (encoded secrets, DNS exfiltration, zero-width injection, split-key attacks) | Partial |
| Post-market monitoring data (Art. 9(2)(c)) | Prometheus metrics (/metrics), JSON stats (/stats), structured audit logs | Partial |
| Eliminate risks through design (Art. 9(5)(a)) | Capability separation reduces network-based credential exfiltration risk: agent holds secrets with no network; proxy has network with no agent secrets. Deployment enforces the boundary | Partial |
| Mitigation and control measures (Art. 9(5)(b)) | Multi-layer scanning, domain blocklist, rate limiting, DLP patterns, HITL approval | Full |
| Residual risk information to deployers (Art. 9(5)(c)) | Audit events document mediated scanner and policy decisions; /stats surfaces observed threats. Completeness still depends on deployment routing and sink delivery | Partial |
| Prior defined metrics and thresholds (Art. 9(8)) | Configurable thresholds per scanner layer; Prometheus counters for block rates by category | Full |
| Continuous lifecycle process (Art. 9(2)) | Hot-reload config (fsnotify + SIGHUP) for live policy updates without restart | Partial |
Gap: Art. 9 covers the full AI system lifecycle. Pipelock provides runtime network-level risk management. Lifecycle-wide risk identification (health, safety, fundamental rights impacts) and systematic misuse analysis require organizational processes beyond runtime controls.
Article 12 - Record-Keeping#
Article 12 requires automatic event logging in high-risk AI systems for risk identification, post-market monitoring, and deployer oversight.
| Requirement | Pipelock Feature | Coverage |
|---|---|---|
| Automatic recording of events (Art. 12(1)) | Structured JSON logging records mediated scanner and policy events with transport-appropriate fields. External emission is best-effort unless the Enterprise durable SIEM path is used | Partial |
| Identify risk situations (Art. 12(2)(a)) | Categorized threat events: SSRF, DLP match, prompt injection, env leak, entropy anomaly, rate limit, redirect chain | Full |
| Support post-market monitoring (Art. 12(2)(b)) | Prometheus metrics with counters, histograms, and alerting integration; Grafana dashboard (configs/grafana-dashboard.json) | Full |
| Enable deployer monitoring (Art. 12(2)(c)) | Per-agent profiles provide named identity, independent config, and per-agent budgets; mediated events carry resolved agent identity when available | Partial |
Gap: Pipelock cannot prove that traffic bypassing the mediated boundary was
recorded, and core external emission is best-effort. Full Article 12 also
includes system-level retention and biometric requirements that are outside
this component's scope.
Article 13 - Transparency#
Article 13 requires sufficient operational transparency for deployers to understand system behavior, including documentation of capabilities, limitations, logging mechanisms, and human oversight measures.
| Requirement | Pipelock Feature | Coverage |
|---|---|---|
| System characteristics and capabilities documented | README, OWASP mapping docs, Claude Code integration guide, comparison doc | Full |
| Limitations documented | Each OWASP mapping doc includes explicit coverage gaps and "out of scope" sections | Full |
| Logging mechanism description | Audit log format, event types, and fields documented in CLAUDE.md and guides | Full |
| Human oversight measures described (Art. 14 ref) | HITL documentation in guides and config presets | Partial |
| Computational/hardware requirements | Single-binary deployment and reproducible performance benchmarks are documented; artifact size varies by platform, build tags, and release flags | Partial |
Gap: Full Art. 13 compliance requires system-level documentation that depends on the deployer's AI system, not just the security layer.
Article 14 - Human Oversight#
Article 14 requires AI systems to be designed for effective human oversight, including the ability to understand system operation, detect anomalies, override or reverse outputs, and intervene or interrupt via a "stop" mechanism.
| Requirement | Pipelock Feature | Coverage |
|---|---|---|
| Understand system operation (Art. 14(4)(a)) | Audit logs, Prometheus metrics, /stats endpoint, Grafana dashboard | Full |
| Detect anomalies and dysfunctions (Art. 14(4)(a)) | Real-time threat detection via pattern matching and entropy threshold analysis | Partial |
| Override or reverse output (Art. 14(4)(d)) | HITL action: ask lets the operator approve, deny, or strip on each flagged request, but only for flagged traffic rather than all system outputs | Partial |
| Intervene or interrupt via "stop button" (Art. 14(4)(e)) | Fail-closed design: HITL timeout defaults to block; context cancellation stops operation | Full |
| Awareness of automation bias (Art. 14(4)(b)) | Configurable modes (audit/balanced/strict) force explicit enforcement decisions | Partial |
| Commensurate with risk level (Art. 14(3)) | Three preset modes map to different risk tolerances; per-scanner thresholds configurable | Full |
| Built into system by provider (Art. 14(3)) | HITL module compiled into binary; fail-closed defaults are structural, not configurable | Full |
Gap: HITL is terminal-only. No UI for non-terminal environments.
Article 15 - Accuracy, Robustness, and Cybersecurity#
Article 15 requires resilience against unauthorized alteration, with specific protections against data poisoning, model poisoning, adversarial examples (model evasion), confidentiality attacks, and model flaws (Art. 15(5)). It also requires technical redundancy and fail-safe plans (Art. 15(4)).
Note: Art. 15(5) uses "adversarial examples" and "model evasion," not "prompt injection." Pipelock's injection detection addresses a subset of the adversarial examples category through pattern-based content scanning, but doesn't cover model-level evasion attacks.
| Requirement | Pipelock Feature | Coverage |
|---|---|---|
| Adversarial examples / model evasion (Art. 15(5)) | Content scanning on responses and MCP tool results; zero-width char stripping; NFKC normalization; case-insensitive matching; null byte stripping. Covers text-based injection patterns, not model-level evasion. | Partial |
| Confidentiality attacks (Art. 15(5)) | DLP scanning (65 built-in credential patterns, extensible via config), env leak detection (raw + base64 + hex), Shannon entropy analysis, DNS subdomain exfiltration detection, split-key concatenation scanning | Full |
| Data poisoning (Art. 15(5)) | File integrity monitoring (SHA256 manifests), Ed25519 signing and verification, response scanning on fetched content | Partial |
| Resilient against unauthorized alteration (Art. 15(5)) | Pipelock blocks mediated exfiltration attempts and SSRF probes by inspecting traffic at the network and tool boundary. Coverage is bounded to traffic that traverses the Pipelock proxy (forward, intercept, reverse, fetch, MCP, WebSocket, A2A surfaces); capability separation reduces risk further when deployment topology or sandboxing forces agent traffic through Pipelock, but the topology that routes traffic through the proxy is deployment-enforced, not binary-enforced. Out-of-band channels not routed through Pipelock fall outside this control. | Partial |
| Technical redundancy / fail-safe (Art. 15(4)) | Fail-closed architecture: scan error, HITL timeout, parse failure, DNS error, context cancellation all default to block | Full |
| Resilient to errors and faults (Art. 15(4)) | DNS rebinding protection (resolve-validate-dial); IPv4-mapped IPv6 normalization; CRLF normalization in diff parsing | Full |
| Accuracy metrics declared (Art. 15(1-3)) | Prometheus counters per scanner layer; false positive tuning via audit mode | Partial |
Gap: Data poisoning in Art. 15(5) refers to training data manipulation. Pipelock's integrity monitoring protects workspace files, not training datasets. Model poisoning and model flaws are out of scope.
Article 26 - Deployer Obligations#
Article 26 requires deployers to monitor AI system operation, keep automatically generated logs for at least 6 months, and use the system per instructions.
| Requirement | Pipelock Feature | Coverage |
|---|---|---|
| Monitor operation per instructions (Art. 26(1)) | Prometheus metrics, /health endpoint for K8s liveness probes, structured audit logs | Full |
| Keep logs for 6+ months (Art. 26(6)) | Persistent audit logs with configurable output (file, stdout, or both) | Partial |
| Use system per instructions of use (Art. 26(1)) | Config presets provide instructions for different deployment contexts | Full |
Gap: Pipelock writes persistent audit logs but doesn't enforce retention periods. Whether logs are kept for 6 months depends on the deployer's log infrastructure (rotation, storage, forwarding).
What Pipelock Does Not Cover#
These require other tools or organizational processes:
| EU AI Act Requirement | Article | Why Not Covered |
|---|---|---|
| Training data governance | Art. 10 | Pipelock operates at runtime, not training time |
| Conformity assessment | Art. 43 | Organizational process, not a tool feature |
| CE marking | Art. 48 | Regulatory formality |
| Technical documentation (full system) | Art. 11 | Pipelock documents itself; full system docs are the deployer's responsibility |
| Fundamental rights impact assessment | Art. 27 | Requires organizational assessment beyond runtime controls |
| EU database registration | Art. 71 | Administrative requirement |
| Incident reporting timelines | Art. 73 | Audit logs provide incident data; reporting process is organizational |
| Bias and fairness evaluation | Art. 10(2) | Pipelock applies rules uniformly but doesn't evaluate model fairness |
| Full process isolation for the agent runtime | Art. 15(4) | Pipelock ships best-effort sandbox primitives (Landlock and network namespace isolation on Linux, plus seccomp on linux/amd64) but full process isolation for the agent itself depends on OS/container support and deployment policy. For a stricter agent-runtime sandbox see srt or agentsh. |
NIST AI RMF 1.0 Crosswalk#
How Pipelock maps to NIST AI Risk Management Framework functions, with EU AI Act cross-references.
GOVERN - Policies, Processes, and Accountability#
| NIST Subcategory | Description | Pipelock Feature | EU AI Act |
|---|---|---|---|
| GOVERN 1.2 | Trustworthy AI characteristics integrated into organizational policies | Capability separation architecture; fail-closed design philosophy | Art. 9 |
| GOVERN 1.4 | Ongoing monitoring plans documented | Prometheus metrics, audit logging, Grafana dashboard | Art. 12 |
| GOVERN 2.1 | Roles and responsibilities for AI risk management | Per-agent profiles with listener binding or source_cidrs matching (network-bound), or header-based identification (self-declared/matched); HITL assigns human approval responsibility | Art. 14 |
| GOVERN 4.2 | Organizational teams document AI risks and impacts | Structured audit logs, config files, OWASP mapping docs | Art. 11, 13 |
| GOVERN 6.1 | Third-party AI risks addressed in policy | MCP bidirectional scanning treats all MCP servers as untrusted; domain blocklists control external access | Art. 9, 15 |
| GOVERN 6.2 | Contingency processes for third-party risk | Fail-closed: scanning failure blocks traffic; HITL timeout blocks; MCP parse errors block | Art. 15 |
MAP - Context, Risk Identification#
| NIST Subcategory | Description | Pipelock Feature | EU AI Act |
|---|---|---|---|
| MAP 1.1 | Intended purposes and contexts documented | Capability separation documented; deployment guides per agent type | Art. 9, 13 |
| MAP 1.5 | Organizational risk tolerance defined | Config presets: audit (log only), balanced (default), strict (aggressive blocking) | Art. 9 |
| MAP 2.1 | System and potential harms classified | Scanner pipeline classifies: SSRF, DLP, injection, env leak, entropy, rate abuse | Art. 9 |
| MAP 4.1 | Risks prioritized by impact and likelihood | Pipeline ordering reflects priority: blocklist/DLP (critical) before DNS, SSRF before rate limit | Art. 9 |
MEASURE - Metrics, Monitoring, Assessment#
| NIST Subcategory | Description | Pipelock Feature | EU AI Act |
|---|---|---|---|
| MEASURE 1.1 | Metrics selected and documented | Prometheus: pipelock_requests_total, pipelock_scanner_hits_total, pipelock_request_duration_seconds | Art. 12 |
| MEASURE 2.5 | System demonstrated valid and reliable | CI: eight required contexts (security scan; Go 1.25 and 1.26 aggregates; macOS test; lint; build with Helm as a transitive prerequisite; govulncheck on default and enterprise graphs; CodeQL), plus race-tested OSS and enterprise matrices (see README) | Art. 15 |
| MEASURE 2.6 | Evaluated for misuse and abuse | Scanning layers target misuse: DLP catches exfiltration, SSRF catches internal probing, injection detection catches hijacking | Art. 9, 15 |
| MEASURE 2.7 | Security and resilience evaluated | Security audit completed (26 of 32 items fixed); DNS rebinding protection; fail-closed architecture | Art. 15 |
| MEASURE 3.1 | Risks tracked on ongoing basis | Prometheus real-time tracking; zerolog persistent timeline; both queryable and alertable | Art. 12 |
| MEASURE 3.3 | Feedback mechanisms for improvement | HITL ask action: human decisions logged for policy refinement; audit mode measures before enforcing | Art. 14 |
MANAGE - Risk Mitigation Controls#
| NIST Subcategory | Description | Pipelock Feature | EU AI Act |
|---|---|---|---|
| MANAGE 1.1 | Risks mitigated, transferred, or accepted | Each scanning layer configurable: enabled (mitigate), audit-only (accept with monitoring), disabled (accept) | Art. 9 |
| MANAGE 1.3 | Risk responses documented | Every block/allow decision logged with timestamp, category, action, URL, reason | Art. 12 |
| MANAGE 2.2 | Mechanisms to disengage or deactivate | HITL override; config hot-reload to tighten controls; fail-closed timeout = safe default | Art. 14 |
| MANAGE 2.3 | Procedures for appeal and human review | HITL terminal approval: agent paused, human reviews with context, decides approve/deny/strip | Art. 14 |
| MANAGE 3.1 | Third-party AI risks managed | MCP bidirectional scanning: server responses scanned for injection, client requests scanned for DLP/injection | Art. 9, 15 |
| MANAGE 4.1 | Post-deployment monitoring with incident response | Audit logs, HITL override, hot-reload for change management, Prometheus alerts, /health for K8s liveness | Art. 12 |
Control-Level Mapping#
Mapping from individual Pipelock controls to both frameworks.
| Control | Description | EU AI Act | NIST AI RMF |
|---|---|---|---|
| Capability separation | Agent has secrets, no network; proxy has network, no agent secrets. Deployment enforces boundary | Art. 15(5) | GOVERN 1.2, MAP 1.1 |
| SSRF protection | Private IP blocking, DNS rebinding prevention, metadata endpoint blocking | Art. 15(4-5) | MAP 2.1, MEASURE 2.7 |
| Domain blocklist | Configurable deny/allow lists with wildcard support | Art. 9(5) | GOVERN 1.2, MANAGE 1.1 |
| Rate limiting | Per-domain sliding window, base domain normalization | Art. 15(4) | MANAGE 1.1 |
| DLP scanning | 65 built-in credential patterns, custom regex, severity classification | Art. 15(5) | GOVERN 1.2, MEASURE 2.6 |
| Env leak detection | Raw + base64 + hex, Shannon entropy > 3.0 | Art. 15(5) | MEASURE 2.6 |
| Entropy analysis | Shannon entropy on URL path segments and query parameters | Art. 15(5) | MAP 2.1 |
| Content scanning | Response scanning with zero-width stripping, NFKC, case-insensitive | Art. 15(5) | MAP 2.1, MEASURE 2.6 |
| MCP bidirectional scanning | Request DLP/injection + response injection scanning | Art. 9(5), 15(5) | GOVERN 6.1, MANAGE 3.1 |
| HITL terminal approval | Ask action, fail-closed timeout, approve/deny/strip | Art. 14(4)(d-e) | GOVERN 2.1, MANAGE 2.2, 2.3 |
| Structured audit logging | Zerolog JSON, event classification, agent attribution, log sanitization | Art. 12, 13, 26(6) | GOVERN 4.2, MEASURE 3.1, MANAGE 4.1 |
| Prometheus metrics | Custom registry, /metrics, /stats, Grafana dashboard | Art. 12, 26(1) | MEASURE 1.1, 3.1 |
| File integrity monitoring | SHA256 manifests, check/diff, glob exclusions | Art. 15(5) | MEASURE 2.7 |
| Ed25519 signing | Key management, file signing, verification, trust store | Art. 15(5) | GOVERN 1.2 |
| Config validation | Pre-load validation, mode enforcement | Art. 9(5) | GOVERN 6.2 |
| Hot-reload | fsnotify + SIGHUP, atomic config swap | Art. 9(2) | MANAGE 4.1 |
| Fail-closed defaults | Timeout/error/parse/DNS failure all block | Art. 15(4) | GOVERN 6.2 |
| Git diff scanning | Pre-push secret detection in unified diffs | Art. 15(5) | MAP 2.1 |
High-Risk Classification Context#
Are AI coding agents high-risk under the EU AI Act?#
AI coding agents aren't explicitly listed in Annex III. The eight high-risk categories cover biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and justice administration.
Classification is context-dependent:
- An AI coding agent writing software for medical devices or critical infrastructure (Annex III, Category 2) could be classified as a safety component of a high-risk system.
- An agent used to evaluate developer performance or allocate tasks (Annex III, Category 4) could fall under employment-related high-risk classification.
- The underlying LLM likely qualifies as a general-purpose AI model under Articles 51-55, with additional obligations if it has systemic risk (>10^25 FLOPs training compute).
- Article 7 allows the Commission to expand Annex III categories via delegated acts. Agentic AI with autonomous action capabilities is actively discussed.
AI coding agents aren't formally high-risk in most cases. But organizations in regulated sectors may still choose to comply with Articles 9, 12-15 as a risk management best practice and to demonstrate due diligence.
Enforcement Timeline#
| Date | Milestone |
|---|---|
| August 1, 2024 | EU AI Act enters into force |
| February 2, 2025 | Prohibited AI practices (Art. 5) and AI literacy (Art. 4) take effect |
| August 2, 2025 | GPAI model obligations (Art. 51-55) take effect |
| February 2, 2026 | Commission publishes high-risk classification guidelines (Art. 6) |
| August 2, 2026 | High-risk AI system requirements take effect (Art. 9, 12-15, 26) |
| August 2, 2027 | Extended transition for safety-component AI under Annex I harmonization legislation |
Penalties: up to EUR 35M or 7% global turnover (prohibited practices), EUR 15M or 3% (high-risk system violations), EUR 7.5M or 1% (misleading information to authorities). SME/startup fines capped at the lower of percentage or absolute amount.
Related Frameworks#
This document complements Pipelock's existing security framework mappings:
- OWASP Top 10 for Agentic Applications - ASI01-ASI10 coverage (3 Strong, 3 Moderate, 4 Partial)
- OWASP Agentic AI Threats & Mitigations - T1-T15 coverage (7 Strong, 2 Moderate, 3 Partial)
- Competitive Comparison - Feature matrix vs AIP, agentsh, srt
OWASP → EU AI Act Compliance Chain#
OWASP has an official liaison partnership with CEN/CENELEC and ISO. The OWASP AI Exchange contributed 70 pages to ISO/IEC 27090 (the global AI security standard) and 40 pages to prEN 18282, the European cybersecurity standard for AI systems being developed under the EU AI Act. When prEN 18282 is published as a harmonized standard, compliance with it will provide a "presumption of conformity" with the relevant AI Act provisions.
Pipelock's existing OWASP mapping documents demonstrate alignment with frameworks that are being written into the EU's harmonized standards. Pipelock is one component of a defense-in-depth approach, not a complete compliance solution.
NIST AI 600-1 - Generative AI Risk Profile#
Six of twelve GAI-specific risks in NIST AI 600-1 map to Pipelock controls:
| GAI Risk | Pipelock Feature |
|---|---|
| Data Privacy | DLP scanning, env leak detection, entropy analysis |
| Information Security | SSRF protection, rate limiting, capability separation |
| Information Integrity | Content scanning, MCP response scanning |
| Human-AI Configuration | HITL approval, fail-closed defaults |
| Confabulation (tangential) | Response scanning catches manipulated content; doesn't detect hallucinations |
| CBRN Information (partial) | Domain blocklist restricts access to dangerous content sources |
NIST CAISI - AI Agent Security#
In January 2026, NIST's Center for AI Standards and Innovation published a Request for Information on security considerations for AI agents. The RFI topics (agent hijacking, backdoor attacks, exploits of autonomous agents) align directly with Pipelock's scanner pipeline and OWASP threat mappings. Comment deadline: March 9, 2026.
EU AI Act#
NIST#
- AI RMF 1.0 (PDF)
- AI RMF Playbook
- AI 600-1: Generative AI Risk Profile (PDF)
- SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models (PDF)
- CAISI RFI: AI Agent Security (Federal Register)