5 questions to ask any AI-agent governance vendor before you sign
TL;DR: Most AI-agent governance vendors will tell you they solve the same problem. Five questions separate the ones that actually do from the ones running configuration theater. Print this. Bring it to the vendor call. Watch the answers.
I've spent 26 years in identity governance across IBM and Oracle. In the last 18 months, the market has flooded with vendors claiming "AI-agent security" as a first-class product line. Most of them shipped a rebrand. Some of them shipped real controls. This post is the buyer-side test for telling the two apart.
Use these questions in order. If a vendor can't answer #1, don't waste time on #2. If they can't answer #2, the rest doesn't matter.
Question 1 — Show me the rule that admin cannot turn off
What you're actually asking: Does safety live above your operator, or inside their configuration?
Watch for: Anything that sounds like "just set this policy" or "add this to your ruleset" or "we recommend enabling this by default."
What a good answer looks like: The vendor shows you a signed manifest loaded at process startup. The signing key is baked into the binary. Changing a rule requires deploying a new signed manifest through the release pipeline — not a config toggle. Admin can add policies on top; admin cannot remove or override the base layer.
Why this matters: If the strongest admin credential in your org can turn off the safety net, so can an attacker who obtains that credential. And it happens every 90 days somewhere in the Fortune 500.
How SidantiX answers: The Machine Constitution. Signed at build, loaded at boot, verified on every action. Read the spec. Try to break it.
Question 2 — Show me the cryptographic receipt for a denial
What you're actually asking: After a breach, can you prove exactly what happened — or are you relying on the vendor's log integrity?
Watch for: "We have audit logs" (log ≠ proof), "We use append-only storage" (doesn't help if the log-writing process is compromised), "It's stored in your S3" (better, but is it signed?).
What a good answer looks like: Every action — allowed or denied — produces a cryptographically signed record. Records are hash-chained (each references the previous, so silent deletion breaks the chain). Signed with the tenant's own key. Written to the tenant's own storage with Object Lock retention. Verifiable offline, without the vendor's involvement, using a small CLI and the tenant's public key.
Why this matters: The current AI-agent breach cycle is disclose → investigate → prove-what-happened. Vendors that can't hand you cryptographic proof end up with 3-week forensics engagements at $2,000/hr. Vendors that can, hand you the receipt file and you verify it in 30 seconds.
How SidantiX answers: Agent Decision Receipts. ECDSA-P256 signed, SHA-256 hash-chained, stored in your S3 with Object Lock. Offline-verifiable with a 12 KB CLI. Read a sample. Verify one yourself.
Question 3 — Show me the enforcement running before the model, not inside it
What you're actually asking: Where does the guardrail live in the request path?
Watch for: "Our model is fine-tuned to refuse harmful requests" (alignment ≠ enforcement), "We prompt-engineer the system prompt to include safety rules" (a clever enough prompt defeats this), "We have output filtering" (too late — action has already been decided).
What a good answer looks like: The vendor shows you a distinct enforcement layer that runs BEFORE the model sees the prompt. Prompts matching known attack patterns (instruction override, role hijack, prompt leak, self-elevation, tool escape) are denied at the gate. The model never sees them. Its "alignment" is a defense-in-depth backstop, not the primary control.
Why this matters: Every publicly-disclosed AI-agent breach in 2026 involved a model being persuaded to do something outside its intended scope. If persuasion is a valid attack vector against your enforcement, no amount of model improvement will fix it. You need enforcement that isn't reachable via prompt.
How SidantiX answers: Pre-LLM prompt-injection gate aligned to OWASP Agentic Security Initiative. Runs before the model reads the prompt. Try to bypass it.
Question 4 — What happens if your control-plane process is compromised?
What you're actually asking: Is your security model "trust the vendor" or "verify without the vendor"?
Watch for: "We have SOC 2" (that means someone read our policies once a year, not that our runtime is safe), "We use zero-trust internally" (good, but does that extend to what YOU can verify?), "Contact us if you suspect an incident" (that means you can't verify independently).
What a good answer looks like: The vendor's answer shows what you can prove without touching their infrastructure. If evidence lives in your S3 with your keys, you can verify integrity even if the vendor is entirely compromised. If constitution rules are hash-chained into every receipt, you can prove the vendor didn't silently change the rules mid-flight. If you can build the CLI from source and verify a receipt on your air-gapped laptop, you're not trusting the vendor for the truth — you're trusting math.
Why this matters: Any SaaS vendor is one credential compromise from being a threat actor in your environment. The security model that survives that scenario is worth 100× the one that doesn't.
How SidantiX answers: Constitution hash included in every receipt. Receipts stored in your S3, not ours. Verification CLI open-source (or will be — currently in the spec repo). Zero SidantiX access needed to verify any historical claim about what our system did.
Question 5 — What don't you catch?
What you're actually asking: Are you being honest about the failure modes I'll still have to manage?
Watch for: "We solve AI-agent security" (nobody does — this is a shape of problem, not a solved problem), "Our controls are comprehensive" (no controls are), any answer without at least three specific gaps.
What a good answer looks like: The vendor lists concretely what they DO NOT stop. "We do not prevent a misaligned model from trying to escape — we prevent the escape from succeeding." "We do not stop insider abuse by legitimate admins — we do record every action with cryptographic proof, so you can prosecute after the fact." "We do not solve fully air-gapped deployments — outbound-only mTLS is our baseline, air-gap is a separate architecture review." Vendors who list gaps are more trustworthy than vendors who claim comprehensive coverage. Nobody comprehensive.
Why this matters: Every "we solve X" claim is a promise your security team will hold the vendor to at 2 AM during an incident. If the vendor is honest about gaps upfront, you scope your other controls to cover them. If they're not, you find out during the incident.
How SidantiX answers: We list the gaps in every product page, and on this blog post above. If we sound like we cover everything, please tell us — that's a warning sign we don't want to send.
What to do with these answers
Score each vendor 0–5. Anyone below 3 is running configuration theater. Anyone at 4–5 is doing the actual work.
We are not the only vendor answering 5. There are two or three others in the market that we respect. If we're not the right fit for you, we'll tell you honestly and point you at them — the founding-partner-stage move for us is finding real fit, not maximizing signups.
Ask the questions. Get the answers. Make the call based on what the vendor can show, not what they claim.
Try SidantiX in your browser — all five answers demonstrable in under 3 minutes. Start Self Experience. Or start a 30-day free trial with your own tenant. Or contact the founder directly if you'd rather talk it through.