01 / BUSINESS AUTHORITY
An approved task.
Not a blank check.
Set what runs, what needs review and what must never proceed. Bind authority to the business record and exact action—not a session an agent can restart.
Use cases / ServiceNow
Your ServiceNow approvals.
Enforced where
AI acts.
Put business policy in charge of your ServiceNow agents. Connect release decisions, action-specific approvals and evidence—so routine work runs, consequential changes get reviewed, and prohibited actions stay blocked.
One ServiceNow instance is enough. Keep the work where it is.
INC0018427 · Incident operations
HOLD · APPROVAL REQUIREDCritical closure held.
The service is restored. Closing the incident still needs its incident commander’s authority.
REQUESTED ACTION
Close one critical incidentINC0018427 · Resolved → Closed
PolicyService operations
ApprovalPending
Target outcomeResolved · not closed
Not dispatched to ServiceNowInspect this decision
ApprovalPending
Dispatches0
Target effectUnchanged
CRITICAL-CLOSURE
Critical closure → incident commander approvalTest the boundary
Approval does not write the record.
Decision dec-sn-1042-e1Open the full walkthrough
Deep integration.
One operating model.
One operating model.
Now Assist & AI agentsFlow DesignerITSM & ChangeCMDBSecOps & IRMAPIs & MCP
Why GovernorAI, even on ServiceNow alone?
One instance.
Real business consequences.
An agent does not need another platform to close a critical incident, expose a protected field or expand its privileges. Govern those consequences where the work happens.
An approved task.
02 / ONE OPERATING PROCESS
Stop rebuilding governance
for every agent.
Bring risk owners, release criteria, approved policies and expiring exceptions together. Keep the operating boundary connected as agents and tools change.
03 / CONNECTED EVIDENCE
Know what was authorized.
See what happened.
Keep the request, policy, approval and recorded result together. Give reviewers a complete decision trail and operators the next step.
Built alongside your controlsAlready have AI Control Tower?
Already have AI Control Tower?
Keep it.
Keep ServiceNow’s inventory, permissions, workflows and runtime controls. GovernorAI connects your business-policy and risk decisions to exact-action authorization, release assurance and recorded outcomes.
The added value is one repeatable governance process—not a second approval queue. Native denials stay in force.
In the product
See a held action and its record, in the console.
Recorded on a demo tenant, not in a ServiceNow instance: decisions at the action boundary, a held action with its reason, what each enforcement point can execute, and the record every decision leaves.
A held action, step by step
Real product screens from a demo tenant with seeded activity: the outcome, the rule and the reason for each governed action.
Recorded against a demo tenant with seeded activity. Real product screens, not a mock-up.
See it work · entirely inside ServiceNow
One incident approved.
Not every incident.
A critical incident is ready to close. The agent proposes the change; the incident commander authorizes it. Try the approval, then change its scope. Every example begins and ends in the same instance.
Governed action / Critical incident closureInteractive simulation · one ServiceNow instance
01 / The agent proposes
Close one critical incident
A Now Assist workflow proposes closing a resolved priority-one incident after service restoration and the required resolution evidence.
- Agent
- incident-assistant
- Source
- ServiceNow · Now Assist workflow
- Action
- servicenow.incident.close
- Target
- INC0018427 · Resolved → Closed
- Record
- INC0018427
- Context
- Priority 1 · restored · closure evidence complete
The example incident is Resolved and its configured closure prerequisites are met. An approval records the decision on this record transition; it does not release the write, and native permissions still apply.
02 / Your policy authorizes
HOLD · APPROVAL REQUIREDdec-sn-1042-e1
Held before the write.
The incident is ready to close. It is held for its incident commander; an approval records the decision, and the scoped app does not replay the write.
CRITICAL-CLOSURE
Critical closure → incident commander approvalApprovalPending
Dispatches0
Target effectUnchanged
Test the boundary
An approval covers no later request and never overrides a native denial.
Approval does not write the record.
One connected decision trail
01 · RequestedINC0018427
02 · EvaluatedService operations policy
03 · Approval pendingPending
04 · Not dispatchedNo write sent
05 · No new resultTarget unchanged
Inspect the example decision record
{
"example": true,
"schema": "illustrative_governance_record_v2",
"scenario": "change",
"workload_platform": "ServiceNow",
"workload_scope": "single_instance",
"instance": "service-ops-prod",
"request": {
"id": "req-sn-1042",
"source_record": "INC0018427",
"agent": "incident-assistant",
"action": "servicenow.incident.close",
"target": "INC0018427 · Resolved → Closed",
"arguments": {
"state": "Closed"
}
},
"governance_context": {
"example": true,
"policy_owner": "Service operations",
"risk_owner": "Service operations",
"agent_snapshot": "incident-assistant@v3",
"release_reference": "illustrative-reviewed-release",
"release_evaluation_performed_by_demo": false,
"native_denials_preserved": true
},
"policy": {
"id": "pol-sn-service-ops",
"name": "Service operations",
"rule_id": "critical-closure"
},
"latest_decision": {
"id": "dec-sn-1042-e1",
"verdict": "hold",
"reason": "Held before the write."
},
"approval": {
"status": "Pending",
"authority": "Awaiting incident commander",
"id": null
},
"execution": {
"id": null,
"status": "not_dispatched",
"dispatch_count": 0,
"confirmed_effect_count": 0,
"target_result": null,
"native_check": "required_before_dispatch",
"idempotency_key": null,
"duplicate_suppressed": false,
"reconciled": false
},
"integrity": {
"cryptographic_verification": "not_performed_in_this_mockup"
},
"events": [
{
"sequence": 1,
"event": "action.requested",
"example": true,
"request_id": "req-sn-1042",
"action": "servicenow.incident.close",
"target": "INC0018427 · Resolved → Closed",
"arguments": {
"state": "Closed"
}
},
{
"sequence": 2,
"event": "action.evaluated",
"example": true,
"decision_id": "dec-sn-1042-e1",
"verdict": "hold",
"reason": "critical-closure",
"policy_id": "pol-sn-service-ops"
}
]
}Simulated approval, dispatch and target confirmation are separate steps. No systems are connected.
Follow the policy lifecycle ↓Govern the agent. Not just this request.
One policy.
From release to result.
The business owner sets the boundary. Engineering ships the approved agent. Runtime decisions and evidence stay connected to that authority.
Discover
Know the agent, its tools, its reach and its accountable owner.
Assure
Test the exact agent configuration against your release criteria.
Govern
Approve operating limits, reviewers and time-bound exceptions.
Enforce
Check the proposed action before the governed operation executes.
Prove
Connect the policy and human authority to the recorded outcome.
A new tool is a new risk decision. Material changes return the affected release for review, rather than silently inheriting old authority.
Explore the policy lifecycleDeep ServiceNow integration
Your teams’ context.
Your agents’ boundaries.
Use the ownership, service context and workflows your teams already maintain. Return decisions and outcomes to the people who need them.
Know what agents touch.
Map AI Agent Studio agents, tools and teams, Now Assist skills, MCP connections and model providers to owners and business services.
AI INVENTORY · OWNERSHIP
Decide with business context.
Use service criticality, effective identity and approved change conditions to decide what this action is allowed to do.
CMDB · IDENTITY · CHANGE CONTEXT
Keep approvals in ServiceNow.
Route to the accountable approver. Keep the held write held: an approval records the decision, and an approved change is made again as a new request.
NATIVE APPROVALS · RECORDED DECISIONS
Close the operational loop.
Return results to the originating task, route actionable findings to SecOps, and link decision evidence to the controls reviewed in IRM.
ITSM · SECOPS · IRM
Stop the agent, not the business.
Stop further governed calls from the selected agent while unrelated automation continues.
AGENT KILL SWITCH
Useful data. Protected fields.
Mask or redact protected fields from tool responses, so the agent can work with the information it is authorized to use.
CONTROLLED TOOL RESPONSES
Keep the engines you trust
Policy as code.
Authority by design.
Author, version and deploy business policy with the engines your teams already use.
Learn from activity. Not by granting permission.
Observed actions inform the draft.
Your team approves it.
Turn workflow activity into candidate rules. Review the intent, test in shadow mode, then promote an approved policy.
For builders: how the integration connects
Start with visibility. Add a decision at the workflow step or connected tool call. Each path declares the controls it can execute; mandatory policy is never silently dropped.
DISCOVER & OBSERVE · AFTER THE EVENT
Read the instance.
Read-only inventory and events establish the picture. Observing a denied action is not the same as blocking it before execution. Administrative containment is enabled separately.
GOVERN THE WORKFLOW · BEFORE THE STEP
Decide before the step.
The workflow check, a Flow Designer action, asks for a decision before the consequential operation. The flow continues on allow, waits on hold and does not execute the step on deny. A before-write rule on the record table is the backstop: a denied write is aborted before it commits.
GOVERN THE TOOL CALL · BEFORE DISPATCH
Control the connected action.
The governed API route checks requests from agents outside the instance before dispatch. Request and response controls are enabled against the integration’s declared capabilities.
Accountability without reconstruction
Not just “approved.”
What was allowed.
What actually happened.
Keep a trail from the ServiceNow record to the policy, human authorization and recorded result. Review the complete decision without piecing it together from separate queues.
Your policy. Your authority. Your record.Link supporting evidence to the controls your reviewers use. Preserve the record outside the review workflow without confusing evidence with an attestation.
Action evidenceHOLD
Change / taskINC0018427
RequestedClose one critical incident
PolicyService operations
Human authorityAwaiting incident commander
ExecutionNot dispatched · resolved · not closed
Decisiondec-sn-1042-e1
This record follows the scenario above. Synthetic fields; no cryptographic verification is performed in this demo.
Even on one platform
Even if every agent you run is in ServiceNow.
"Single platform" describes where your agents run. Governance is about what they do, who answers for it, and what you can prove. None of those stop at the instance boundary.
The consequences land outside the instance.
A Now Assist flow resolves the incident in ServiceNow; its spokes restart the service in your cloud, change access in your identity provider and credit the customer in billing. ACLs decide who may touch a record in the instance. Business limits are scoped to the case, the customer and the day, wherever the action lands.
You didn't choose multi-platform. Your vendors did.
The all-ServiceNow company still runs Salesforce, Microsoft 365 and a cloud, and each now ships its own agents: Agentforce, Copilot, Bedrock. They call into the instance through its APIs. The mixed estate is the state you are in, not a state to plan for.
A control the platform runs on itself is line one.
The admins who build the flows should not also hold the policy editor, the enforcer and the audit log. Risk and audit need a control that is independent of the system it controls. SOC 2, ISO 42001 and the NIST AI RMF all expect that separation.
The platform will change under you.
Now Assist and AI Agent Studio gain capabilities with every family release. Controls written as ACLs, scoped-app logic and skill settings for one release are revisited at the next. Intent written once, reviewed by Risk and enforced at the action boundary outlives the release.
Evidence has to survive the instance.
An instance log proves what the instance decided. An auditor wants the chain: business authority, policy version, approval, decision, dispatch and the result in the system of record. It has to outlive a retention rule, an instance rebuild and a change of vendor, and it has to tell allowed from executed.
"Governed" should be a number you can see.
AI Control Tower gives you an enterprise view of the AI that ServiceNow knows about, and it is a good one. Discovery that is independent of the instance adds the denominator: the agent on another platform, the flow step that bypasses the governed path, the SaaS agent nobody registered. It refuses to call an uninstrumented path governed.
One incident closure, end to end.
In this example, the closure rule is managed in GovernorAI and checked by the GovernorAI workflow check in your flow.
- ServiceNow In this example, the configured ACLs and scoped application let Now Assist update INC0018427.
- GovernorAI The GovernorAI workflow check applies the incident policy before the flow step runs. Closing a critical incident needs the incident manager, so the workflow check holds the closure.
- Owner The incident manager approves or rejects in ServiceNow.
- Record The record carries the policy and rule that decided and the outcome, independent of the instance.
And when you are not single-platform: one policy, one ledger, one evidence chain across ServiceNow, Salesforce, AWS, Azure, Google Cloud, Databricks, Kubernetes and MCP. See how one policy governs everywhere
Value on your first platform. Consistency everywhere else.
Start with ServiceNow.
Govern wherever the work goes.
Use the same policy lifecycle, business authority and evidence across clouds, SaaS, hybrid and on-premises systems. No second platform is required to start getting value.
AWSBedrock & agent workflows
Google CloudAgents, tools & data
Microsoft AzureAI & enterprise workflows
ONE GOVERNANCE OPERATING MODELGovernorAI
Your business policy.
Connected to the action.
ALLOWHOLDDENY
Native controls stay in place.
Business authority stays consistent.
Business authority stays consistent.
ServiceNow & SalesforceAgents inside SaaS
DatabricksData & model workflows
Custom, hybrid & on-premisesAny framework · APIs · MCP
Govern agents inside a platform, agents calling into it, and workflows that connect them.
A practical path to governed production
Start read-only.
Govern when you are ready.
Start with visibility, not disruption. Enable read-only discovery first; add governance to a selected workflow when its policy and operating criteria are ready.
1
Connect and understand.
Read the instance without enabling writes or action enforcement. Map the agents, their reach and the workflow you want to govern.
2
Review and test the boundaries.
Use observed activity to inform policy. Exercise approvals, denials, changed requests and failure paths before anything is promoted.
3
Govern, measure, expand.
Enable the chosen action control. Review actual decisions, execution outcomes and operating overhead before extending the rollout.
The practical questions
Built to work
alongside your stack.
We only use ServiceNow. Why add GovernorAI?
Because a single instance still contains consequential business actions. GovernorAI connects risk owners, release criteria, approval holds, exceptions and recorded outcomes in one repeatable process. The value starts with a workflow that never leaves ServiceNow; multi-platform consistency is an additional benefit.
ServiceNow already governs our AI. Why GovernorAI?
Keep ServiceNow's governance and IRM where they are; GovernorAI connects to them and feeds them. What GovernorAI adds is enforcement at the action boundary on every platform, including this one, the shared limits and approval holds that cross platforms, and an evidence chain that is independent of the instance.
Where do approvers decide?
Approvers are notified through the channels you configure, such as Slack, Teams, PagerDuty, email or a webhook, and decide in GovernorAI. The decision is recorded on that held request; it does not release the call, and re-running it is a new request. A policy approval, an action approval and a target update remain distinct events.
What happens when the agent changes its request?
A changed request is a new request, evaluated from scratch. An approval is recorded on one held request and carries over to no other, and restarting a session does not create one. Native permissions and explicit denials remain effective.
How do we start without disrupting production?
Start with read-only discovery for one instance. Agree the workflow and success criteria, exercise its approval, denial and failure paths, then enable the selected action control. Use the six-week design-partner evaluation to measure behavior, operating effort and evidence.
Can the same program extend beyond ServiceNow?
Yes. Carry the policy lifecycle, ownership and evidence across connected cloud, SaaS, custom and hybrid workflows. Use appropriate execution controls for each integration. Start where your work runs today; add other platforms when the business needs them.
Prove the value on one workflow
One instance.
One workflow.
A clear reason to move forward.
Bring a consequential workflow to a 30-minute briefing. Define the business policy, approving authority and success criteria for a focused six-week evaluation.
Continue
Govern EverywhereOne policy across your AI stack Runtime EnforcementDecide at the action boundary Evidence & ComplianceHash-chained audit record, mapped to controls Discovery & Shadow AIInventory the AI activity nobody registered Shadow AIUnmanaged agents and connections Destructive actionsChanges to systems of record