Engineering Transparency

    Technical Truth

    How Aegis Sovereign actually works — architecture and security documentation, the 8-phase AI safety platform, a tamper-evident audit chain across 7 frameworks, framework comparisons, and an AI concierge that answers straight from the docs.

    Automated Documentation

    Searchable, code-rich documentation with copy-paste ready configurations

    Platform Architecture — Governance-First Design

    Aegis Sovereign is a Kubernetes-native platform built around a single principle: every AI model action must be traceable, auditable, and reversible. The core services — Model Registry, Compliance Engine, LLM Gateway, Audit Chain, and Policy Engine — communicate via an internal event bus. Every write operation generates an immutable audit entry. The Helm chart deploys all services into a single namespace with NetworkPolicy isolation and mTLS enforced by Istio.

    bash
    Minimal production Helm install (AKS/EKS/GKE)
    # From the Aegis Sovereign release bundle
    cd aegis-sovereign/helm
    
    helm upgrade --install aegissovereign ./sovereign-gateway \
      --namespace aegissovereign --create-namespace \
      --set global.domain=sovereign.yourcompany.com \
      --set postgresql.auth.password="$(openssl rand -base64 32)" \
      --set redis.auth.password="$(openssl rand -base64 32)" \
      --set secrets.encryptionKey="$(openssl rand -hex 32)" \
      --set ingress.enabled=true \
      --set ingress.className=nginx \
      --wait --timeout 10m

    Compliance Evaluation Engine

    The Compliance Evaluation Engine maps each of the 7 supported regulatory frameworks to a scored checklist of controls. Evaluations are triggered automatically by the CompliancePipelineAgent on every model registration, or on-demand via API. Results are scored 0–100 per framework, and failing controls are tagged with remediation steps by the RemediationSuggestionAgent. Evaluation artifacts (PDF, JSON) are stored alongside the model version and linked in the audit chain.

    bash
    Trigger a compliance evaluation via REST
    # Evaluate a model against all active frameworks
    curl -X POST https://sovereign.yourcompany.com/api/v1/regulatory/evaluate \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "model_id": "mdl_fraud_v4",
        "frameworks": ["eu_ai_act", "sr_11_7", "nist_ai_rmf"],
        "workspace_id": "ws-prod"
      }'
    
    # Poll for result
    curl https://sovereign.yourcompany.com/api/v1/regulatory/evaluations/eval_xyz \
      -H "Authorization: Bearer $TOKEN"
    # → { "status": "completed", "scores": { "eu_ai_act": 91, "sr_11_7": 87, "nist_ai_rmf": 83 } }

    AI Safety Platform — 8-Phase Defence-in-Depth

    Beyond compliance scoring, every request, agent hand-off, and model promotion passes through an eight-phase safety pipeline: (1) a Safety Policy Engine — a fast regex pre-screen followed by an ML classifier ensemble (Llama Guard, ShieldGemma, Azure AI Content Safety, OpenAI Moderation); (2) an Agentic Safety Guard that validates tool calls before execution (blocking destructive arguments like `rm -rf /` or `DROP TABLE`); (3) PII masking via Microsoft Presidio; (4) a cross-turn conversation monitor; (5) a multi-agent trust boundary; (6) Safety SLOs; (7) a red-team certification runner; and (8) a ModelSafetyRegistry clearance gate that blocks promotion until safety checks pass. Safety is a pipeline stage wired into every path — not an afterthought.

    bash
    Run an LLM output safety evaluation (LLM-as-judge)
    curl -X POST "https://sovereign.yourcompany.com/api/v1/llm/output-evals?workspace_id=ws-prod" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "prompt": "Summarize this customer record",
        "response": "...model output...",
        "checks": ["hallucination", "toxicity", "factual_consistency"]
      }'
    # → { "status": "completed", "overall_score": 0.93, "passed": true }

    Cryptographic Audit Chain

    Every state-changing operation in the platform writes an AuditEntry row with: the event type, actor, resource, diff payload, timestamp, and a SHA-256 hash of the previous entry. This creates a per-workspace, append-only, hash-chained log — altering any row breaks verification from that row forward, so it is tamper-evident. To make it tamper-proof even against the platform operator, the current chain head is periodically anchored to an external append-only ledger (immudb, Azure Confidential Ledger, or a WORM file). A third-party auditor can then obtain the anchor independently and confirm the chain was not rewritten. Export the full chain as CSV for external SIEM, legal discovery, or regulatory submission.

    bash
    Verify audit chain integrity and export
    # Verify the chain from the latest entry back to genesis
    curl "https://sovereign.yourcompany.com/api/v1/audit/entries/verify?workspace_id=ws-prod" \
      -H "Authorization: Bearer $TOKEN"
    # → { "valid": true, "total": 62193, "head_hash": "a1b2..." }
    
    # Export full audit log to CSV for legal review
    curl "https://sovereign.yourcompany.com/api/v1/audit/export/csv?workspace_id=ws-prod" \
      -H "Authorization: Bearer $TOKEN" > audit-export-$(date +%Y%m%d).csv

    Live Kill Switch & Drift-Triggered Rollback

    The kill switch removes a model from all active traffic within 2 seconds. It works by updating the model's status to 'retired' in the registry and invalidating the routing cache in Redis — the LLM Gateway's next request cycle (every 500ms) picks up the change. For automated rollback: when a drift check produces critical severity (PSI ≥ 0.25), the platform reverts the model to its previous champion and fires the IncidentResponseAgent.

    bash
    Trigger kill switch on a production model
    # Pull a model from all traffic immediately
    curl -X POST https://sovereign.yourcompany.com/api/v1/models/mdl_fraud_v4/kill \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{ "reason": "Critical drift detected — PSI 0.31", "workspace_id": "ws-prod" }'
    
    # Revert to previous champion
    curl -X POST https://sovereign.yourcompany.com/api/v1/models/mdl_fraud_v4/revert \
      -H "Authorization: Bearer $TOKEN" \
      -d '{ "target_version": "mdl_fraud_v3" }'

    GitOps — Compliance-Linked Deployment Manifests

    Every model deployment is expressed as a versioned YAML manifest stored in your Git repository. The compliance_eval_id field is immutable — it chains the deployment record to the exact evaluation run that signed it off. OPA/Rego policy bundles are evaluated against each manifest on every merge to main. The GitOps operator watches the repo and applies manifests automatically after policy validation passes.

    yaml
    Auto-generated deployment manifest (stored in Git)
    apiVersion: aegissovereign.io/v1
    kind: ModelDeployment
    metadata:
      name: fraud-detection-v4
      namespace: production
    spec:
      model_id: mdl_fraud_v4
      version: "4.0.0"
      compliance_eval_id: eval_a1b2c3d4   # immutable — links to passing eval
      frameworks_passed:
        eu_ai_act: 91
        sr_11_7: 87
        nist_ai_rmf: 83
      bias_dir: 0.94
      robustness_score: 0.78
      approved_by:
        - role: legal
          user: sarah.chen@acme.com
          timestamp: "2026-04-18T14:22:00Z"

    Documentation reflects the current platform; the metrics shown are representative demo-sandbox figures, not a live customer feed. Last updated: 29/07/2026, 13:43:06