A.C.E: Auditable AI Containment System Development

Auditable, layered AI containment for systems that must survive scrutiny. Built by Fratres X AI.

No unbreakable AI. No magic perimeter. A.C.E assumes breach and rigorously limits what can leave a workload in usable form — with reviewable evidence, honest maturity labels, and measurable catch rates.

Label Meaning Prototype Working end-to-end demos, CI-gated tests, real sandbox backends, red-team harness Not production-hardened TEE quote verification stubs, rule-based guardians (LLM-judge optional), process sandbox on nested hosts is isolation-limited

We separate research, prototype, and production boundaries on purpose. Claims stay conservative.

A composable containment stack you wrap around model and agent workloads:

Ingress — field encryption, IFC labels, tunnel policy

Boundary — pluggable sandbox runtime + instrumented execution

Egress — output guardians, rate limits, session kill

Audit — hash-chained tamper-evident logs + compliance export

Perfect blocking is impossible under neural compression and side channels. A.C.E inverts the problem: run the work, control the exit, prove what happened.

Loading

Path When to use HF Inference API Llama via HF_TOKEN + router — no GPU download Local HF weights Small ungated models on a GPU pod Integration guide Wire Ollama / vLLM / your handler

Layer Module Why it matters Field encryption crypto/encryption_fields Shrinks plaintext blast radius Weight obfuscation demo crypto/equivariant Linear similarity transform — not encryption Information flow control ifc/ BLP sensitivity + integrity via dominates() Agent label tracking ifc/agent_planner Propagates labels through tools and memory TEE abstraction execution/tee_* Attestation binding (adapters + stub verify) Instrumented runner execution/instrumented_runner No silent bypass of inference Output guardian guardians/output_guardian PII, entropy, stego, canaries Egress controller guardians/egress_controller Throttle / block / kill session Tamper-evident log audit/tamper_proof_log Hash-chained append-only trail Metrics + export audit/metrics, compliance_export Effectiveness score, submission packs Red-team harness redteam/simulator Self-auditing stress scenarios Sandbox runtime sandbox/ bubblewrap · Docker · process (gVisor/Firecracker registered, not yet functional) Tunnel gateway tunnel/ Policy-controlled ingress/egress

Registry-driven. Real isolation only — no fake in-process “sandbox.”

Platform Auto order Linux bubblewrap → docker → process (if allowed) Nested containers (e.g. RunPod) often process (separate OS process; not namespace isolation) Windows / macOS Windows Sandbox → Docker fallback

Policy: policy.yaml · env: ACE_SANDBOX_BACKEND

Callable workloads must be registered with @register_workload("name") before isolated execution.

A.C.E is built for review:

Red-team scenarios with reported catch rate

Hash-chained audit reconstructable after the fact

Compliance packs under artifacts/compliance_pack/

Documented trade-offs (security benefit vs cost)

Defense stays defensive. No offensive capability generation.

Nested cloud pods often cannot create Linux namespaces — use process or a bare-metal/VM host for bubblewrap

Docker Desktop on Windows/macOS works but is heavier than Linux-native runtimes

MCP adapter is a secure RPC pattern, not full MCP server-spec compliance

Weight-obfuscation demo and proof placeholders are not HE / ZK — do not treat as production crypto

TEE verification accepts simulated quotes only; hardware quotes fail closed until DCAP/KDS

Math interface reports SymPy parse success, not physical or formal verification

Guardian stack is primarily rule-based today; LLM-judge is on the roadmap

gVisor / Firecracker backends are stubs until guest workloads work

Doc Contents Architecture Layer model and design intent Sandbox + Tunnel Isolation and boundary gates Integration Ollama, RunPod, TEE notes RunPod quickstart Smoke, HF weights, Inference API Roadmap Phased extension plan Docs index Full index

Security policy — private vulnerability reports preferred

Copyright (C) 2026 Fratres X AI

Path Terms When to use Open source AGPL-3.0-or-later Audit, research, and use that complies with AGPL (including network source offer) Commercial Paid license from Fratres X AI Proprietary / closed-source products or SaaS where AGPL obligations are not acceptable

See LICENSING.md and COMMERCIAL_LICENSE.md. Commercial inquiries: fratres-x.com

A.C.E is part of the Fratres X AI lab — reviewable AI, autonomy, and defensive technology prototypes with physics-first modeling and honest maturity labels.

Site: fratres-x.com · Org: Fratres-X-AI