Prove your AI agents
are under control.

AI agent governance is the practice of controlling what an AI agent is allowed to do at runtime, evaluating what it actually did, and producing a record that proves both. In practice that means four things working together: policies declaring which tools and actions an agent may use, guardrails enforcing them inline before a response reaches a user, evaluators scoring each interaction for failures like PII leakage or hallucination, and an audit trail an independent party can verify. Observability tools cover the third; governance requires all four.

Governance and assurance are not the same thing. Governance is the regime — the policies, the committees, who decides what an agent may do. Assurance is the evidence that the regime actually held: the testing, the verification and the record an independent party can check. In the three-lines model, governance is written in the first line and assurance is what the second and third lines — model validation and internal audit — are accountable for. Sengol is built for the assurance side: governance says what should happen, assurance proves what did.

Yes. OSFI Guideline E-23 on model risk management takes effect 1 May 2027 for federally regulated financial institutions in Canada, and extends to AI and machine-learning models. Sengol compiles E-23 into obligations, routes each one to the evaluators that satisfy it, and binds every signed record to the specific control that produced it — so coverage per agent and per period is a query, not a spreadsheet exercise. The same mechanism covers SR 11-7, the EU AI Act, FINTRAC, HIPAA and 24 other frameworks, and your own internal model-risk standard is one YAML entry.

An observability tool tells you what happened. Sengol decides what is allowed to happen, and produces evidence of the decision. It blocks a CRITICAL failure inline before the user sees it, blocks a failing deploy before it merges, and writes each verdict as a cryptographically signed record, runtime decisions in a per-agent hash chain, that a third party can check offline without access to your systems. The gate verdict and the record you hand an examiner are the same object, not two systems you reconcile.

Those are developer observability tools — they help engineers debug agents faster, and they do it well. They produce dashboards and scores. Sengol produces evidence: a signed record, hash-chained per agent for runtime decisions and checkable offline, bound to the specific obligation it satisfies, plus the runtime controls that decide what happens next.

Only where you point it. The SDK sends records over HTTP to the Sengol API you run, which signs them and writes them to your own Postgres; the SDK never connects to the database. Sengol itself sends no licence check or telemetry. Deploy with Docker Compose, Helm or Terraform inside your VPC, or fully air-gapped. If you use a hosted LLM judge, that provider sees the judge prompt, and any sink, exporter, timestamp-authority or identity-provider URL you set receives what it is sent; run a local judge model and set no external URLs, and nothing leaves your network.

Each audit record has a canonical payload signed with HMAC-SHA256 and linked to the previous record in a per-agent hash chain, so the store is append-only and tamper-evident; CI run records are signed but not chained. Records are countersigned with Ed25519 when a signing key is configured, and chain checkpoints are anchored to an RFC 3161 timestamp authority and Rekor when you set their URLs. A third party can check an exported bundle offline with sengol-verify, without access to your systems: chain linkage and Merkle roots from the bundle alone, and the Ed25519 countersignatures against a public key. The HMAC needs your key, so it is checked online against the store. Proving who signed means pinning a countersigning public key obtained out of band, which sengol audit verify --offline --trusted-key accepts.

Add it. A framework in Sengol is a catalog entry with obligations and evaluator routing — no new Python classes. That is exactly how internal bank policies and regional regimes are supported, and they get the same compiled obligations, the same signed evidence and the same reports as the 29 that ship in the box.

Runtime instrumentation is two lines at process startup — sengol.configure() and sengol.instrument() — with no per-call changes to your agent code. The CI gate is one workflow step. Mapping your controls into a ControlBook is the part that takes real thought, and it is the part that produces the evidence.

No. Sengol is proprietary software from version 2.0 and there is no free tier and no feature tiers: one licence unlocks the whole appliance — the SDK, every evaluator, the signed audit store, the Console, the CLI and CI gate, judge governance, ControlBook-driven reports, and the Docker Compose, Helm and Terraform installs, air-gapped or not. A 14-day pilot is the full product. The one exception runs the other way: sengol-verify, the offline verifier, is a separate Apache-2.0 tool that needs no licence at all.