Invariant is an independent kernel between AI agents and the systems they act on. It checks every action against your rules before it runs, and signs a record of every decision that anyone can verify.
Verified Action Certificate
Example record, demo key
Refund €5,000.00
POST api.stripe.com/v1/refunds
No allow rule matched, so the default rule applied. The call was never made.
An agent can misread an instruction, follow text injected into its context, or call the right tool with the wrong amount.
Observability tools record what an agent did after it happened. Guardrail tools mostly filter what a model says, not what it does.
A buggy or compromised agent can skip its own checks.
When something goes wrong, it is unclear who is responsible: the model provider, the company that deployed the agent, or the system that executed the action.
A customer asks for a €50 refund. The agent issues €5,000.
Today
The refund goes through. The log explains it afterwards.
With Invariant
A rule capping refunds stops the call before it reaches the payment provider. A signed record shows which rule stopped it.
Capture the action and translate it into one standard record, whatever service or protocol it was meant for.
Check it against your rules. If it breaks one, the call is never made, so nothing happens in the world.
Record the decision and sign it, so anyone can later check what was attempted, what was checked, and what happened.
Path of the call
Agent
agent_billing calls POST /stripe/v1/refunds with amount=500000
Intercept
Waiting for the call
Validate
Rules not evaluated yet
api.stripe.com
Reachable only through Invariant
Certify
No decision to sign yet
Agent receives
Nothing yet
# Pick an amount and a mode, or press Run action.
# The default is the €5,000 mistake in enforce mode.
A certificate appears here once the action is decided.
Decision log
Example rows from this demo
mode: enforce default: block # when no rule allowsrules: - name: allow-small-refunds when: route: stripe intent: create_refund amount_lte: 10000 then: allow - name: allow-slack-posts when: route: slack intent: send_message then: allow
Amounts are in minor units, so 10000 is €100.00. The policy format is still being finalized.
Start in observe mode, which only records. Shadow mode evaluates the rules and records what would have been blocked. Enforcement starts when you choose.
In enforce mode, an action that no rule allows is blocked by default.
Every decision names the rule that caused it and the policy version in force. Rules decide. Any risk score is informational, because a rule can be audited and a weighted score is hard to defend.
An operator can halt one agent's traffic, or all traffic, on command.
Parameters bound for external services can be scanned for personal data, using self-hosted open-source detection.
Change the base URL the agent's SDK uses for a service to Invariant's route for that service, and add a key that identifies the agent. The agent's own credentials for the service pass through unchanged.
This works with most agent frameworks, because most SDKs let you set a base URL. It needs no forged certificates, and no changes to the agent's code beyond configuration.
POST http://invariant:8080/stripe/v1/refunds
charge=ch_123&amount=500000
The order is the core of the design: capture, decide, forward. Until the forwarding call is made, nothing has happened in the world. Blocking an action simply means never making that call. A check that runs after forwarding can only report damage.
On the allow path, the agent receives exactly what the service sent: same status, same headers, same body. If the service cannot be reached, Invariant reports an honest error and never fakes a success.
Every action, whatever protocol it arrived on, becomes one standard Action Object before anything else happens. That is what lets you write a rule once and have it apply across every service your agents use.
Each field has a known source, and the record keeps them apart. Inferred fields are marked, because they can be wrong. If no mapping exists, the intent is recorded as unknown rather than guessed. Anything the agent claims about itself is recorded as a claim, never as fact.
Hashes are SHA-256 over the exact bytes received, and over the RFC 8785 canonical JSON form for structured fields, so anyone can reproduce them. MCP tool calls over the network take the same path: the tool name becomes the intent and the tool arguments become the parameters.
Read from the request, computed by Invariant, or inferred from configuration.
The Verified Action Certificate (VAC) is meant to work for AI actions the way a certificate works for a website. A recorded block matters to an auditor as much as a recorded approval, because it is the evidence that a control worked.
Each certificate is designed to prove four things:
Records are kept in an append-only log structured as a hash tree, in the style Certificate Transparency uses for web certificates (RFC 9162). That allows two proofs: that a given record is in the log, and that the log's history was never rewritten between two points in time. Signatures cover the whole record, so no field can be edited without detection.
We plan to publish the VAC format as an open, versioned specification with test vectors, so any tool can produce or check records.
Checking the example record from Fig. 1.
# The verifier runs when this figure is on screen.
Check the Fig. 1 example with your own tools: the certificate, the Action Object and the demo public key. The action hash is SHA-256 over the RFC 8785 canonical form of the Action Object. The signature is Ed25519 over the canonical form of the certificate without its signature field.
A standalone verifier, separate from the kernel, takes a record, a public key and a signed snapshot of the log, and answers valid or invalid. It is what an auditor runs.
Who holds the signing key decides what a certificate proves to an outsider. It is the most important trust decision in the product, and we will settle it, and document it, before certification ships.
Every agent's credentials for upstream services pass through Invariant, which makes the kernel a valuable target in its own right. Fixed in the design:
Direct route from agent to service: closed by network egress rules
A full threat model will be published as a standalone document before the first pilot.
Agent records can contain personal data taken from action parameters. Retention will be configurable per customer. Payloads are stored apart from the hashes the log chains together, so a payload can be deleted on request without breaking verification of the log.
In 2023 an AI mistake was usually a wrong sentence. Now it can be a wrong transfer. Standard tool protocols such as the Model Context Protocol make it cheap to give an agent many tools at once, so the number of actions each agent can take keeps growing.
The EU AI Act's Digital Omnibus delayed the obligations for high-risk AI systems. It did not shrink the requirements. They include automatic logging of events (Article 12) and a duty on deployers to keep automatically generated logs for at least six months (Article 26).
We are mapping which obligations Invariant's records support, and make no compliance claims until legal counsel has reviewed that mapping. Sources: Orrick, Freshfields.
Without a verifiable record of what an agent did and what was checked, an insurer has little to price agent risk on. A signed record per action is a candidate basis for that. It is a hypothesis we intend to test with insurers, not a result.
The person who feels the pain is the same in both: the engineer who has to approve letting an agent touch production. Today that person either blocks the project or accepts a risk they cannot measure.
We are looking for design partners for the first pilots: teams putting agents onto systems they care about, who need a control they can show to their customers, auditors or regulators.