May this identity reach this resource?
Settled before the agent decides what to do with the access. A valid credential is the beginning of the problem, not the end of it.
Identity & access managementCompany / Where we fit
Two categories are converging. We are the part neither one started from.
AI security platforms watch the traffic. AI governance platforms hold the register. Both are moving toward the same place — a decision on the action itself — and neither began there. GovernorAI did.
Action-level decision, not traffic or registry Seven enforcement points, multi-cloud Evidence an assessor verifies, signature checkable offline
THE FOURTH QUESTION
Three questions about the action. One that decides it.
That refund passed every check most teams already run. Who is asking, is it hostile, what does the rule say — every one of those is a question about the action. Only the fourth is the action itself, and it is the one that stopped the refund.
Is this interaction malicious?
Prompt injection, exfiltration, jailbreaks. GovernorAI detects these before policy runs — so what it finds decides the action, instead of raising an alert someone reads on Monday.
AI security platforms · GovernorAIWhat is our policy, and are we compliant with it?
A register describes the rule. GovernorAI holds it, enforces it, and produces the evidence mapped to the controls your assessor asks about — one place, not three systems reconciled after the fact.
GRC & control towers · GovernorAIMay this specific action proceed, right now?
Allow, deny, or hold for a named human — decided per action against one policy, and written down in a way that proves afterwards which way it went. The hold is the part GovernorAI is built around: not a flag raised after the fact, a call that does not proceed until someone holding the named role votes.
GovernorAI Answered the same way everywhere GovernorAI answers question four the same way in every cloud, SaaS and tool you run — one policy object, one decision core.
Each platform’s native governance is excellent inside its own boundary. GovernorAI carries one policy, one register and one audit trail across all of them, so the boundaries between them are not yours to reconcile.
THE THREE CATEGORIES
What each one is actually good at.
Written to be recognised by someone who has evaluated all three, including where we are behind.
Discovery of employee and agent AI use, inline visibility on the wire, and strong content classification. Aurascape is the reference example.
strength: detection qualityModel and agent registries, policy packs, continuous assessment and audit-ready documentation. Credo AI is the reference example.
strength: programme packagingControls for the AI running in a single platform — ServiceNow AI Control Tower and AWS Bedrock AgentCore being the clearest cases. Deep, native, and bounded by the platform that ships them.
strength: depth in one estateA per-call verdict at the action boundary where intent becomes a change in a system of record — across clouds, SaaS, MCP and frameworks — recorded as tamper-evident evidence.
strength: execution controlHONEST CONTRAST
Where we lead, where we coexist, and where we are behind.
A comparison that only lists wins cannot be checked. This one names the place a competitor is genuinely stronger.
| Dimension | AI security platforms | AI governance / GRC | GovernorAI |
|---|---|---|---|
| Execution-path enforcement | One agent-action integration, typically MCP | Registry and assessment; runtime is recent and narrow | Seven registered enforcement points with a published capability matrix the runtime enforces |
| Runtime control plane | A guardrail. Content inspection over prompts and responses, probabilistic by design — it judges whether text looks like a jailbreak, an injection or an unsafe answer | Not a runtime control | An authorisation decision. Deterministic policy over identity, action, resource and context, with OPA/Rego on the hot path so the engine you already run for everything else decides this too. A guardrail cannot express “refunds over $10,000 need a human”; a policy can, and the same rule is testable and versionable before it ever runs |
| Detection quality | Ahead of us. Multimodal ML classification leads the field | Not the focus | Seven deterministic detectors on by default, plus an optional, default-off semantic detector that can only add a deny |
| Shadow AI source breadth | Ahead of us on direct vendor coverage | Mostly registry and attestation | Normalised event schema, correlation and provenance shipped; direct vendor connectors expanding |
| Evidence | Audit-trail messaging | Audit-ready reports and documentation | Hash-chained ledger, with optional Ed25519/Merkle batch manifests an assessor verifies with the GovernorAI verifier. Third-party verification without any GovernorAI component is roadmap — there is no JWKS or out-of-band key publication yet |
| Pre-production assurance | Runtime posture. Nothing blocks a release | Questionnaires and documentation review, not an executable gate | Six implemented evaluators scoring an immutable snapshot against bars preregistered before the run, shipped as a CI/CD gate where unreachable fails closed. Whether a domain can be measured is computed per deployment and the missing prerequisite is named — two are measurable in a typical deployment today, and not_assessed is never reported as a pass |
| Policy model | Vendor rule sets | Governance workflows and policy packs | Native DSL and OPA/Rego on the hot path — keep the engine you already run |
| Scope | Broad security posture | Broad governance posture | Cloud, SaaS, MCP and frameworks in one policy and evidence plane |
| Deployment | SaaS | SaaS | Hosted or self-hosted. An air-gapped shape is architectural, offered only by enterprise qualification — not a standard tier |
The concession, stated on purpose
A multimodal classifier detects things a deterministic detector will miss. We chose determinism because a governance decision that cannot be reproduced cannot be defended to an assessor — and because a model inside the governance path is a model that can drift. The semantic detector exists for teams who want the coverage, off by default, and it can only add a deny, never soften one.
COEXISTENCE
Platform-native governance makes this more useful, not less.
Every major platform is building governance for its own AI estate. An enterprise running several still needs one policy and one record across them.
ServiceNow, Salesforce and AWS each ship real governance for the AI running on their own platform, and each is extending it outward. We expect that to continue, and it does not weaken the case for this layer — it strengthens it. Every capable platform register an enterprise adds is another policy to author, another set of controls to reconcile, and another evidence format an assessor has to be walked through. GovernorAI coexists with all of them and gives the security team one place to state the rule and one place to read what happened. The argument was never that the native controls are inadequate. It is that owning four good ones is not the same as having one answer.
WHERE IT SITS
Not another register. The layer between the policy and the action.
If you already run a control tower and an identity provider, the question is not whether GovernorAI replaces them — it does not. It is which layer answers “may this agent do this, right now”, and whether you can get that answer, in the same terms, in more than one of the environments you run.
Layer 01GRC & control towers
Where policy is written, attested and audited. Answers what the rule is — not whether a given action at 02:14 complied with it.
Layer 02Identity & access
Okta, Entra, cloud IAM. Answers whether the identity may reach the resource — a question settled before the agent decides what to do with it.
Layer 03GovernorAI
Answers whether this specific action may proceed — allow, deny, or hold for a named human — against one policy, and writes down which it was. This is the layer nobody else occupies across more than one estate.
One policy model · one place to read what happened · every environment below
Layer 04Enforcement points
The surfaces where a decision lands: a proxy, a sidecar, an ext_proc filter, a scoped app inside someone else’s SaaS. Each carries out what it can, and the matrix prints what it cannot.
Layer 05Agents, models and tools
What your teams build, on whatever stack they chose. Yours — we do not build them, host them, or sit in the availability path of every token. Where a framework is governed, a thin wrapper stands between the agent and its tools; that is the integration, and it is the whole of it.
THE QUADRANT
Action × multi-cloud × full lifecycle.
We have not found another product in all three at once.
Products that decide on the action are usually single-integration or single-platform. Products that span clouds are usually observing rather than deciding. Products that cover the full lifecycle — discover, assure, govern, enforce, prove — are usually assessing rather than enforcing. The combination is the position, and two U.S. provisional applications are on file.
WHERE THE COMPARISON ACTUALLY LANDS
Everyone is adding both halves. The question is what each half is looking at.
Having both halves is not the rare part — several AI security platforms ship pre-release testing and runtime guardrails together. The rare part is the reach of each half. Theirs act on model behaviour, and where they now reach the agent it is MCP tools. Ours assess the agent's authority before release, and decide the action itself once it is live — at the cloud, SaaS and tool boundaries an enterprise actually runs.
Test the model, guard the prompt
Several run both halves: algorithmic red teaming before release, then inline guardrails after. A guardrail inspects content — it asks whether text looks unsafe. Authorising an action is a different control plane, and the newest agent-level authorisation work is real but scoped to MCP tools. Their own documentation is explicit that it does not reach enterprise SaaS.
Assess the documentation
Registers, questionnaires and attestation. The review is of what a team wrote down about the agent, not of the agent, and it cannot fail a build.
Marks its own homework
A gate built by the platform that ships the agent is judging its own delivery stack. It can be useful; it cannot be independent, and an assessor knows the difference.
An executable gate, from outside
An immutable snapshot, bars preregistered before the run, a CI/CD exit code that blocks the pipeline, and a result that leaves as a re-verifiable artifact rather than a dashboard state.
One thing does not change with the category: a gate is only worth anything if it is allowed to say no to the team that owns the deadline. That is an organisational position as much as a technical one, and it is why a bar preregistered before the run matters more than the score it produces. A bar chosen once the results are in is a rationalisation, and an assessor can tell.
Two of the six domains are measurable in a typical deployment today. The other four return not_assessed with the missing prerequisite named, rather than a pass. A governance tool that reports a pass it cannot support is worse than one that reports nothing — so that is the output we would defend hardest. See what each domain needs →
WHAT ONE RULE CAN SAY
The difference shows up the moment you write a policy.
Category names are arguable. Rule syntax is not — it either has a place to put the condition or it does not. Read from each vendor's own policy documentation in September 2026.
| Product | What a rule matches on | Outcomes | “Refunds over $10,000 need a human” |
|---|---|---|---|
| Check Point / Lakera AI Guardrails | Detector categories, a flagging-sensitivity level from L1 lenient to L4 paranoid, message roles, and allow or deny word lists | Flag or block | No place to put it. The knobs are detector types and confidence thresholds |
| Amazon Bedrock Guardrails | Content-filter categories, denied topics, exact-match word filters, PII and custom regex, contextual grounding | Block or mask | No place to put it. Every filter reads the prompt or the response |
| Cisco Duo Agentic Identity | Duo user groups mapped to the MCP tools those members may invoke | Allow, or deny by omission | It can say who may call process_payment. It cannot read the amount |
| GovernorAI | A tool pattern plus a condition on the call's own arguments — field, operator, value — evaluated before the action runs | Allow, deny, or hold for a human | Three rules, one field, shown below |
# the condition is the point: args.amount, not the wording of the prompt
- id: allow-small-payment
match:
tool: "finance.process_payment"
condition: { field: "args.amount", operator: "<=", value: 1000 }
action: allow
- id: approve-medium-payment
match:
tool: "finance.process_payment"
condition: { field: "args.amount", operator: "<=", value: 10000 }
action: require_approval
reason: "Payments between $1,000 and $10,000 require manager approval"
- id: deny-large-payment
match:
tool: "finance.process_payment"
condition: { field: "args.amount", operator: ">", value: 10000 }
action: deny
This is not a claim that the others are weak at what they do. A content filter is the right control for prompt injection, and Lakera and Bedrock are good at it. The point is narrower: a rule about an action needs somewhere to put the action's own values, and a detector threshold has nowhere to put them. Where a competitor does authorise a tool call, the grant is identity to tool name — it decides who may call process_payment, not what may be passed to it. If you prefer Rego, the same rule runs on OPA on the hot path, on the engine you already operate.