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; Ed25519 signing available per deployment
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 feeds the same decision on the action, alongside the rule and the approval.
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, and its Agent Governor now brings runtime decisions into the Claude Code harness as a research preview.
strength: programme packagingControls for the AI running in a single platform — ServiceNow AI Control Tower and AWS Bedrock AgentCore being the clearest cases. AgentCore Policy, generally available since March 2026, decides tool calls at the AgentCore Gateway in Cedar, and its temporal policies, announced in August, add approval, count and running-total rules over a session. Deep, native, and scoped to 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 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 enforcement is arriving: as of 6 October 2026, in research preview inside one coding-agent harness | Seven registered enforcement points with a published capability matrix the runtime enforces |
| Runtime control plane | Mostly a guardrail: classification over prompts, responses and tool traffic — it judges whether content looks like a jailbreak, an injection, a leak or an unsafe answer. Some now add tool-level authorization at an MCP gateway | Historically outside the runtime path; agent-harness enforcement now in preview | 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 content classifier has no field for a refund amount; an action policy does, so “refunds over $10,000 need a human” is one testable, versioned rule 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 | Logs and alerts over inspected traffic | Audit-ready reports and documentation; per-decision records in newer runtime products | Hash-chained control-plane audit log, 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 | Red teaming and model testing before release; whether a result blocks a release depends on how each team wires it | Assessments, questionnaires and documentation review of the system | Six implemented evaluators scoring an immutable snapshot against bars preregistered before the run, returned as a decision surface a deploy step can consume; shown today as a demo, not yet the automated stop in your pipeline; an unreachable control plane never reads as a pass. 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. Remote evaluation is not a replacement for your OPA management plane. |
| Scope | Broad security posture | Broad governance posture | Cloud, SaaS, MCP and frameworks in one policy and evidence plane |
| Deployment | Predominantly SaaS, some with self-hosted options | Predominantly SaaS | Hosted or self-hosted. Offline-tolerant; self-hosted control plane scoped per engagement |
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.
NAMED PRODUCTS, CHECKED 6 OCTOBER 2026
The two closest products, from their own documentation.
Both decide an agent's action before it runs, and both can stop it for a human. As of 6 October 2026, one is a research preview inside a coding-agent harness; one is generally available inside AWS, with session-aware approval, count and running-total rules. Each is good at what it is built for, and either can run alongside GovernorAI.
| Dimension | Credo AI Agent Governor | AWS Bedrock AgentCore Policy | GovernorAI |
|---|---|---|---|
| Status | Research preview and beta service, not generally available, as of 6 October 2026 (announced July 2026) | As of 6 October 2026: Policy generally available since 3 March 2026, per AWS's announcement. Temporal policies documented in 16 AWS Regions (announced 6 August 2026) | As of 6 October 2026: available through the design-partner program; self-service timing is on Pricing |
| Supported integrations | Claude Code today; Codex, Cursor and Microsoft Copilot in development | Tools behind an AgentCore Gateway: MCP servers, OpenAPI, Lambda and HTTP targets | AWS, Azure, Google Cloud and Databricks; Salesforce and ServiceNow; MCP; agent frameworks through the SDK |
| Control point | Inside the agent harness, before each action runs | The AgentCore Gateway, outside the agent's code; temporal rules need the gateway and its targets in one AWS account and Region | At the action boundary on each distinct path: the gateway or sidecar, the SDK, Envoy ext_proc, the MCP proxy, Salesforce's native action gate and governed API route, ServiceNow's workflow check and before-write rule, Databricks Model Serving and cluster egress |
| Who sets the policy | Curated postures (permissive, balanced, strict) installed by IT; custom policies listed as coming soon | Builders and security, compliance and operations teams, in Cedar or plain English translated to Cedar | The business owner, through a versioned policy: an author and an approver on each version, draft to active, a diff between versions, and rollbacks that need approval. Native rules or OPA/Rego, held once for every path |
| Approvals | Escalate: the action stops and waits for a named human | A temporal rule permits a call only after a matching approval action earlier in the same session | On the gateway, sidecar and MCP paths a hold returns an approval reference and the call does not run. The approval routes to a multi-step workflow with named approvers or groups and a required count |
| Limits across actions | Not described in the reviewed material | Count and sum over earlier actions in the same policy session, within a 24-hour window. The session is identified by a session ID the caller sends with each request | Iteration and wall-clock caps on an agent loop, counted per account, loop and authenticated principal over a continuous run. Enforced on the gateway and sidecar path |
| Evidence | A structured record per decision: policy version, who started the session, tool and arguments, decision and reason | Decisions in CloudWatch metrics and logs, with spans when tracing is on | Recorded decisions, a hash-chained control-plane audit log and optional Ed25519-signed Merkle batch manifests, checked with the GovernorAI verifier. Pre-release assurance is pinned to the agent's exact configuration, marked stale when it changes, and read next to that agent's runtime decisions |
Reviewed 6 October 2026 against each vendor's own documentation. Preview and availability status changes; the sources and quoted passages are listed per claim.
Where the difference is. Approvals, deterministic rules and limits on their own are not it: AgentCore Policy has all three for the calls that cross its gateway. GovernorAI's difference is the operating process around them: a business owner who versions and approves the rule; the same rule enforced across distinct execution paths, from the SDK to the SaaS platforms' own gates; loop caps scoped to the agent's run and its authenticated identity; and pre-release assurance read next to the decisions the same agent makes in production.
Running AgentCore Policy for your AgentCore agents? Keep it. It is the native decision for the tool calls that cross that gateway. GovernorAI adds the same business rule, approval and record for the actions those agents — and your other agents — take outside it. How that works on AWS →
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.
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.
What GovernorAI is built for: 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. Most act on model behaviour, and where they reach the agent it is usually through an MCP or model gateway. 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. Agent-level authorisation from security vendors is real and growing; the products we reviewed attach it at an MCP or agent gateway.
Assess the programme
Registers, questionnaires and attestation. The review is mostly of what a team documented about the agent. Runtime agent controls are now arriving from this side too, starting in preview.
Judged inside its own stack
A gate built by the platform that ships the agent is deep and convenient. It judges the agent inside the same vendor's delivery stack, and an assessor weighs that differently from a check run from outside it.
A pre-deployment decision, from outside
An immutable snapshot, bars preregistered before the run, distinct exit codes a deploy step can consume (shown today as a demo), 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; rechecked 6 October 2026.
| Product | What a rule matches on | Outcomes | “Refunds over $10,000 need a human” |
|---|---|---|---|
| Check Point / Lakera AI Guardrails | Detector categories (prompt defense, data leakage, content moderation, malicious links, agent behaviour) and a flagging-sensitivity level from L1 lenient to L4 paranoid | Flag, which your application or gateway blocks on | No documented field for 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 documented field for it. The filters read prompts, responses and tool content |
| Cisco Duo Agentic Identity (beta) | Duo user groups mapped to the MCP tools those members may invoke | Allow, or deny by omission | It can say who may call issue_refund. The documented rules don't read the amount |
| AWS AgentCore Policy | Cedar policies over the principal, the tool and the input parameters of the call; temporal rules (prior approval, counts and running totals) over earlier events in the same session | Permit or forbid | Can express it: an input condition on the amount, plus a temporal rule that permits the call only after a matching approval action earlier in the session. Scoped to tool calls through AgentCore Gateway |
| Cerbos (authorization engine) | Resource and principal attributes, with CEL conditions in YAML policies | Allow or deny; a human step-up comes from a paired system | Can express it if the action is modelled as a resource with its amount as an attribute |
| 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 | Two rules, one field, shown below |
# the condition is the point: args.amount, not the wording of the prompt
- id: allow-routine-refund
match:
tool: "support.issue_refund"
condition: { field: "args.amount", operator: "<=", value: 10000 }
action: allow
- id: finance-approves-large-refund
match:
tool: "support.issue_refund"
condition: { field: "args.amount", operator: ">", value: 10000 }
action: require_approval
reason: "Refunds over $10,000 need Finance approval"
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 an authorization product does read the arguments — AgentCore Policy and Cerbos both can — the difference is reach: each decides the calls that pass through its own gateway or service. GovernorAI carries one rule, its approvals and its evidence across the cloud, SaaS and MCP paths an enterprise runs. If you prefer Rego, the same rule runs on OPA on the hot path, on the engine you already operate.