Control your AI agents before they control prod.

It runs your AI agent in a sealed box, attacks it, and hands you a signed pass or fail — before you ship it, and while it runs in production. Probity secures an agent at two moments: it tests it before you ship, and it contains it while it runs in production. Whether your team built the agent or pulled one in, once it has real access it can be talked into misusing it. Other tools read the code (and miss what only happens when it runs) or dump raw logs. Probity runs it in a sealed box, attacks it, decides, and signs the result so anyone can re-check it. The Gate blocks a compromised agent from shipping; the Runtime keeps the same sealed box around it in production, so an agent that turns bad later is stopped and the catch is signed.

If your app runs an AI agent — one you built or one you pulled in — yes. You don't have to be a bank; you just have to be giving an agent real access. Any agent with reach into your systems can be talked into misusing that access, and if you also load someone else's MCP server or skill, you're running code nobody security-checked on top of that. Probity runs the agent in a sealed box, throws real attacks at it, and gives you a one-line CI check that blocks a compromised agent or a booby-trapped dependency before it ships. The same sealed box then contains the live agent in production. No security team required. A regulated enterprise runs the same command; they just also want the compliance paperwork.

One line in the CI you already run. Add `probity gate ./server.oci`. The first run is zero-config (sane defaults, leak attempts caught by a dead-end we control), so you get a green or a real finding without writing any policy. An allowlist is opt-in, for tuning a finding, not a precondition to your first green. A full run takes a minute or two, and warn mode never blocks while you dial it in. On a real catch it fails the build and emits a bundle your pipeline reads directly. In production, the same sealed box stays on as the Runtime: one field in your deployment config.

Not in any way you'll notice. Your agent's time goes to the model, not to us. An AI agent spends most of its life waiting on model inference, hundreds of milliseconds to seconds per step. The box's tax sits well under that: a lightweight microVM around the process, a host-side check on each outbound action, and no LLM anywhere in the enforcement path. Signing stays off the hot path too. The boot cost lands once, at the start of a run, and clones come off copy-on-write snapshots. The one time you actually feel the Runtime is when it freezes an agent mid-violation, and that is the product working, not overhead. The Gate's full attack run costs a minute or two in CI, where nobody is waiting on it.

All of them. If it ships as a container, we can run it. The box runs your agent's container image and watches its behavior from outside, so there is nothing to integrate: no SDK, no code changes, no language bindings. Python, Node, Go, Rust, or whatever else is in the image works already. Frameworks are the same story, since LangChain, CrewAI, AutoGen, and next month's framework all sit inside the box while we gate at a boundary they can't route around: the process, the filesystem, the network; swap frameworks and the boundary stays put. One substrate covers MCP servers, A2A agents, and agent skills, and the verifier runs anywhere: Node, pure Python, or right in your browser.

A curated, taxonomy-mapped set of real agent attacks — prompt injection, tool poisoning, data theft, secret theft, excessive agency — run against your agent for real, not simulated. Thirty known CVEs, raw-protocol fuzzing, and the SAFE-MCP technique library, maintained by our security research team and mapped to the catalogs your auditor already knows: MITRE ATLAS and the OWASP GenAI Top 10. So a PASS reads as “these classes were thrown and contained.” We also ship original research: we disclosed a new agent vulnerability class and released MIT-licensed detection rules for it before any public advisory. The one honest bound we always state: a PASS is coverage-bounded — it means the attacks we ran were contained, not that the agent is “safe” against something we didn't throw. Enterprise teams can review corpus contents and coverage and bring their own threat-model cases; the verdict is deterministic and you re-verify it yourself.

The verdict carries digests, not contents — and with self-host, your image and secrets never leave your boundary at all. The agent only ever sees a decoy credential. The real one is injected host-side, to a single allowlisted destination, at the instant of use — any attempt to send it elsewhere hits a dead-end we control and is sealed into a signed catch-record. Your source code never enters the box; each run gets its own sealed box. The verdict carries only digests — never your code, memory, or secret — signed with a key that never touches a public log. To keep real secrets out of our reach entirely, run the gate with test credentials (it still exercises the leak paths) or self-host, so the image and the real credential never leave your infrastructure.

Scanners read the code; sandboxes run it and hand you logs; inline gateways filter with a model and keep no portable proof; Probity runs it, contains it, and signs a verdict anyone re-checks offline. Probity sits in the empty quadrant: real execution, real-time containment, and a signed verdict you re-verify offline with just a public key. The hard part to copy isn't the signature — that's table-stakes — it's the byte-identical substrate that makes the proof reproducible on any host. A sealed box, some attack scripts, and a signing step are a weekend; a cross-host byte-identity substrate plus a maintained adversary corpus is not.