This document outlines the security architecture for AIXCL in adversarial environments, including known security debt, compensating controls, and threat model.

Classification: Internal Use Only
Last Updated: 2026-05-01
Owner: Security Team
Review Cycle: Quarterly

Overall Assessment: Suitable for internal adversarial testing with documented compensating controls. Not production-ready for customer-facing PCI DSS workloads without VM-level isolation.

Since containers use network_mode: host, we enforce network policies at the host level:

# Applied via scripts/security/host-firewall.sh

# Default: DROP all INPUT/FORWARD/OUTPUT
# Allow: Loopback only for service communication
# Allow: Established connections
# Block: All external access to service ports

Effectiveness: Medium
Limitations: Bypassable if attacker gains host root access
Verification: iptables -L -n -v | grep DROP

Sanitizes all LLM interactions:

• Prompt injection detection
• PII/PCI data redaction
• Rate limiting (100 requests/hour)
• Output filtering
• Audit logging

Deployment: localhost:11435 (proxy to Ollama on :11434)

Effectiveness: High
Limitations: Adds latency (~50ms per request)
Verification: Check llm_interactions table in PostgreSQL

Continuous monitoring for:

• Model extraction attempts (high query volume)
• Data exfiltration (encoding requests)
• Privilege escalation (docker socket access)
• Anomalous behavior (after-hours access)

Alerting: Slack #security channel

Effectiveness: High
False Positive Rate: ~5% (tuned via ML)
Verification: Prometheus alerts, Loki logs

Immutable logging to PostgreSQL:

• All agent actions with cryptographic chain
• LLM prompts/responses (sanitized)
• Human approval workflow
• Security events

Retention: 30 days live, optional S3 archive

Effectiveness: High
Tamper Resistance: Hash chain + append-only
Verification: scripts/audit/verify-chain.sh

Critical actions require human approval:

• git push to main/dev
• rm -rf operations
• Docker container deletion
• Schema changes
• External network requests

Approval SLA: 4 hours (24 hour timeout)

Effectiveness: Very High
Limitation: Requires 24/7 security team coverage
Verification: human_approvals table

Path: Malicious prompt → LLM → Sensitive data in response

Mitigations:

• llm-firewall injection detection
• Output PII scanning
• Rate limiting on encoding requests

Residual Risk: Medium (sophisticated jailbreaks possible)

Path: Exploit privileged container → Root on host

Mitigations:

• Remove/disable cAdvisor in production
• seccomp profiles
• read-only root filesystems

Residual Risk: High (if privileged containers required)

Path: Steal .env credentials → Access PostgreSQL/Ollama

Mitigations:

• Docker secrets (in progress)
• Host firewall (localhost only)
• Credential rotation

Residual Risk: Low (with secrets implementation)

Path: High-volume API queries → Reconstruct training data

Mitigations:

• Rate limiting (100 req/hour)
• Anomaly detection
• Query pattern analysis

Residual Risk: Medium (determined attacker with resources)

Path: Malicious Ollama model → Backdoor in inference

Mitigations:

• Local LLM preference (reduces attack surface)
• Model provenance verification (future)
• Sandboxed execution

Residual Risk: Low (with local LLM usage)

• Firewall: iptables rules (localhost-only services)
• Intrusion Detection: Falco (container runtime security)
• Monitoring: Prometheus node-exporter
• Hardening: CIS Benchmark applied where possible

• LLM Security: llm-firewall agent
• Threat Detection: threat-detector agent
• Audit Logging: PostgreSQL + cryptographic chain
• Secret Management: Docker secrets + Vault (in progress)

• Input Validation: Schema validation
• Output Encoding: Context-aware encoding
• Authentication: OAuth2/OIDC (external)
• Authorization: RBAC with principle of least privilege

T+0 minutes: Automated Detection

• Threat-detector identifies anomaly
• Alert sent to Slack #security
• Incident ID generated

T+5 minutes: Automated Containment

• Emergency lockdown triggered (if critical)
• Compromised container stopped
• Network isolation applied

T+30 minutes: Human Assessment

• Security team acknowledges alert
• Forensic evidence preserved
• Scope of breach determined

T+2 hours: Eradication

• Root cause identified
• Malicious artifacts removed
• Vulnerability patched

T+3 hours: Recovery

• Services restored from clean backups
• Monitoring enhanced
• User notification (if required)

T+4 hours: Post-Incident

• Lessons learned documented
• Controls updated
• Team debrief

Overall PCI DSS Readiness: ~70%

Blockers for Full Compliance:

1. Host networking (requires VM-level isolation or AIXCL fork)
2. Privileged containers (requires architecture change)

Recommendation: Deploy customer-facing apps inside isolated VMs with hypervisor-level network policies.

• LLM firewall agent
• Host firewall rules
• Threat detection agent
• Blast radius controller
• SECURITY.md (this document)

• Docker secrets management
• Migration scripts from .env
• PostgreSQL SSL encryption (sslmode=require)
• Certificate generation and management
• Update connection strings for SSL

• GPG-signed commits
• Podman migration (rootless)
• Automated credential rotation (threat-adaptive with human-in-the-loop)
• Penetration testing
• Security training for team

• Vault integration (HashiCorp)
• mTLS between services
• Zero-trust service mesh
• Red team exercises

• AIXCL fork for microsegmentation (decision pending)
• PCI DSS audit
• SOC 2 Type II certification
• Bug bounty program

Emergency: Call on-call via PagerDuty
Non-Emergency: Slack #security

This document acknowledges the following security debts that cannot be resolved without significant architectural changes:

1. Host Networking: AIXCL architectural invariant prevents container network isolation. Compensated by host-level firewall rules.

2. Privileged Containers: cAdvisor requires privileged mode for metrics. Compensated by disabling in production and using node-exporter.

3. Root User Requirements: Ollama/pgAdmin require root for initialization. Compensated by VM-level isolation for production.

Risk Acceptance: These debts are accepted for internal development and testing. Customer-facing deployments require VM-level isolation or AIXCL fork.

Review Date: 2026-08-01 (Quarterly)

• AIXCL Platform Invariants
• Security Runbook
• Incident Response Playbook
• Threat Model
• Compensating Controls

Document History

Next Review: 2026-08-01