shieldx/docs/eu-ai-act-compliance.md
Rene Fichtmueller 1c4c034483 feat: ShieldX v0.3.0 — UnicodeScanner (L5), DNS Covert Channel rules, ATLAS v5.4 mappings
- Layer 4 EntropyScanner: Shannon entropy, Base32/Base64 detection, CVE-2025-55284
  ping/nslookup exfil, EchoLeak markdown pattern, DNS tunneling (iodine/dnscat)
- Layer 5 UnicodeScanner: ASCII Smuggling (U+E0000 Tags Block), Variant Selectors,
  Zero-Width steganography, CamoLeak image-ordering (CVE-2025-53773), homoglyphs,
  BiDi override, high-entropy URL params
- 30 DNS covert channel rules (dns-001 to dns-030)
- ATLASMapper: 29 techniques (ATLAS v5.4.0 Feb 2026), added AML.T0062 (Agent Tool
  Invocation), AML.TA0015 (C2 tactic), memory poisoning, multi-agent trust,
  CamoLeak, Unicode steganography mappings
- Rule count: 72 → 102
- Build: tsup 316ms, zero TypeScript errors
2026-03-31 16:32:16 +02:00

305 lines
13 KiB
Markdown

# EU AI Act Compliance
## Overview
ShieldX provides tooling to help organizations comply with the European Union Artificial Intelligence Act (Regulation 2024/1689), specifically the articles relevant to high-risk AI systems that incorporate large language models. ShieldX is not a legal compliance tool -- it is a technical implementation that addresses the measurable, auditable requirements of the regulation.
Enable EU AI Act compliance reporting:
```typescript
const shield = new ShieldX({
compliance: { euAiAct: true },
})
```
This document covers Articles 9, 12, 14, and 15 -- the articles most relevant to LLM security and prompt injection defense.
---
## Article 9: Risk Management System
### What the Article Requires
High-risk AI systems must have a risk management system that:
1. Identifies and analyzes known and reasonably foreseeable risks
2. Estimates and evaluates risks that may emerge during intended use and reasonably foreseeable misuse
3. Adopts risk management measures to address identified risks
4. Tests the system to ensure residual risks are acceptable
### How ShieldX Addresses This
| Requirement | ShieldX Implementation | Evidence |
|-------------|----------------------|----------|
| Risk identification | MITRE ATLAS mapping identifies 44 attack techniques; OWASP LLM Top 10 maps 10 risk categories | `ComplianceReport.totalTechniques`, `ComplianceReport.coveredTechniques` |
| Risk estimation | Kill chain classification assigns severity levels (none, low, medium, high, critical) per detected threat | `ShieldXResult.threatLevel`, `ShieldXResult.killChainPhase` |
| Risk mitigation | 10-layer defense pipeline with phase-appropriate healing actions | `ShieldXResult.action`, `ShieldXResult.healingApplied` |
| Residual risk documentation | Gap analysis identifies uncovered ATLAS techniques | `ComplianceReport.gaps`, `ComplianceReport.recommendations` |
| Testing | Red Team Engine generates adversarial variants; benchmark suite measures ASR and false positive rate | `npm run self-test`, `npm run benchmark` |
### EU AI Act Report Fields
```typescript
interface EUAIActReport {
article9RiskManagement: {
riskIdentification: boolean // ATLAS + OWASP mapping enabled
riskMitigation: boolean // Healing engine active
residualRisks: string[] // Uncovered ATLAS techniques
testingPerformed: boolean // Red team + benchmark results available
}
}
```
### Generating a Risk Assessment
The `EUAIActReporter` module produces a structured report:
```typescript
const shield = new ShieldX({ compliance: { euAiAct: true } })
await shield.initialize()
// After running the system for a period:
const report = await shield.generateComplianceReport('eu_ai_act')
// report.article9RiskManagement contains:
// - riskIdentification: true (ATLAS mapping active)
// - riskMitigation: true (healing engine active)
// - residualRisks: ['AML.T0003', 'AML.T0004', ...] (techniques not covered)
// - testingPerformed: true/false (based on last red team run)
```
---
## Article 12: Record-Keeping (Logging)
### What the Article Requires
High-risk AI systems must enable automatic recording of events (logs) throughout the system's lifetime. Logging must:
1. Enable traceability of system functioning
2. Record events relevant to identifying risks
3. Maintain logs for an appropriate retention period
4. Be accessible for monitoring and audit
### How ShieldX Addresses This
| Requirement | ShieldX Implementation | Evidence |
|-------------|----------------------|----------|
| Automatic event recording | Every scan produces a structured `ShieldXResult` with timestamp, scan ID, scanner results, and actions | `ShieldXResult.id`, `ShieldXResult.timestamp` |
| Risk-relevant events | All detected threats are logged as `IncidentReport` with full context | `IncidentReport.id`, `IncidentReport.timestamp` |
| Traceability | Each scan result links to specific scanner IDs, matched patterns, and kill chain phase | `ScanResult.scannerId`, `ScanResult.matchedPatterns` |
| Audit trail | Incident reports include ATLAS technique IDs and OWASP risk mappings | `IncidentReport.atlasMapping`, `IncidentReport.owaspMapping` |
| Structured logging | Pino JSON logging with configurable levels | `logging.structured: true` |
### Incident Report Structure
Every incident generates a structured report:
```typescript
interface IncidentReport {
id: string // Unique incident ID
timestamp: string // ISO 8601 timestamp
sessionId?: string // Session identifier (if available)
userId?: string // User identifier (if available)
threatLevel: ThreatLevel // none | low | medium | high | critical
killChainPhase: KillChainPhase // 7-phase classification
action: HealingAction // Action taken
attackVector: string // Description of the attack vector
matchedPatterns: string[] // Pattern IDs that triggered detection
inputHash: string // SHA-256 hash (never raw input)
mitigationApplied: string // Description of mitigation
falsePositive?: boolean // Post-hoc feedback
atlasMapping?: string // MITRE ATLAS technique ID
owaspMapping?: string // OWASP LLM risk ID
}
```
### EU AI Act Report Fields
```typescript
interface EUAIActReport {
article12Logging: {
incidentLogging: boolean // Incident logging enabled
auditTrail: boolean // ATLAS/OWASP mappings in incident reports
retentionPeriod: string // Configured retention period
totalIncidents: number // Total incidents recorded
}
}
```
### Privacy Consideration
ShieldX never stores raw user input in logs or incident reports. All input references are SHA-256 hashes. This is compatible with GDPR data minimization requirements while still providing the traceability required by Article 12.
---
## Article 14: Human Oversight
### What the Article Requires
High-risk AI systems must be designed to allow effective human oversight, including:
1. The ability for humans to understand the AI system's capabilities and limitations
2. The ability to monitor the system's operation
3. The ability to override or reverse the system's decisions
4. The ability to intervene or stop the system
### How ShieldX Addresses This
| Requirement | ShieldX Implementation | Evidence |
|-------------|----------------------|----------|
| Understanding capabilities | Full configuration transparency; every scanner and threshold is documented and configurable | `ShieldXConfig` (all fields documented) |
| Monitoring | Structured logging, incident reports, compliance reports, `getStats()` API | `LearningStats`, `ComplianceReport` |
| Override/reverse | `submitFeedback()` API for marking false positives; per-phase healing strategies are configurable | `shield.submitFeedback(scanId, { isFalsePositive: true })` |
| Intervention | All layers independently toggleable; master kill switch via `healing.enabled: false`; `destroy()` for clean shutdown | Config toggles, `shield.destroy()` |
### Human-in-the-Loop Integration
ShieldX supports human-in-the-loop workflows:
1. **Active Learning**: The learning engine identifies uncertain samples and surfaces them for human review via the `ActiveLearner` module. This ensures humans are involved in decisions at the classifier's uncertainty boundary.
2. **Feedback Loop**: The `submitFeedback()` API allows human operators to correct false positives and false negatives. This feedback is processed by the `FeedbackProcessor` to improve detection accuracy.
3. **Configurable Actions**: The `healing.phaseStrategies` configuration allows operators to set per-phase responses. Setting an action to `warn` instead of `block` enables human review before action is taken.
4. **Incident Review**: Incident reports are structured for human review, with ATLAS and OWASP mappings providing standardized context.
### EU AI Act Report Fields
```typescript
interface EUAIActReport {
article14HumanOversight: {
humanInTheLoop: boolean // Active learning enabled
overrideCapability: boolean // Feedback API available
feedbackMechanism: boolean // Feedback processing enabled
}
}
```
---
## Article 15: Accuracy, Robustness, and Cybersecurity
### What the Article Requires
High-risk AI systems must achieve appropriate levels of:
1. **Accuracy**: The system must perform at an appropriate level of accuracy
2. **Robustness**: The system must be resilient to errors and inconsistencies
3. **Cybersecurity**: The system must be protected against unauthorized access and adversarial attacks
### How ShieldX Addresses This
#### Accuracy
| Metric | Measurement Method | Target |
|--------|-------------------|--------|
| False positive rate | Tracked via feedback loop; `LearningStats.falsePositiveRate` | <5% |
| False negative rate | Measured via red team testing; `npm run self-test` | <15% against known patterns |
| Detection accuracy | PINT benchmark, AgentDojo benchmark | Published with each release |
ShieldX measures accuracy through:
- **Feedback Loop**: Every false positive report adjusts the classifier and threshold
- **Red Team Testing**: Automated adversarial testing measures the false negative rate
- **Benchmark Suite**: Standardized benchmarks (PINT, AgentDojo) provide comparable accuracy metrics
#### Robustness
| Property | Implementation |
|----------|---------------|
| Graceful degradation | Every scanner is wrapped in try/catch; `Promise.allSettled` ensures failing scanners do not block the pipeline |
| No single point of failure | 10 independent layers; any subset can operate alone |
| Adaptive thresholds | `ThresholdAdaptor` adjusts to changing attack patterns |
| Drift detection | `DriftDetector` alerts when attack patterns shift |
#### Cybersecurity
| Property | Implementation |
|----------|---------------|
| Defense in depth | 10 layers, each catching different attack types |
| Zero trust for data sources | `TrustTagger` assigns per-source trust scores; no data source is trusted by default |
| Cryptographic integrity | `SignedPromptVerifier` for system prompts; `ManifestVerifier` for MCP servers |
| No raw data storage | SHA-256 hashes only; raw input never persists |
| Self-testing | Red Team Engine continuously probes for weaknesses |
| Supply chain verification | `SupplyChainVerifier` and `ModelProvenanceChecker` |
### EU AI Act Report Fields
```typescript
interface EUAIActReport {
article15Accuracy: {
falsePositiveRate: number // Current FP rate
falseNegativeRate: number // Current FN rate (from red team)
benchmarkResults: Record<string, number> // PINT, AgentDojo, etc.
}
conformityAssessment: {
selfAssessment: boolean // Self-test has been run
thirdPartyAudit: boolean // External audit performed
lastAssessmentDate?: string // ISO date of last assessment
}
}
```
---
## Generating Compliance Reports
### Full EU AI Act Report
```typescript
const shield = new ShieldX({ compliance: { euAiAct: true } })
await shield.initialize()
// After operating the system:
const report = await shield.generateComplianceReport('eu_ai_act')
```
The report covers all four articles with structured, auditable data.
### Combined Report (ATLAS + OWASP + EU AI Act)
```typescript
const report = await shield.generateComplianceReport('combined')
```
### Periodic Reporting
For continuous compliance, schedule regular report generation:
```typescript
// Generate weekly compliance reports
setInterval(async () => {
const report = await shield.generateComplianceReport('eu_ai_act')
await saveComplianceReport(report) // Your persistence layer
}, 7 * 24 * 60 * 60 * 1000)
```
---
## Risk Classification
The EU AI Act classifies AI systems by risk level. ShieldX helps determine and document the risk classification:
| Risk Category | Criteria | ShieldX Relevance |
|---------------|----------|-------------------|
| Unacceptable risk | Manipulative, exploitative, or social scoring systems | Out of scope (prohibited uses) |
| High risk | AI in critical infrastructure, education, employment, law enforcement, etc. | Full compliance tooling (Articles 9, 12, 14, 15) |
| Limited risk | Chatbots, emotion recognition, deep fakes | Transparency obligations; ShieldX provides audit trail |
| Minimal risk | Spam filters, AI-assisted games | No specific obligations; ShieldX still provides defense |
For high-risk AI systems, ShieldX provides the technical foundation for demonstrating compliance with the mandatory requirements. The compliance reports are designed to be presented to auditors and regulatory bodies as evidence of systematic risk management.
---
## Limitations
ShieldX provides technical tooling for compliance. It does not provide:
- Legal advice on whether your AI system is classified as high-risk
- Legal interpretation of EU AI Act articles
- Representation before regulatory authorities
- Certification or conformity marking
Organizations should consult legal counsel to determine their specific obligations under the EU AI Act and use ShieldX's compliance reports as technical evidence within their broader compliance strategy.