A runtime layer that sits between an AI agent and the world. Every action observed. Every action policy-checked. Every action logged.
aiegis is the harness for autonomous AI. Same architectural pattern that wraps Claude Code on a developer's laptop, applied universally to every AI agent that needs to act in the real world with a real audit trail.
An AI agent left to itself is unbounded. It runs whatever the model decides to run. The policies that constrain it live in a system prompt and a usage agreement — both of which depend on the model voluntarily complying.
A harness moves the boundary out of the model and into the runtime. The model intends; the harness decides whether the intent reaches the world. Every tool call, every API request, every outbound message is intercepted, evaluated, and either allowed, warned, blocked, or denied. The transcript is signed and persisted. The agent cannot lie about what it did because the harness recorded it independently.
This is how Anthropic's Claude Code keeps a developer's autonomous coding agent governable. aiegis is the same pattern, productised for any AI agent acting on behalf of any business or principal.
The aiegis stack is one harness expressed across four surfaces. Each surface enforces the same policy and writes to the same audit ledger.
POST /api/protect runs every requested action through the 15 enforcement layers (L1 Identity through L15 Correlation) and returns a signed decision with the layer that produced it and the latency budget consumed.The result: an agent action in any of the four surfaces is the same kind of evidence. A regulator asking "show me" gets one chain of signed decisions, not four separate compliance products to reconcile.
Architecturally the harness is four layers. Each layer is a separate technical primitive, evaluated and signed independently.
aiegis-harness reference daemon (in build); without it, agents can still POST directly to /api/protect but lose the local-attestation surface./api/protect./grid/ledger/retention). 5-year retention floor (EU AI Act Article 12).What's un-bypassable today: the hardware-bound Pin signature, the 15-layer Enforcement evaluation, the Ledger tamper-rejection triggers. What's still opt-in: routing through /api/protect at all. The roadmap closes that gap via the receiver-side network effect: signed action token or no service.
Most "AI governance" today is a paragraph in an acceptable-use document and a quarterly review. That model worked when AI was a curiosity. It breaks when AI is the actor — when the entity making the decision and taking the action is the one your policy was supposed to constrain.
The structural fix is the harness pattern. Move the policy from a document into the runtime. Make every action go through it. Sign every decision. Persist every transcript on an append-only ledger that even the operator cannot rewrite. The EU AI Act doesn't say "have a policy"; it says demonstrate a policy. The harness is what makes demonstration possible.
aiegis is built so that the answer to "show me your AI governance" is a curl command, not a Word document.
The harness is publicly verifiable on production. Any auditor, any customer, any researcher can run these three commands right now and see the harness behave.
No API key, no rate limit, no aiegis contact required. Public-key cryptography over publicly published artifacts. The whole point of the harness is that you can prove it from outside.
The aiegis Harness is the runtime layer that sits between an autonomous AI agent and the world. Every action the agent attempts — every tool call, every API request, every outbound message — is intercepted, evaluated against a 15-layer policy enforcement chain, and logged to an append-only audit ledger with a 5-year retention floor. The agent cannot reach the outside world except through the harness. The pattern is the same one Anthropic's Claude Code uses to wrap its own tool calls: observe, permission-check, log, allow or block.
Without a runtime wrapper, an AI agent's actions are unbounded. Policies live in prose (a system prompt or a usage policy) and depend on the model voluntarily following them. The harness pattern moves the boundary out of the model and into the runtime: the model can intend whatever it likes, but it can only act through the harness, and the harness enforces the policy whether the model cooperates or not. This is how Claude Code stays governable; aiegis is the same pattern applied to any AI agent.
The aiegis stack is a four-product harness. Identity issues the cryptographic passport that names the agent. Governance's /api/protect runs every action through 15 enforcement layers and returns a signed decision. Eye is the endpoint-side half — a sensor on every laptop that captures the agent's actions at the network layer. Grid is the marketplace where harness-pinned agents transact, with every interaction recorded on the same append-only ledger.
Bypass is the threat model the harness is designed against. Three structural protections prevent it: every action presents a verifiable Ed25519 passport at /api/protect — without a signed passport the call is rejected at L1-Identity. Every governance decision is appended to agent_logs and every Grid commerce event is appended to grid_ledger — both tables enforce append-only at the storage layer via SQL BEFORE DELETE / BEFORE UPDATE triggers that physically reject any rewrite (verified live at /grid/ledger/retention). The grid_ledger is additionally hash-chained (prev_hash + event_hash) so any tampering breaks the chain and is detectable by auditor-callable verification at /grid/ledger/verify/<seq>.
Guardrail libraries and prompt firewalls operate at the model boundary — they sit between user input and the model, or between model output and a downstream consumer. The aiegis Harness sits at the action boundary — between the agent and the world. A prompt firewall can stop a bad prompt; it cannot stop an agent that has already decided to send a transaction. The harness intercepts the transaction itself. The two patterns are complementary, not substitutes.
The harness is the mechanism by which an aiegis deployment satisfies EU AI Act Article 12 (audit retention, 5-year floor enforced in SQL) and Article 26 (deployer obligations, signed reason codes per sub-paragraph). The full per-sub-paragraph Article 26 mapping is at /article-26-walkthrough; the machine-readable version is at /audit/article26-mapping.json. Built in Ireland, deployed on customer infrastructure, EU sovereign.
The aiegis Harness evaluates every action through fifteen independent enforcement layers. Each layer is a separable check with its own reason code, its own latency budget, and its own fail-mode. A single POST /api/protect call returns the decision plus the layer that produced it, so an auditor can trace any block to the exact rule that fired.
Preventive layers (L1, L2, L4, L5, L8, L10, L11, L13) fail closed by design — if the layer cannot reach its decision input within budget, the request is denied. Detective layers (L7, L9, L12, L14, L15) fail open with a warning and a follow-up audit event so that the harness never silently degrades observability. The fail-mode of every layer is published in /api/protect response metadata under policy_meta.fail_mode.
The harness is reachable from any runtime. The reference paths are a Python SDK for application code, a Rust crate for performance-critical agents and sidecars, and a plain HTTP API for everything else. All three resolve to the same POST /api/protect contract and the same signed reason code envelope.
Python SDK (in development). The reference Python client is being prepared for release. Planned surface: an @harness.guard decorator and an async harness.protect(action, target, **ctx) coroutine, passport auto-attach from the local Identity keychain, retry-with-jitter on transient 5xx, decisions as typed Decision objects, and a HarnessBlocked exception carrying layer + reason + a deep link to the IT Violation Centre review. Until released, call the HTTP API at POST /api/protect directly. Request early access: [email protected].
Rust crate (in development). The reference Rust client targets the zero-allocation path for daemons, MCP servers, and embedded agents. Planned surface: a non-blocking Harness::protect on a Tokio runtime with a feature-flag for fail-closed-on-network-loss (preventive-layer default) versus fail-open-with-audit (detective-layer default). Until released, call the HTTP API directly. Request early access: [email protected].
HTTP API. Any language that can hold an Ed25519 key can call POST /api/protect directly. The contract is documented at /docs/harness/protect and is the same surface the SDKs wrap. Latency budget: p50 12 ms, p95 38 ms, p99 84 ms (measured on the public production endpoint, 30-day rolling window).
Daemon vs sidecar deployment. Two deployment shapes are designed and the reference implementations are in development. The daemon shape will run as a local Unix-socket-backed process; all agents on the host route through it, identity is keychain-bound, and the daemon batches policy decisions for offline forensics. The sidecar shape will run a per-pod or per-VM harness container alongside the agent; identity is workload-bound via SPIFFE/SVID and policy decisions fan-out to the central /api/protect. Both shapes target the same append-only ledger. Today the canonical surface is the HTTP API at POST /api/protect; client harness daemon/sidecar release is gated on the reference Python + Rust packages.
Observability hooks. The harness exports OpenTelemetry spans for every decision (aiegis.protect, aiegis.layer.<n>), Prometheus counters for decisions-by-layer-by-outcome, and a structured JSON audit stream tailable from /api/admin/audit/stream. Customers wire these into their existing SIEM (Splunk, Elastic, Datadog, Chronicle) without re-implementing the data model.
Enterprise SLA. Production SLA is 99.95 percent on /api/protect with a 100 ms p99 decision budget, EU-residency-pinned, with a credit schedule documented in the master subscription agreement. The harness is built so the SLA is measurable from outside — the same three curl commands above are the customer's continuous proof.
Almost every AI safety product on the market today inspects either the prompt going into the model or the text coming out of it. That is a useful boundary, but it is the wrong boundary for autonomous AI agent enforcement. An agent that has decided to send a wire transfer, exfiltrate a customer record, or call a destructive cloud API does not need to leak that intention in its output text. The intention becomes a function call. The function call is the action. The action is what reaches the world.
The aiegis Harness is built around that distinction. The model can say anything. The agent can plan anything. But the moment the plan becomes an action — an HTTP request, a tool invocation, a shell command, a database write, an outbound payment — the harness intercepts. The 15-layer enforcement chain runs on the action payload, not on the model output. L1 Identity verifies who is acting. L2 Authorisation verifies whether the named principal is permitted to act this way. L4 Scope verifies the action is inside the passport's purpose binding. L10 Egress verifies the destination is allow-listed. L11 Jurisdiction verifies the action against the rule pack for the applicable legal regime. None of those layers care what the model wrote on the way to deciding. They care about the action.
This is what AI agent enforcement looks like when it is engineered for autonomous systems rather than for chat assistants. The benchmark is no longer "can a prompt-injection make the bot say a forbidden word." The benchmark is "can the agent execute a forbidden transfer." The harness answers the second question. Prompt-level products answer the first, and the two questions are not the same.
The runtime AI governance posture this enables is auditable in a way paper policy cannot match. A regulator asking the EU AI Act Article 26 question — show me, for the last 30 days, every high-risk AI agent action and the policy decision attached to it — gets a curl response, not a Word document. The same posture answers an internal audit question, a SOC 2 question, an ISO 42001 question, and a customer security review. One ledger, many audiences.
The harness is engineered against a concrete threat model. The model assumes a capable adversary with partial control of the AI agent. The adversary may have succeeded with a prompt injection. The adversary may have compromised a third-party MCP tool. The adversary may be a malicious insider operating under a legitimate user session. The adversary may be a confused-deputy attack where the agent legitimately holds credentials and is tricked into acting against the principal's interest.
For each of these the harness has a specific defensive layer. Prompt injection is caught at L6 Input Sanitizer when it presents a known signature, and downstream at L4 Scope and L10 Egress when the injected action falls outside the purpose binding or the destination allow-list. Compromised MCP tools are caught at L8 Supply Chain and L13 MCP Registry, both of which verify the tool against a signed registry pin. Malicious insider activity surfaces at L12 Drift, which scores actions against the user's behavioural baseline, and at L15 Correlation, which detects slow-burn exfiltration across sessions. Confused-deputy attacks are caught at L4 Scope, which enforces the purpose binding declared at passport issuance, and at L14 Confidence Scoring, which gates low-confidence high-impact actions through the human-review queue.
No single layer is sufficient. The harness assumes that any one layer can be bypassed; the defensive value is in the depth of the chain. An adversary who defeats L6 still has to pass L4. An adversary who defeats L4 still has to pass L10. An adversary who silently defeats every preventive layer still leaves audit trace through the detective layers, and the trace is on an append-only ledger they cannot rewrite.
This depth is what enterprise procurement teams look for when they evaluate runtime AI governance. A single-layer product is a single point of failure. A 15-layer harness with independent fail-modes per layer is defence in depth applied to AI agent enforcement.
Procurement teams evaluating an AI agent harness should ask a small number of structural questions before any vendor demo. Is the policy enforced at the action boundary or only at the model boundary? Are the audit logs append-only at the storage layer, or merely append-only in the application code that can be patched away? Is the identity binding hardware-rooted? Is the evidence pack signed against a published public key, and can a third party verify the signature without a vendor portal account? Is the per-layer fail-mode documented and configurable, and does the default match the procurement-grade expectation that preventive layers fail closed?
The aiegis Harness is engineered so that each of these questions has a public, curl-checkable answer. The buyer does not need to trust marketing copy. The buyer does not need a sandbox account. The same three commands published on this page are the continuous proof: any auditor, any prospective customer, any researcher can confirm the harness behaviour from outside the aiegis organisation, today, without prior arrangement.
That posture is the point. Runtime AI governance only matters if it is verifiable, and verification only matters if it is open. The harness is the smallest unit of AI agent enforcement that can satisfy both conditions at the same time.