For ServiceNow · Now Assist AI Agents · AI Agent Fabric · ITSM, HR, CSM, Finance

Every Now Assist agent action,
independently judged before it executes.

Three agent actions below are shaped exactly as they leave the ServiceNow platform — a Flow action tool, a record write, an MCP tool call through AI Agent Fabric — and each one goes through the live Veridect system on this page. On your side the integration is a Flow action, a business rule, or a URL change. Behind it is the whole control plane: consensus from frontier models across independent vendors, deterministic policy classes, risk routing, a hash-chained ledger, and an Ed25519-signed decision record you can verify right here. And when a decision escalates, the serious-incident package lands back in ServiceNow as a standard incident record — live, on this page.

Open the full live tour
3 seams
a Flow action, a before business rule, or one MCP URL — your agents, flows and models stay exactly as they are
1 judgment
POST /pre-action — behind every path (the MCP gateway makes that call for you); the answer is a verdict plus a signed record
1 record back
an escalation returns to ServiceNow as a standard incident via the Table API every instance ships with — no GRC module required
0 trust required
every decision re-derives from its recorded inputs and verifies against a published key — try it below
Where it sits

Between the agent’s decision and the record write.

ServiceNow runs the agent: Now Assist AI Agents built in AI Agent Studio, orchestrated by the AI Agent Orchestrator, reaching tools and data through AI Agent Fabric and Workflow Data Fabric, inventoried and governed from AI Control Tower. Veridect sits at the one moment none of those were built to own: the instant before an action with consequences executes, when an independent judgment — not the model that proposed the action, not the platform that hosts it — decides whether it goes, waits for a person, or never happens, and signs the record either way. Then the record goes back to where your teams already work: an incident.

Your agent on ServiceNow

Proposes an action

  • Now Assist AI Agents using Flow action, Subflow or Script tools
  • Any flow or script that writes a record on the platform
  • Any MCP tool reached through AI Agent Fabric
Veridect · live control plane

Judges it before it runs

  • Deterministic scope check against the agent’s configured authority
  • Policy classes in code — money thresholds, protected data, regulated data, cumulative exposure
  • Multi-vendor model consensus with calibrated confidence and a dissent register
  • Risk routing: greenlight, escalate to a named human queue, or block
  • Hash-chained, Ed25519-signed record — written whether it passes or not
Outcome

Three doors, one record

greenlightthe tool runs or the record is written; the verdict and record id travel with it
escalateheld for a person in the queue the policy names — and an incident record opens in ServiceNow if you want it to
blocknever executes — and the refusal is on the ledger too
Three thin paths — and the way back

The integration is thin. The system behind it is not.

Each path maps the call your agent was already making onto one judgment — POST /api/ai/consensus/pre-action, made by your step, your rule, or the MCP gateway on your behalf: the verb, the target table, the fields, which agent is asking, and what that agent is authorized to do. Nothing about the agent, the model, or the tool changes. The verdict decides whether the original action proceeds — and the escalation comes back as a record your teams already know how to triage.

PATH 01 · AI AGENT STUDIO · FLOW ACTION TOOL

A pre-action step inside the tool itself

AI Agent Studio gives an agent its tools as Flow actions, Subflows and Scripts. Make the Veridect call the first step of the action: a script step asks Veridect, and anything other than a greenlight ends the action with the verdict and the record id in the tool’s output — the agent sees why, and so does the ledger.

~26 lines · Flow Designer script step · no change to the agent or its model

Fail-closed by construction: proceed starts false and becomes true only on a parsed greenlight — a non-200, a timeout, a thrown request or a malformed body all leave it false, and the work step runs only when it is true. The same call fits a Script tool (string inputs and outputs) or an IntegrationHub REST step. The endpoint and the key live on the REST Message record and its Credential alias, never in script.

// Flow action "Veridect pre-action" — step 1 of any tool an AI agent can call
(function execute(inputs, outputs) {
  outputs.proceed = false; outputs.verdict = 'unavailable'; outputs.record_id = '';   // closed until proven open
  var agentId = gs.getUserID();                          // the identity this action runs as (the agent's service account) — never an input the agent fills in
  var auth = new GlideRecord('x_veridect_agent_authority');   // your table: one row per agent identity, its authority in words
  if (!auth.get('agent_user', agentId)) { outputs.verdict = 'unknown_agent'; return; }   // no configured authority: never asked, never run
  var d = null;
  try {
    var r = new sn_ws.RESTMessageV2('Veridect', 'pre-action');   // REST Message record: endpoint + credential alias live there, not in code
    r.setHttpTimeout(60000);
    r.setRequestHeader('Content-Type', 'application/json');
    r.setRequestBody(JSON.stringify({
      action:            inputs.action,                  // e.g. "reassign_incident"
      target:            'servicenow:' + inputs.table,   // e.g. "servicenow:incident"
      parameters:        JSON.parse(inputs.parameters_json),   // a bad payload throws here — inside the fail-closed try
      callingAgent:      String(auth.getValue('agent_name')),
      callingAgentScope: String(auth.getValue('scope')),      // its configured authority, in words
      department:        String(auth.getValue('department'))
    }));
    var resp = r.execute();                            // synchronous — the step waits for the verdict
    if (resp.getStatusCode() === 200) d = JSON.parse(resp.getBody());
  } catch (e) { d = null; }                            // network, timeout, parse: all stay closed
  if (d && d.verdict) {
    outputs.verdict   = d.verdict;
    outputs.record_id = d.auditBundleId || '';
    outputs.proceed   = d.verdict === 'greenlight';   // step 2 (the work) runs only if true
  }
})(inputs, outputs);
PATH 02 · THE PLATFORM · BEFORE BUSINESS RULE

One business rule — no agent code at all

A before business rule on the tables your agents may write — incident, sc_req_item, sys_user, cmdb_ci — fires only for the identities your agents run as (put them in a marker group), asks Veridect, and aborts the write with setAbortAction unless the verdict is a greenlight. Every agent, every tool, every agent you add next quarter is covered at the data layer; people and ordinary integrations never wait.

~22 lines · one rule per governed table · humans untouched

Where the authority lives: the scope string is the agent’s configured authority, looked up by the identity the agent runs as — platform context, never an input the agent fills in. A read-only agent that proposes a record write is a categorical no-authority action — the deterministic layer blocks it before any model is asked to weigh in. Watch it below. The policy classes work over field names; send values only for the fields your policy needs.

// Before Business Rule · insert, update · on each governed table
// Condition: gs.getUser().isMemberOf('Veridect AI Agents')   ← marker group holding the identities your agents run as (a role would also match admins)
(function executeRule(current, previous) {
  var changed = {}, fields = current.getFields();
  for (var i = 0; i < fields.size(); i++) {
    var el = fields.get(i);
    if (el.changes()) changed[el.getName()] = String(el);
  }
  var d = null;
  try {
    d = new x_veridect.Gate().preAction({              // your Script Include around the same POST as Path 01
      action:            (current.isNewRecord() ? 'create_' : 'update_') + current.getTableName(),
      target:            'servicenow:' + current.getTableName(),
      parameters:        changed,
      callingAgent:      gs.getUserName(),              // the identity the agent runs as — platform context, not a field on the record
      callingAgentScope: new x_veridect.Gate().scopeFor(gs.getUserID()),   // looked up by the stable user sys_id in x_veridect_agent_authority; null → no verdict → abort
      department:        gs.getProperty('x_veridect.department')
    });
  } catch (e) { d = null; }                            // unreachable or malformed → treated as no verdict
  if (!d || d.verdict !== 'greenlight') {
    gs.addErrorMessage('Not written — Veridect ' + (d ? d.verdict + ' (record ' + d.auditBundleId + ')' : 'unavailable'));
    current.setAbortAction(true);                      // the write never happens; the refusal is on the ledger
  }
})(current, previous);
PATH 03 · AI AGENT FABRIC · MCP

One MCP URL in front of the tool server

ServiceNow AI Agents can be equipped with external tools over MCP through AI Agent Fabric. Register the tool server as a Veridect upstream once, then point the Fabric connection at Veridect instead. Every tools/call is judged in flight; tools/list, initialize and everything else pass straight through. A refused call is never forwarded.

0 lines of agent code · one registration, one URL

Identity on the wire: the agent’s identity, workflow id and business context ride in params._meta["veridect/…"] — unsigned, that is the caller’s own claim, and the decision record marks it as such; a tenant can require a signed Ed25519 identity envelope on every call, and an unsigned call is then refused inside the protocol. Both outcomes run live below.

# 1) once — register the tool server as an upstream (admin call)
POST /api/ai/consensus/mcp/upstreams/{tenant}
{ "upstreamId": "fabric-tools-prod",
  "url": "https://<your-tool-server>/mcp",
  "enabled": true }

# 2) the MCP connection AI Agent Fabric uses — before
MCP_URL = "https://<your-tool-server>/mcp"

# 2) the MCP connection AI Agent Fabric uses — after
MCP_URL = "https://<your-veridect-host>/api/mcp/gateway/fabric-tools-prod"
HEADERS = {
  "Authorization":            "Bearer <VERIDECT_API_KEY>",      # your Veridect tenant
  "X-Upstream-Authorization": "Bearer <tool-server token>",    # forwarded to the tool server as Authorization
}

# 3) what the agent sees on a greenlight: the upstream's own result, plus
#    result._meta["veridect/verdict"] and result._meta["veridect/bundleId"]
#    on escalate / block: a JSON-RPC error (-32003 / -32004) carrying the
#    verdict and the record id — and the tool server never receives the call.
THE WAY BACK · A SERVICENOW INCIDENT RECORD

The escalation lands where your teams already work

When a decision escalates or blocks, Veridect builds a serious-incident package in an Article-73-style structure — sanitized by construction: namespaced targets as SHA-256, pattern-gated tokens, no raw caller strings — and creates a standard incident record in your instance through the Table API every instance ships with. No GRC or IRM module is required, and nothing on the ServiceNow side is installed.

1 call · core incident table · package SHA-256 inside the record

Tamper-evident on arrival: the record carries the package’s own disclosure verbatim and a SHA-256 over the exact JSON transmitted, so later truncation or editing is detectable against the platform’s incident-payload API. Demonstrated end-to-end against a live ServiceNow instance below — demonstrated wiring, not a certified integration.

// what Veridect sends your instance — the Table API call every instance accepts
POST https://<your-instance>.service-now.com/api/now/table/incident
{
  "short_description": "[Veridect] AI serious-incident package — escalate decision qai-act-…",
  "description":  "<the package's disclosure, verbatim>
                   Decision bundle: qai-act-…  |  Verdict: escalate  |  Risk tier: high
                   Policy classes: dollar_threshold
                   Payload SHA-256: 9f3c…  — re-derive via the incident-payload API",
  "work_notes":   "veridect.incident-payload.v1 | sha256=9f3c…
                   { \"schema\": \"veridect.incident-payload.v1\", \"event\": {…}, \"trigger\": {…},
                     \"measures\": {…}, \"evidence\": {…}, \"verification\": {…} }",
  "urgency": "2", "impact": "2"
}

// the instance answers with the record it created — number and sys_id —
// and that is what Live 04 shows you below, straight from ServiceNow's reply.
Run it live

Five ServiceNow-shaped actions, through the live system, now.

Each card sends the exact request the Flow action, the business rule, or the Fabric MCP connection would send, to the live Veridect system on a shared sandbox tenant. The verdicts are real multi-model decisions made while you wait; the records are written to the ledger and signed; the Verify button re-derives the verdict from the recorded inputs and checks the signature against the published key. Live 04 then creates a real incident record in a ServiceNow instance from the escalation in Live 03. Expected outcomes are stated in advance — the engine decides.

Ready. Each decision takes a few seconds while the model roster deliberates.
LIVE 01 · PATH 01 · FLOW ACTION TOOL

Reassign an incident to the network team

A Now Assist incident-triage agent calls its reassign_incident tool on INC0012874 with a work note. Its configured authority: “may read incidents and may categorize, prioritize and reassign them to the correct assignment group.”

Expected: greenlight — inside authority, no policy class fires, the roster agrees. The Flow action’s proceed output is true, the work step runs, and the record id rides along.

Waiting. Request shape: the Flow action’s JSON, verbatim.
LIVE 02 · PATH 02 · BEFORE BUSINESS RULE

A read-only summarizer tries to resolve the incident

A Now Assist incident-summarization agent proposes an update_incident that sets INC0012874 to Resolved with a close code. Its configured authority: “read-only: may read incident records and knowledge articles to draft summaries.”

Expected: block — a read-only agent proposing a record write is a categorical no-authority action; the deterministic scope check decides, the models are consulted for the record, and the business rule aborts the write instead of letting it through.

Waiting. Request shape: the business rule’s JSON, mapped from the changed fields.
LIVE 03 · PATH 01 · FLOW ACTION TOOL

Release a $48,000 payment to an approved vendor

An accounts-payable agent, inside its authority (“may read invoices and may release payments to approved vendors”), calls release_vendor_payment for an amount above this tenant’s policy limit of $10,000.

Expected: escalate — the deterministic dollar_threshold policy class fires and routes the action to the senior-officer queue. Authorized but consequential actions escalate to a person; they are never silently blocked and never silently allowed. This is the record Live 04 sends to ServiceNow.

Waiting. Request shape: the Flow action’s JSON, verbatim.
LIVE 04 · THE WAY BACK · SERVICENOW INCIDENT

The escalation lands in ServiceNow as an incident, live

Veridect builds the serious-incident package for the Live 03 decision and creates a record in the core incident table of a live ServiceNow instance through the standard Table API. What you see is ServiceNow’s own reply: the incident number and sys_id it assigned.

Expected: one new incident record — number, instance host, the package’s SHA-256 as written into the record, and the disclosure it carries verbatim. Writes on this instance can take several seconds to half a minute; that latency is the instance’s, not the engine’s. If ServiceNow does not answer, the card says so — nothing is simulated.

Waiting on Live 03 — this card sends that decision’s package to the instance.
LIVE 05 · PATH 03 · AI AGENT FABRIC → MCP

The same tools/call, two tenants, two outcomes

A JSON-RPC tools/call for lookup_policy_limit goes through the live Veridect MCP gateway to a sample tool server that counts what it actually receives. First on the shared sandbox tenant; then on a tenant that requires a signed identity envelope, sent without one.

Expected: first call forwarded, the tool’s own hit counter goes up by one and the result carries _meta["veridect/bundleId"]; second call refused inside the protocol (-32004 identity_not_presented), counter unchanged, refusal on the ledger.

Waiting. Request shape: JSON-RPC 2.0, verbatim.

What on this page is live, and what is illustrative

Live: every verdict, confidence, dissent register, policy class, escalation route, ledger write, hash chain, Ed25519 signature, MCP forwarding decision and verification result above comes from the production Veridect system on a shared sandbox tenant — the same endpoints an integrator calls. The consensus roster is four frontier providers from independent vendors with a decisive-verdict early stop, so a decision on this surface typically records three; the models are named in each record’s dissent register. The $10,000 escalation limit is this sandbox tenant’s policy; in your tenant every threshold is yours.

Live, in a ServiceNow instance Veridect controls: the incident record in Live 04 is created in a developer instance through the standard Table API — the same call your instance would receive — and the number and sys_id shown are ServiceNow’s reply. One decision never produces two incidents: before creating anything the platform asks the instance whether a record for that decision already exists, and if so shows that one. The link opens for a user of that instance. In your deployment the target is your instance and your credentials; the integration is demonstrated wiring, not a certified or endorsed ServiceNow application. A daily allowance keeps visitors from filling the instance; when it is used up the card says so.

Illustrative: the agent side. No Now Assist agent, flow or business rule executes from this page; each card sends the exact request the Flow action, the business rule or the Fabric MCP connection would send, so what you watch is the decision those integrations would receive. The MCP calls in Live 05 leave this browser as a standard MCP client; an AI Agent Fabric connection from a ServiceNow instance was not exercised here. The code above is written against the documented Glide APIs (sn_ws.RESTMessageV2, setAbortAction) and the Flow Designer script-step contract; x_veridect.Gate is a Script Include you would write around the Path 01 call, and the tool-server URL is a placeholder for your own.

Verification proves that the enforcement decision re-derives from the recorded inputs and that the record is unmodified and signed by the published key. It does not re-run the models: the consensus summary is attested through the recorded dissent register and verifier-text hash, and disclosed as such in the proof itself.

ServiceNow, the ServiceNow logo, Now, Now Assist, Now Platform and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc. in the United States and/or other countries. Veridect is an independent company and is not affiliated with or endorsed by ServiceNow.

Five questions, answered for a ServiceNow team

The short version.

How does this help?

It lets Now Assist agents into the workflows that carry consequences — payments, access, employee and customer records, regulators — because an independent judgment stands in front of each action and a signed record stands behind it. The model that proposes the action is never the one that approves it, and the escalation arrives as an incident your teams already triage.

How do I integrate it?

One of the three paths above: a step in the Flow action, a before business rule, or one MCP URL in front of the tool server. Your agents, flows and models stay as they are. The way back is one Table API call your instance already accepts. It runs where you say, on your keys.

How long does it take?

The system is live today. A private sandbox on your own policy thresholds in a day once you say go; production typically about two weeks, with the pace set mostly on your side — security review, keys, access. Ours is ready on day one.

How does this make money?

Three levers, none of them invented here: revenue held back because agents could not be trusted with the consequential step; cost stopped on human review of actions a signed record now settles; losses not taken on the actions that should never have executed. Your own number comes out of the sandbox.

Why you and not a big well-known company?

Because the judgment has to be independent of the model and of the platform to be worth anything to an auditor. AI Control Tower is the platform’s own view of its agents; a platform grading its own agents is self-governance. Veridect is a separate control plane with its own ledger and keys, validated by an external red team on scope-violation semantics, and verifiable offline. Try to forge a record on the live tour; the engine refuses it.

Test-drive it yourself.

Run the five actions above, verify the records, open the incident, then take the full live tour — identity envelopes, delegation chains, cross-agent exposure, the fleet layer, and the forgery the engine refuses. Seven minutes, open access.

Prefer to see it on your own scenarios? Paste one on the pre-action console — or write to lrussell@veridect.ai and a scoped production sandbox on your own thresholds and your own instance follows in a day.

The same control plane, built the same way for Snowflake, Microsoft, AWS, CrowdStrike, Rubrik, Salesforce, Databricks, Okta and Google Cloud — one engine behind all ten pages, each run live. All ten platforms →