Astartis x Codex

Inspiration

I'm inspired by enterprise-grade software. Working part-time in IT internships while at university, I've seen how efficient and fault-tolerant enterprise networking and cybersecurity systems can be. But these systems are only affordable for large enterprises and government ministries in Botswana — small companies and solo developers can't afford things like Essl access-level door lock systems or Dell's write-once-read-many (WORM) server architecture, which gives absolute immutability. So I built a hyper-scalable system and used Codex/GPT-5.6 to debug its C++-heavy errors. It can run on a server or your own laptop by changing configs via my GitHub repo — making it cheap and reliable for regions like Botswana, where cloud hosting is expensive and infrastructure can be unreliable.

Compliance & Regulatory Alignment

Astartis's architecture was built with real-world compliance obligations in mind, particularly for government and enterprise deployments in Botswana. Note: these are architectural alignments, not formal certifications — no third-party audit has verified compliance against any of the below.

Zero Trust Architecture (NIST SP 800-207) — zerotrust_engine and the 8-step nac_workflow implement per-device trust scoring and cross-zone deny-by-default access, core NIST 800-207 patterns. NIST Cybersecurity Framework — the module set maps directly to all five CSF functions: Identify (attribution, threat_level), Protect (firewall, access_token, crypto_identity), Detect (packet_sensor, chaos_detector, rule_engine), Respond (action_dispatcher, active_response), Recover (worm_lock, version_store, veeam_interface). Botswana Data Protection Act (2018) — the HMAC-signed, scoped, TTL-bound access token system and immutable audit chain support the Act's accountability and access-control obligations. Ransomware-resilience guidance (e.g. CISA) — the WORM lock (write-once-read-many, 12-eye multi-party unlock) and Veeam backup-locking integration reflect current guidance on immutable backup protection. SOC 2 / ISO 27001 Annex A (logging & monitoring) — the SHA-256 hash-chained audit log provides tamper-evident event history consistent with these frameworks' audit-trail control objectives.

What it does

Astartis is the deterministic security engine behind this project. It combines:

-a rule engine and using advanced mathematical entropy/chaos analysis for local threat signals; -WORM-style protected evidence and a hash-linked audit chain; -NAC admission and Zero Trust access evaluation; -recovery, decoy, sandbox, attribution, and rule evidence surfaces; -opt-in local Npcap metadata capture when the driver is installed; -a safe, allowlisted diagnostic terminal; and -a routed catalogue of 77 security-agent definitions. The 77 agents are not 77 large models running concurrently on a laptop. They are 65 JSON personas and 12 ECC agent definitions used as a routed catalogue. This makes the project practical on ordinary hardware while retaining a meaningful way to organise security roles, health, and routing evidence.

What Astartis x Codex adds The dashboard shows what Astartis sees. The Codex integration makes selected evidence usable in the development workflow.

Through the local astartis-control-plane plugin, Codex gets seven intentionally narrow MCP tools. It can read posture, inspect network zones, simulate NAC admission, evaluate a Zero Trust request, inspect agent health, retrieve attribution evidence, and run Proof Mode.

It cannot silently change a production firewall, quarantine files, unlock WORM-protected evidence, change an identity provider, operate a switch or VLAN, or run arbitrary agents. Those limits are a design feature: Codex is the investigation, explanation, remediation, and verification surface; Astartis remains the deterministic policy authority.

How we built it

I set the product direction and the boundaries: preserve the existing Astartis engineering, keep enforcement deterministic, make packet capture opt-in, be honest about simulation versus live activity, and make the Codex integration useful to a developer.

I used Codex with GPT-5.6 to audit and brutally debug the C++/Phoenix/Node boundaries, build and test the local MCP control plane, reconcile NAC and Zero Trust bridge payloads, add safe diagnostic-terminal controls, strengthen runtime evidence presentation, improve the Astartis x Codex experience, and validate the dashboard and plugin tests. I made the product, engineering, and security-boundary decisions; Codex accelerated the implementation and verification work. DISCLAIMER -Permissions are opt-in by design. Every destructive capability — absolute immutability, packet sniffing, native firewall control, file quarantine — is disabled by default and gated behind explicit repo-level configuration changes that only the user can make. Codex and the agent catalogue operate strictly within the 7 read/simulate MCP tools until a user deliberately opts in via our interactive demo lab on Vercel. Nothing destructive happens by default or by accident.

Challenges we ran into

Debugging this behemoth of a code , and also we were trying to make sure that astartis X codex can be reconfigured to use real data on the network cybersecurity testing like windows based network adapters like Qualcomm adapters and web stream socket APIs

Accomplishments that we're proud of

Getting this project finally working and being able to integrate properly through Local Codex plugin then Node MCP adapter.

What we learned

I've learned how to efficiently vibe-code and debug advanced systems with Codex/GPT-5.6, and I've also learned about MCP servers.

What's next for Astartis x Codex

My goal is to improve the user experience, reduce the low-latency C++ architecture's overhead with Codex/GPT-5.6 (funding permitting), expand real-world use cases, and convert more of the current simulated features into live, production-grade functionality.

Built With

• 5.6
• and
• codex
• gpt
• luna
• terra