AIEGIS Governance

AIEGIS Governance evaluates every agent action against the applicable jurisdictional rule pack at runtime. The decision arrives before the action does. The audit trail is signed, immutable, and yours.

The problem

Most "AI governance" is a quarterly audit, a binder, a checkbox. Agents don't ask permission — they act. By the time the audit catches the violation, the contract is signed and the data is gone.

AIEGIS Governance evaluates every agent action against the applicable jurisdictional rule pack at runtime. The decision arrives before the action does. The audit trail is signed, immutable, and yours.

Frameworks · Runtime · Audit

• Frameworks (coverage proof). Six rule packs, article-by-article. EU AI Act (Art. 50 enforces 2026-08-02), GDPR, NIST AI RMF, MGAIF, POPIA, plus the AgenticOS Five-Pillar universal baseline. What your regulator wants to see.
• Runtime (enforcement proof). /api/protect flow, 15 enforced layers × 5 packs, real reason codes (EU_AI_ACT_*, GDPR_*, NIST_RMF_*, SG_MGAIF_*, ZA_POPIA_*). What stops bad agent behaviour.
• Audit Trail (auditor handoff). Ed25519-signed receipts, customer-cloud invariant (signed receipts only return), retention, SIEM export. What your SOC2/GDPR/Article 26 auditor walks away with.

Five frameworks, one engine

Pack versions evolve continuously — current pack metadata is published live at /registry/governance/versions.

• EU AI Act. Articles 9, 10, 11, 12, 13, 14, 15, 50, 72. Article 50 enforces 2026-08-02. Penalties up to 7% global revenue.
• GDPR. Lawful basis, data minimisation, automated decision rights, transparency, DPIA hooks.
• NIST AI RMF. Govern, Map, Measure, Manage. Risk classification, behavioural baselining, anomaly response.
• Singapore MGAIF. Multi-jurisdiction agent governance: Singapore IMDA, jurisdictional extensions, cross-border data flow.
• South Africa POPIA. Lawful processing, special personal information, cross-border transfer.
• AgenticOS Universal Pillars. Cross-jurisdiction baseline: accountability, transparency, risk classification, audit trail, intervention capability. Composes with every jurisdictional pack above.

Rule pack roster

EU AI Act. Articles 9, 10, 11, 12, 13, 14, 15, 26, 50, and 72 are enforced as structured rule packs with article-level reason codes (EU_AI_ACT_ART9_* through EU_AI_ACT_ART72_*). The biometric §9 layer is treated as a high-risk category with the December 2 2027 deadline locked into the pack metadata. Article 50 transparency obligations enforce from 2026-08-02. Penalties reach 7% of global revenue for the most serious infringements.

GDPR. Lawful basis verification, data minimisation, automated decision rights (Article 22), transparency, and DPIA hooks. Special-category data triggers explicit-basis checks at layer 8. Cross-border transfer to non-adequacy countries triggers the network-layer guards.

NIST AI RMF. Govern, Map, Measure, Manage — the four functions of the NIST AI Risk Management Framework — surface as reason-code prefixes (NIST_RMF_GOV_*, NIST_RMF_MAP_*, etc.). Risk classification feeds the confidence-scoring layer. Behavioural baselining sits at layer 10.

Singapore MGAIF. The Multi-Agent Governance AI Framework covers cross-border agent commerce. The pack carries jurisdictional extensions for Singapore IMDA, with explicit cross-border data-flow rules used by layer 9 (network). Reason-code prefix is SG_MGAIF_*.

South Africa POPIA. Protection of Personal Information Act. Lawful processing, special personal information, cross-border transfer. Reason-code prefix ZA_POPIA_*.

Pack versions evolve continuously. The live registry at /registry/governance/versions publishes current pack metadata and hashes.

NIST + W3C agent-identity direction

AIEGIS Identity (Ed25519 cryptographic passport with operator-key trust-root + v1.8 governance-payload signature enforcement) is being built compatibly with the canonical agent-identity standards emerging in 2026.

• NIST AI Agent Standards Initiative. Announced Feb 2026. Concept paper on agent identity + authorization. AIEGIS tracks this direction; alignment statement v0.1.
• W3C DID + VC. Decentralized Identifiers + Verifiable Credentials. did:web:aiegis.ie method spec + VC 2.0 envelope export for shipped passports.

15 layers, one API

15-layer defense-in-depth. Identity, compliance, agent police, model gate, input sanitiser, memory integrity, tool sandbox, data protection, network, behavioural intelligence, confidence scoring, correlation engine, output filter, audit signer, retention writer.

Single REST API. /api/protect evaluates, decides, and signs. Designed for real-time verification on customer infrastructure. Self-hosted. No data leaves your perimeter.

Cryptographically-signed audit trail. Every decision Ed25519-signed and stored on your infrastructure. Article 26 evidence-ready.

Defense-in-depth, layer by layer

Every /api/protect evaluation walks the layers in order. Each layer can allow, deny, or annotate the decision. A deny at any layer is final under the default fail-closed semantics for preventive layers. The fifteen layers are grouped into four bands: identity, policy, content, and behaviour.

Fail-closed vs fail-open

Fail-mode is a procurement disqualifier when wrong. AIEGIS Governance distinguishes preventive layers (those that block actions before they happen) from detective layers (those that detect anomalies after the fact) and applies different fail-modes accordingly.

Preventive layers fail closed. Identity verification, compliance gating, tool sandbox, data protection — if the layer cannot reach a positive decision, the action is denied. Closed is the only safe default for a layer whose job is to prevent harm. This is the default expected by EU AI Act high-risk obligations and by CISO procurement reviews.

Detective layers fail open. Behavioural intelligence and correlation engine — if the layer cannot reach a positive signal, the action proceeds but the absence is logged. A detective layer that fails closed would cause cascading outages on every state-store issue without preventing any concrete harm.

The fail-mode for each layer is part of the published rule pack and can be inspected at /registry/governance/versions. Operators can tighten a detective layer to fail-closed in their local deployment, but cannot loosen a preventive layer to fail-open without explicit override and audit-logged justification.

Latency budget

Agents act in milliseconds. A governance layer that takes minutes to decide is a layer the agent will route around. AIEGIS Governance is designed for real-time inline evaluation on customer infrastructure — the /api/protect endpoint runs the full 15-layer stack and returns a signed decision on the synchronous request.

The target latency budget for the full 15-layer evaluation is in the low milliseconds for the common case. Latency-class layers (identity, compliance, sanitiser, tool sandbox) sit on the synchronous path. Heavier analytical layers (behavioural intelligence, correlation engine) run on a deferred-update path where the layer's effect on the current decision uses cached state and the heavy compute updates the state asynchronously.

Self-hosted deployment is the default. The endpoint runs on the operator's infrastructure, the rule packs ship as signed pack bundles, and no data leaves the operator's perimeter. This is the property regulators expect for high-risk AI under EU AI Act Article 26 — the audit trail is on the deployer's infrastructure, not on a third-party SaaS that adds another data-controller relationship.

Ed25519 receipts

Every decision produces a signed receipt. The receipt is Ed25519-signed by the deployment's audit key, names the agent passport that triggered the evaluation, lists the 15 layer decisions with their reason codes, references the policy bundle hash that governed the evaluation, and timestamps the decision.

{
  "type":            "AiegisProtectReceipt",
  "agent_passport":  "did:agent:aiegis:my-fleet:scribe-001",
  "action":          "post_message",
  "decision":        "ALLOW",
  "layer_decisions": [
    { "layer": "01_identity",   "verdict": "PASS" },
    { "layer": "02_compliance", "verdict": "PASS", "pack": "eu-ai-act-26" },
    ...
  ],
  "pack_bundle_hash": "sha256:...",
  "ts":               "2026-06-09T...",
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-jcs-2022", ... }
}

Customer-cloud invariant

The customer-cloud invariant is that signed receipts only return — they never leave the deployer's infrastructure except as a signed export the deployer chooses to share. AIEGIS does not aggregate customer audit data centrally. The audit store sits on the operator's infrastructure with retention configured for the EU AI Act Article 12 five-year window.

SIEM export is supported through standard transport (syslog, Kafka, S3-compatible object writes) with the same signed-receipt format. Receipts that go to a SIEM remain verifiable — the signature travels with the receipt.

Auditor handoff

The auditor-ready export is a signed audit pack — a tarball of receipts for a specified time range, accompanied by the pack bundles in force during that window, the operator key fingerprints, and the revocation list snapshots. A SOC 2 auditor, an EU AI Act Article 26 auditor, or a GDPR DPIA auditor can verify the bundle independently using only the public operator key.

Reason codes — EU_AI_ACT_*

Article-prefixed. Each EU AI Act article enforced by AIEGIS Governance maps to a reason-code family.

• EU_AI_ACT_ART9_* — biometric and special-category high-risk gates (December 2 2027 deadline locked in pack metadata).
• EU_AI_ACT_ART10_* — data and data governance.
• EU_AI_ACT_ART11_* — technical documentation requirements.
• EU_AI_ACT_ART12_* — record-keeping (5-year retention floor).
• EU_AI_ACT_ART13_* — transparency obligations to deployer.
• EU_AI_ACT_ART14_* — human oversight.
• EU_AI_ACT_ART15_* — accuracy, robustness, cybersecurity.
• EU_AI_ACT_ART26_* — deployer obligations (2026-08-02).
• EU_AI_ACT_ART50_* — transparency to natural persons (2026-08-02).
• EU_AI_ACT_ART72_* — post-market monitoring.

Reason codes — GDPR_*

• GDPR_ART6_* — lawful basis verification.
• GDPR_ART9_* — special-category data explicit basis.
• GDPR_ART22_* — automated decision rights.
• GDPR_ART32_* — security of processing.
• GDPR_ART44_* — international transfers.

Reason codes — NIST_RMF_*

Aligned to the four NIST AI RMF functions:

• NIST_RMF_GOV_* — Govern.
• NIST_RMF_MAP_* — Map.
• NIST_RMF_MEAS_* — Measure.
• NIST_RMF_MANAGE_* — Manage.

Reason codes — SG_MGAIF_*

Singapore IMDA Multi-Agent Governance AI Framework. Cross-border data-flow guards triggered at layer 9 (network).

Reason codes — ZA_POPIA_*

South Africa Protection of Personal Information Act. Special personal information + cross-border transfer guards.

Frequently asked questions

What is AI governance? AI governance is the set of policies, controls, and audit mechanisms that keep autonomous AI systems within legal, ethical, and operational boundaries. AIEGIS Governance enforces governance at runtime — every agent action is evaluated against the applicable rule pack before it takes effect.

What is runtime AI governance? Runtime AI governance evaluates agent actions inline, at the moment they are about to happen, rather than reviewing them in a quarterly audit after the fact. The decision arrives before the action does, and the audit trail is produced as a side-effect of enforcement.

How does AIEGIS Governance enforce the EU AI Act? Through structured rule packs covering Articles 9, 10, 11, 12, 13, 14, 15, 26, 50, and 72. Each article maps to specific reason codes (EU_AI_ACT_ART9_* through EU_AI_ACT_ART72_*) returned in the decision receipt. Article 50 transparency enforces from 2026-08-02.

Which jurisdictions are covered? EU (AI Act and GDPR), United States (NIST AI RMF), Singapore (MGAIF), South Africa (POPIA), and the AgenticOS universal pillars that compose with any jurisdictional pack.

What is the 15-layer stack? A defense-in-depth model in which every agent action is evaluated by 15 ordered layers covering identity, compliance, agent behaviour, model invocation, input sanitisation, memory integrity, tool sandboxing, data protection, network egress, behavioural intelligence, confidence scoring, correlation, output filtering, audit signing, and retention.

Where does the audit trail live? On the operator's own infrastructure. AIEGIS Governance does not aggregate customer audit data centrally. The retention window defaults to the EU AI Act Article 12 five-year requirement and is configurable upward.

Is the audit trail tamper-evident? Yes. Every receipt is Ed25519-signed by the deployment's audit key. The receipts hash-chain through their predecessor reference, so any post-hoc modification breaks the chain and is detectable on verification.

What is the default fail-mode? Preventive layers fail closed; detective layers fail open. The fail-mode for each layer is published in the rule pack and inspectable at /registry/governance/versions.

What is a rule pack? A signed bundle of policy logic implementing the requirements of one jurisdictional framework. AIEGIS ships rule packs for EU AI Act, GDPR, NIST AI RMF, MGAIF, and POPIA, plus the universal AgenticOS pillars.

How do I prove compliance to my auditor? Export a signed audit pack covering the audit window. The auditor verifies the bundle independently using the public operator key, walks the receipts for the period, and confirms that every agent action carries a layer-by-layer decision trail.

Does AIEGIS Governance run in the cloud or on-premises? On-premises by default — the endpoint runs on the operator's infrastructure under a self-hosted licence. SaaS options exist for evaluation, but production deployments are typically operator-hosted to keep the audit trail inside the operator's perimeter.

Does the governance engine support custom rule packs? Yes. Operators can author custom packs alongside the shipped jurisdictional packs. Custom packs sit on the same enforcement stack and produce the same signed receipts.