GovernorAIby SentinelLayer Request a briefing
Find and qualify
Discovery & Shadow AIInventory the AI activity nobody registered AssuranceEvaluate an agent snapshot before production
Decide and enforce
Policy & GovernanceKeep the policy engine you already run Runtime EnforcementDecide at the action boundary Inference & Model GovernanceGovern the model call itself Multi-cloudOne policy, each cloud's own controls
Prove and observe
Evidence & ComplianceTamper-evident record, mapped to controls Decision ObservabilitySee the decision behind the action
Risk and security
RiskScore the action, and act on the score ContainmentStop a runaway run before it lands Security architectureHow the control plane itself is built
By persona
SecurityPer-call authorization and stop controls GRCEvidence chains and control mapping Platform & AI EngineeringGovern without touching the agent
By risk
Shadow AIUnmanaged agents and connections Data leakageIn prompts, completions and tool calls Destructive actionsChanges to systems of record
By platform
AWS BedrockInbound path, guardrail attachment ServiceNowNow Assist discovery and scoped control SalesforceAgentforce and Einstein Bots, in-org MCPRegistry, proxy, argument-aware inspection
By cloud and runtime
AzureConnect, discover, govern at the gateway Google CloudValidated connect mode, bootstrap session DatabricksCluster-side egress, pinned at create Kubernetes & sidecarIn your cluster, on the agent host

USE CASES / SALESFORCE

Decide before the native tool runs.

An Agentforce agent or Einstein Bot executes inside Salesforce, on Salesforce's own runtime. Governing it from outside is not possible — so GovernorAI ships a managed package that places a decision step on the agent's path, inside the org, before the tool fires.

Agentforce, Einstein Bots, Flow Decision-only — no double execution Named Credential, no secret in Apex
A DECISION STEP PLACED INSIDE THE ORG 01 EnableAgent writes GovernorAI_Config__mdt through the Tooling API 02 Agent runs on Salesforce's own runtime outside our reach 03 Invocable action POST /api/v1/saas/salesforce/check/{agent_id} Named Credential 04 Verdict returns decision · reason · policy_id · rule_id · action_id X-Governor-Proxy-Secret 05 The flow branches before the native tool fires decision only, never execute-through Not an execute-through proxy. An allow would forward once, and the bot would then call the tool again.

An Agentforce agent runs on Salesforce's own runtime, so governing it from outside is not possible. The managed package puts a decision step on the agent's path, inside the org, before the tool fires.

decision onlyin-orgApex not yet org-tested

TWO TOPOLOGIES

Where the agent runs decides how it is governed.

Salesforce appears on both sides of the boundary, and the two cases need different mechanisms.

A — Salesforce as a toolAn external agent calls Salesforce as a downstream system.
Topology A — Salesforce as a tool An external agent calls the GovernorAI execute-through proxy. The proxy decides and, on allow, forwards the call to Salesforce and streams the response back. GovernorAI sits in the request path, so a deny stops the call before Salesforce sees it. GOVERNORAI IS IN THE PATH External agent outside Salesforce call GovernorAI proxy decides, then forwards allow Salesforce tool executes response streams back through the proxy A deny stops the call before Salesforce sees it. The proxy is the only way through, so the tool runs only on allow.
B — agent inside SalesforceThe agent runs in your org; the decision happens before its tool.
Topology B — agent inside Salesforce An Agentforce agent, Einstein Bot or Flow runs inside your Salesforce org. An invocable Apex action calls the GovernorAI decision-only check endpoint before the native tool executes, and the agent branches on the verdict. GovernorAI never forwards the call, so the tool runs at most once. GOVERNORAI IS CONSULTED, NEVER IN THE PATH INSIDE YOUR SALESFORCE ORG Agentforce Bot or Flow Apex action invocable check GovernorAI decision only no forwarding verdict returns allow the native tool fires — once deny the tool never fires
Topology
How the decision is applied
A — Salesforce as a tool
An external agent calls Salesforce as a downstream system. The execute-through proxy governs the call and, on allow, forwards it to Salesforce and streams the response back.
B — agent inside Salesforce
An Agentforce agent, Einstein Bot or Flow runs in the org. An invocable Apex action calls the decision-only check endpoint before the native tool executes, and the agent branches on the verdict.

Topology B deliberately does not use the execute-through proxy. If it did, an allow would have already forwarded the request to Salesforce once — and the bot would then call the tool again. Decision-only means the tool runs at most once, after allow.

THE MANAGED PACKAGE

What gets installed in the org.

01
The control plane enrols the agentEnableAgent writes a GovernorAI_Config__mdt custom metadata record through the Tooling API, carrying the agent's governance state, its per-agent gateway URL and the shared proxy secret.
02
The customer adds the actionThe GovernorAI Check invocable action goes into the Agentforce action list, the Einstein Bot dialog, or the Flow — wherever the decision belongs.
03
The action asks for a verdictIt reads the metadata record, then POSTs the tool name and arguments to /api/v1/saas/salesforce/check/{{agent_id}} through a Named Credential, authenticated with X-Governor-Proxy-Secret.
04
The gateway answers and recordsPolicy is evaluated, an audit event is emitted, and the response carries decision, reason, policy_id, rule_id and action_id — enough to show why, not just what.
05
The agent branchesAllow, deny or pause is applied by the agent's own logic before the native tool is invoked.

The package also carries the Named Credential and External Credential principal, so the shared secret is held by Salesforce's credential store rather than written into Apex, plus a permission set scoping who may invoke the action.

BEFORE THE PACKAGE IS ENABLED

Deciding before the native tool runs assumes the agent belongs there.

The managed package puts a decision on the agent path. Assurance is the step before: an agent is scored as a pinned snapshot against acceptance bars set in advance, so what was evaluated and what goes live are the same thing.

Results leave as a re-verifiable artifact rather than a dashboard state, so a reviewer is not asked to trust a screenshot.

See what each domain needs →

Continue

ServiceNowThe same pattern, as a scoped app IntegrationsEvery enforcement point in one table Runtime EnforcementDecide at the action boundary