| Stack | Role | Year | Status |
|---|---|---|---|
| — | Systems / Infrastructure Engineer | 2026 | In Progress |
Aegis — Autonomous Infrastructure Guardrail System
Closing the trust gap in AI-driven infrastructure with Zero-Trust pull-based agents and OPA policies. Developed by Ancel Ajanga.
Aegis — Autonomous Infrastructure Guardrail System — Closing the trust gap in AI-driven infrastructure with Zero-Trust pull-based agents and OPA policies. Developed by Ancel Ajanga. is a technical case study on ancel.co.ke documenting architecture, trade-offs, and outcomes. To solve the trust and security dilemma of autonomous infra, I architected a system where the control plane is purely advisory and the execution plane is strictly pull-based, requiring every action to be policy-verified and cryptographically si…
Aegis is a production-hardened Autonomous Infrastructure Guardrail System engineered to bridge the gap between AI-driven remediation and system safety. Developed by Ancel Ajanga, the platform provides a Zero-Trust orchestration layer where AI suggests remediations but execution is strictly gated by human-defined Open Policy Agent (OPA) rules and cryptographic 'Signed Intent' validation. By utilizing a pull-based agent architecture, Aegis scales securely across heterogeneous cloud environments, providing high-availability infrastructure self-healing without compromising the security perimeter.
The Problem
The primary barrier to fully autonomous infrastructure is not the AI's ability to recommend a fix; it is the human inability to trust that fix at scale. Traditional 'Auto-Remediation' tools often operate in a 'Black Box'—triggering destructive actions with no audit trail or policy-gated control. 1. Security Risk: Traditional push-based systems require open ports into every cluster, creating a massive attack surface. 2. Failure Volatility: Misconfigured AI agents can trigger 'Feedback Loops,' where a fix creates a new outage. 3. Compliance Gap: In regulated environments, every infra change must be policy-verified and traceable to a signed intent. Aegis was conceived to solve these three critical 'Trust Vectors' by removing direct AI-to-Execute paths and replacing them with a policy-gated, pull-based verification engine.
To solve the trust and security dilemma of autonomous infra, I architected a system where the control plane is purely advisory and the execution plane is strictly pull-based, requiring every action to be policy-verified and cryptographically signed before it touches a production node.
The Solution
Aegis implements a 'Policy-Gated Pull' architecture. Instead of the core server pushing updates (unsafe), local 'Aegis Agents' in each cluster pull signed task intents from an encrypted outbox. Every task payload is wrapped in a JWS (JSON Web Signature) with a 5-second replay window. Before an agent executes a 'Restart Pod' or 'Modify Replica' action, it validates the intent against a local OPA (Open Policy Agent) sidecar. If the action violates a FinOps budget or a safety guardrail (e.g., 'Never restart more than 20% of a cluster'), the agent fails closed. This creates a 'Guardrail Loop' where AI handles the complexity of root-cause analysis, but the human-defined policy handles the risk of execution. The system features a 'Shadow Mode' for safe rollout, where actions are logged but not performed, allowing engineers to verify AI decisions before going live with 'AUTONOMOUS' mode.
Key Technical Terms
- Pull-Based Execution:A security model where agents inside a protected network initiate outbound requests for work. This eliminates the need for inbound firewall rules and ensures that clusters remain isolated from a compromised control plane.
- Signed Intent (JWS/HMAC):Every administrative action is cryptographically signed by the Aegis control plane. Agents verify the signature and timestamp to prevent 'Man-in-the-Middle' attacks and replayed administrative commands.
- FinOps Guardrails:Resource-based policies enforced via OPA that prevent AI from accidentally scaling infrastructure beyond budget limits or resource availability during a remediation event.
The Impact
< 5s
Zero-Trust
< 200ms
10k+ Agents
Architecture Deep-Dive
The Aegis architecture follows a strictly decoupled, Zero-Trust pattern: 1. Control Plane (NestJS/Python): The control plane aggregates observability data via OpenTelemetry and runs ML-driven anomaly detection (using Prophet for forecasting). It generates 'Remediation Intents' but lacks the credentials to execute them directly. It stores tasks in an 'Encrypted Intent Buffer' (PostgreSQL + Redis). 2. Security Layer (OPA/JWS): Every intent is signed with an HMAC or RSA-4096 key. The local OPA sidecar provides the decision-ready 'Engine' that evaluates task safety against live cluster metrics (e.g., 'Is CPU > 80%? If yes, deny restart'). 3. Execution Plane (Go Agents): Lightweight agents deployed as DaemonSets in Kubernetes clusters. They pull tasks via an authenticated endpoint (GET /tasks?cluster_id=X). This 'External-In' isolation ensures that the control plane cannot 'hack' the cluster; it can only 'propose' work that the agent chooses to accept. 4. Observability Mesh (Otel/Loki): Aegis uses 'Blinded Observability.' Logs are encrypted at the agent level using HKDF-derived keys, ensuring that sensitive infrastructure data in Loki is only accessible to authorized engineers, even if the logging backend is compromised.
Key Engineering Decisions
Designing Aegis required choosing safety over speed in several critical areas: - Pull-Based Latency vs. Push-Based Speed: A push-based system reacts in <10ms. A pull-based system has a polling latency of 1-5 seconds. I chose pull-based because the security benefits of closed inbound ports far outweigh the requirement for sub-second remediation in 99% of infra scenarios. - OPA vs. Hardcoded Logic: Hardcoding safety rules in the agent would be faster to develop. I chose OPA for its 'Declarative' nature, allowing teams to update guardrails instantly via GitOps without redeploying the execution agents. - Shadow Mode Complexity: Implementing a parallel 'Log-Only' path for every action doubled the state complexity. However, it was essential for 'Operator Trust'—without a way to see what the AI *would* have done, no SRE would ever turn the system to 'AUTONOMOUS' mode.
Performance & Scalability
Aegis is engineered to scale across thousands of clusters. The 'Pull' mechanism is inherently horizontally scalable. By leveraging Redis for task distribution, a single Aegis control plane can support 10k+ agents polling at 5s intervals with sub-200ms API response times. We utilize 'Adaptive Polling' to reduce load: agents poll slower when the cluster is healthy and accelerate to 1s intervals when an anomaly is detected. The control plane is stateless, allowing for effortless N+1 scaling behind a standard load balancer. Our benchmarks show the system can handle 50,000 active remediation intents in the buffer without slowing down the task-pull endpoints.
Failure Modes & Resilience
Resilience in Aegis is focused on 'Failing Closed' to prevent cascaded infra destruction: 1. Control Plane Outage: If the server goes down, agents simply continue their last known 'Safety Protocol.' No new remediation actions are taken, preserving the current state of the infra until humans intervene. 2. Agent-Side TTL Exhaustion: Every task includes a 'Valid-Until' timestamp. If an agent pulls a task but experiences a network partition before execution, it checks the TTL. If the task is >5s old, it is discarded to prevent 'Stale State' remediation. 3. OPA Sidecar Failure: If the local policy engine cannot be reached, the Aegis Agent enters a 'Hard Lock' state where all tasks are denied by default. We prioritize safety over availability of the self-healing feature. 4. AI Hallucination Protection: We implement 'Confidence Gating.' If the ML model's confidence in a remediation fix is <85%, Aegis automatically switches the task from 'AUTONOMOUS' to 'PROPOSED,' requiring a human click on the Next.js 15 dashboard to proceed.
Security & Trust Boundaries
Aegis is built on a Zero-Trust mandate. Security is the core value proposition. - JWS Intent Validation: We use JSON Web Signatures to ensure that only the verified control plane can issue commands. Agents rotate their public keys through a secure handshake every 24 hours. - Blinded Observability: Utilizing the HKDF (HMAC-based Key Derivation Function), we mask pod names, IP addresses, and custom labels in the logs before they leave the cluster. Only the 'Security Officer' role in the Aegis UI can de-mask the data. - Default-Deny Policies: In line with Staff-level engineering standards, our OPA policies are 'Default-Deny.' Unless a specific remediation action is explicitly whitelisted for a cluster ID, it is blocked, preventing the AI from 'inventing' new infrastructure patterns.
Frontend Engineering & UX
The Aegis dashboard (Next.js 15) is a high-performance command center for infrastructure state. - Real-Time Topology Explorer: Built with React Flow, the topology view provides a live, interactive map of cluster health. We use Server Components (RSC) to stream the initial dashboard state, reducing Time-to-Interactive (TTI) by 30%. - Remediation Timeline: SREs can view a 'Play-by-Play' breakdown of AI reasoning. Each recommendation links back to the Prometheus metrics that triggered it, providing a 'Full-Chain' audit trail from alert to action. - Optimistic UI with Rollback: When a human approves an action, the UI pessimistically shows the 'Applying' state. If the agent returns a 'Policy Violation' error, the UI rolls back instantly with a detailed explanation of why the guardrail blocked the action.
Outcome & Future Potential
< 5s
End-to-end time from anomaly detection to pull-based execution
Zero-Trust
Pull-based agents with JWS signature validation
< 200ms
Local OPA policy evaluation time before task execution
10k+ Agents
Architected for massive multi-cluster coordination
Key Engineering Takeaways
Trust is not given; it is verified cryptographically (Signed Intents).
Infrastructure safety requires 'Default-Deny' policy engines (OPA).
Pull-based architectures are the only way to scale securely across VPC boundaries.
Blinded observability preserves privacy without sacrificing operational visibility.
Autonomous systems must fail closed; doing nothing is better than doing the wrong thing.
Project Gallery