Salesforce and ServiceNow Govern Their Own Agents. Who Governs the Whole System?

Part of: Multi-Tenant AI Operations Reference — the full pillar covering scope hierarchy, per-tenant enforcement, multi-agent coordination, tenant lifecycle, and identity.

Part of: AI Agent Risk & Blast Radius Reference — the full pillar covering action authority, risk scoring, blast-radius containment, and degradation paths.

A batch of 200 overdue invoices hits the system on a Tuesday afternoon. Salesforce Agentforce picks up the cases and starts auto-generating follow-up emails. Simultaneously, the invoicing system raises incidents in ServiceNow, and Now Assist begins auto-reassigning them, posting updates to customer Slack channels, and triggering escalation workflows. By the time anyone notices, 200 customer emails have gone out from Salesforce, 200 Slack notifications have gone out from ServiceNow, and 15 incidents have been auto-escalated to the wrong team.

The Salesforce admin checks Einstein usage. Everything looks normal — the agent did what it was configured to do. The ServiceNow admin checks Now Assist logs. Same story. Each platform governed its own agents correctly. Nobody governed the aggregate.

This is becoming a natural failure mode of multi-platform agent deployments — and the risk grows as enterprises move Agentforce and Now Assist from pilot to production.

The Cross-Platform Blind Spot

Many large enterprises run both Salesforce and ServiceNow. Salesforce handles customer-facing CRM — sales, service, marketing. ServiceNow handles internal operations — IT service management, HR, facilities. Many also run custom AI agents built on LangChain, Spring AI, or internal tooling.

Each platform is shipping AI agents aggressively:

• Salesforce Agentforce — autonomous agents that handle sales outreach, case resolution, lead nurturing, and customer communications within the Salesforce ecosystem.
• ServiceNow Now Assist — AI agents that triage incidents, auto-resolve tickets, generate knowledge articles, and manage change requests within ServiceNow.
• Custom agents — LangChain, CrewAI, AutoGen, or bespoke agents that operate outside both platforms, calling APIs, querying databases, and interacting with third-party services.

Both platforms have invested substantially in AI governance. Salesforce offers the Einstein Trust Layer for content safety, Agentforce guardrails for topic classification, and the Agentforce Command Center for visibility and control across its ecosystem. ServiceNow provides AI Control Tower for centralized AI monitoring, Action Fabric for connecting third-party agents, and flow-level governance controls within the Now Platform.

This is not a claim that Salesforce and ServiceNow lack governance. Both offer substantial observability, analytics, and governance features within their own ecosystems — and both are expanding those capabilities aggressively. The gap is different: neither platform acts as a vendor-neutral, shared pre-execution control plane across Salesforce, ServiceNow, and custom runtimes simultaneously. Each governs its own agents. Nobody governs the aggregate.

Three questions that illustrate this gap:

1. "How much are we spending on AI across all platforms this quarter?" — The CFO asks this. The answer requires reconciling Salesforce Einstein usage reports, ServiceNow AI consumption logs, cloud provider invoices, and custom agent costs across different billing systems with different units and cadences. There is overlap, double-counting, and no way to attribute costs to business outcomes.

2. "Show me a complete log of all AI-initiated actions that modified customer data in the last 90 days, across all systems." — The SOC2 auditor asks this. The security team can pull Salesforce audit logs and ServiceNow sys_audit records separately. But neither captures AI-initiated actions specifically (vs. human-initiated), and there is no way to correlate activity across platforms into a single timeline.

3. "Can we prove that our AI agents cannot send more than N customer communications per hour, across all systems?" — The CISO asks this. Salesforce can limit Agentforce actions within Salesforce. ServiceNow can limit Now Assist actions within ServiceNow — and Action Fabric can connect third-party agents into ServiceNow's governance model. But no vendor-neutral shared pre-execution ledger enforces a combined limit across Salesforce, ServiceNow, and custom runtimes simultaneously. The Tuesday email storm was technically within each platform's individual limits.

Why a Neutral Governance Plane Is Needed

Both Salesforce and ServiceNow are expanding their AI governance capabilities — and those capabilities are real and valuable within each platform's ecosystem. Salesforce's Command Center gives Agentforce operators visibility and control. ServiceNow's AI Control Tower provides centralized monitoring. Action Fabric connects third-party agents into ServiceNow's governance model.

But each platform's governance is anchored to its own ecosystem. The structural challenge is not that these platforms lack governance — it is that cross-platform governance requires a neutral party.

Platform governance is platform-scoped. Salesforce's Agentforce Command Center monitors and controls Agentforce agents. It does not monitor Now Assist agents, LangChain agents, or custom agents running outside Salesforce. ServiceNow's AI Control Tower governs agents within the Now Platform. Action Fabric connects and controls third-party agents — but it brings them into ServiceNow's governance model, not into a vendor-neutral shared ledger. Even when a platform can connect to third-party agents, that is not the same as a neutral pre-execution authority enforced across Salesforce, ServiceNow, and custom runtimes simultaneously.

Shared limits require a shared ledger. If a Salesforce agent and a ServiceNow agent both handle the same customer interaction, enforcing a combined risk limit across both requires a single ledger that both platforms write to before acting. Neither platform provides this — and building it requires the kind of vendor-neutral protocol that neither platform is positioned to offer for the other's agents.

Neither can enforce pre-execution authority on the other. Salesforce cannot intercept a ServiceNow flow before it executes. ServiceNow cannot block an Agentforce action before it sends an email. The only entity that can sit between both platforms is a third party that both platforms call into before acting.

This is a familiar pattern. No single SaaS platform built cross-platform identity — Okta exists because cross-platform identity requires a neutral third party that every platform authenticates against. Cross-platform AI agent governance follows the same architectural logic: a neutral governance plane that every agent runtime calls before every consequential action.

Unified Governance: One Protocol, Every Platform

The Cycles protocol was designed for exactly this problem. A single Cycles tenant spans all platforms. The subject hierarchy maps naturally to enterprise organizational structure:

tenant:acme-corp                          → $50,000/month total AI budget
│                                         → 10,000 RISK_POINTS/day action limit
│
├─ app:salesforce                         → $20,000/month
│  ├─ workflow:case-triage                → $5,000/month
│  └─ workflow:lead-nurture               → $8,000/month
│
├─ app:servicenow                         → $15,000/month
│  ├─ workflow:incident-auto-resolve      → $7,000/month
│  └─ workflow:hr-onboarding              → $3,000/month
│
└─ app:custom-agents                      → $15,000/month
   └─ agent:knowledge-bot                 → $5,000/month

The tenant:acme-corp ledger acts as a shared reservation ceiling across connectors that submit this tenant scope. Even if individual app allocations sum to more than $50K, atomic reservations cannot collectively claim estimates beyond available tenant capacity. Actual external cost and settlement still depend on integration coverage, estimate quality, and overage policy. This uses the existing Cycles hierarchy; no protocol change is required.

Two governance dimensions

Budget authority (USD_MICROCENTS) controls how much submitted activity can spend across platforms. Calls are governed only when each connector routes them through the shared tenant ledger. Concurrent reservations from Salesforce and ServiceNow against that ledger are handled atomically by the Cycles server.

Caller-assigned action exposure (RISK_POINTS) lets both connectors account for the risk scores their applications assign. It does not replace platform permissions, tool allowlists, or argument validation. A single customer interaction spanning both platforms might be scored like this:

Platform	Action	Risk Points
Salesforce	Read case details	0
ServiceNow	Read related incidents	0
Salesforce	Update case status	5
ServiceNow	Reassign incident	10
Salesforce	Send customer email	50
ServiceNow	Post to Slack channel	20

The connectors can share an enforceable interaction budget by putting the same interaction identifier in a standard Subject field—for example, workflow: "case-4782". Keep dimensions.correlation_id as attribution metadata. The reference server does not derive budget scopes from dimensions, so a dimension alone cannot create the shared interaction budget. Reads and internal operations continue only if the application classifies and routes them through a different funded scope or deliberately leaves them outside this risk budget.

Dollar budgets bound submitted cost. RISK_POINTS bound a caller-defined measure of cumulative action exposure. A support agent that sends 200 customer emails can have low token cost and high reputational or operational consequence; the application assigns a score that reflects that distinction.

How agents connect: thin connectors, not platform lock-in

Connecting a platform to the Cycles governance plane requires a minimal connector — a thin HTTP wrapper that calls the Cycles API before and after agent actions. The connector complexity is comparable to integrating with any external REST API, which both platforms do routinely.

Salesforce: A minimal Apex connector would expose three static methods — reserve(), commit(), release() — making HTTP callouts to the Cycles server via a Named Credential. An Invocable Action wrapper would expose the same lifecycle to Flow Builder and Agentforce action definitions. No custom objects, no triggers, no scheduled jobs.

ServiceNow: A minimal Script Include connector would provide the same three methods — reserve(), commit(), release() — making REST calls via a Connection & Credential Alias. A Flow Designer action would expose the lifecycle to Now Assist workflows. No tables, no UI pages, no scheduled jobs.

In both cases, the connector stores no data in the platform — all state lives in the Cycles server. The connector can be added or removed with zero side effects. The argument "just build governance in Apex" or "just build it in ServiceNow scripting" applies to the connector itself. It does not apply to the cross-platform governance logic — atomic budget enforcement across concurrent agents on different platforms, hierarchical scope enforcement, idempotent commit/release with automatic expiry. Building that correctly requires exactly what the Cycles server already provides.

How this works in practice

Scenario 1: The CISO needs a kill switch

A batch processing error triggers AI agents on both platforms simultaneously. Salesforce Agentforce starts auto-sending follow-up emails. ServiceNow Now Assist starts posting updates to customer Slack channels.

With a shared RISK_POINTS budget of 500 per hour at the tenant level — where email.send costs 50 points and slack.notify costs 20 points — the cascade is contained. After 8 emails (400 points) and 5 Slack notifications (100 points), the budget is exhausted. The 9th email attempt from the Salesforce connector:

// POST /v1/reservations
{
  "idempotency_key": "sf-email-009",
  "subject": {
    "tenant": "acme-corp",
    "app": "salesforce",
    "agent": "agentforce-case-bot",
    "toolset": "customer-email"
  },
  "action": { "kind": "tool.email", "name": "send-follow-up" },
  "estimate": { "unit": "RISK_POINTS", "amount": 50 }
}

// 409 Conflict
{
  "error": "BUDGET_EXCEEDED",
  "message": "Insufficient risk-point budget at scope tenant:acme-corp",
  "request_id": "req_7x9f..."
}

The reservation is rejected before the email function executes. The next submitted Slack-notification reservation against the same exhausted ledger returns 409 BUDGET_EXCEEDED. Internal reads, note-taking, and status updates continue only if platform authorization permits them and their configured Subjects do not require the exhausted ledger.

The Cycles reservation ledger records every governed action — every attempt, every allow, every deny — with timestamps, platform origin, agent identity, and risk points consumed.

If the CISO needs to halt all AI agent activity immediately — not wait for a budget to drain, but stop everything now — the Cycles Admin API supports a tenant-level kill switch:

PATCH /v1/admin/tenants/acme-corp
{ "status": "SUSPENDED" }

A suspended tenant blocks all operations at the authentication layer. Every subsequent request from any connector — Salesforce, ServiceNow, custom agents — returns 401 UNAUTHORIZED with reason TENANT_SUSPENDED before any reservation logic runs. No agent code changes. No platform logins. One API call, universal stop.

When the incident is resolved, reactivate with { "status": "ACTIVE" } and agents resume normally. The suspension is reversible; closure (CLOSED) is not.

Scenario 2: The CFO wants a single number

The quarterly AI spend review. Instead of reconciling billing systems across multiple providers:

GET /v1/balances?tenant=acme-corp

Returns budget state across the standard scopes populated by the connectors. Drill down by app to see per-platform spend or by the standard field chosen for an enforceable process/run boundary. For business-outcome attribution, export reservation or event records and group their dimensions.correlation_id metadata in downstream analytics. Dimensions are useful attribution fields, but they are not balance-query scopes in the reference server.

Scenario 3: The auditor asks for logs

SOC2 Type II audit. The auditor requests a complete log of all AI-initiated actions that modified customer data in the last 90 days, across all systems.

The Cycles reservation ledger contains the budget lifecycle for actions routed through the reserve-commit boundary. A reservation query returns those lifecycle records:

GET /v1/reservations?tenant=acme-corp&status=COMMITTED

Each entry includes the budget-lifecycle context submitted to Cycles:

{
  "reservations": [
    {
      "reservation_id": "res_8f3a...",
      "status": "COMMITTED",
      "subject": {
        "tenant": "acme-corp",
        "app": "salesforce",
        "workflow": "case-4782",
        "agent": "agentforce-case-bot",
        "toolset": "customer-email",
        "dimensions": {
          "platform": "salesforce",
          "correlation_id": "CASE-4782"
        }
      },
      "action": { "kind": "tool.email", "name": "send-customer-reply" },
      "reserved": { "unit": "RISK_POINTS", "amount": 50 },
      "created_at_ms": 1743091200000,
      "affected_scopes": [
        "tenant:acme-corp",
        "tenant:acme-corp/app:salesforce",
        "tenant:acme-corp/app:salesforce/workflow:case-4782",
        "tenant:acme-corp/app:salesforce/workflow:case-4782/agent:agentforce-case-bot",
        "tenant:acme-corp/app:salesforce/workflow:case-4782/agent:agentforce-case-bot/toolset:customer-email"
      ]
    }
  ],
  "has_more": true,
  "next_cursor": "eyJ..."
}

Action kind, agent identity, timestamp, platform origin, correlation ID, and risk points can be correlated across those records. Paginate with cursor for the retained reservation history. A complete SOC 2 evidence set must also retain application authorization, tool arguments, external side-effect outcomes, identity decisions, and non-persisting preflight responses. The lifecycle ledger is an enforcement record, not a replacement for those application logs. For the compliance model behind this, see AI Agent Governance: Runtime Enforcement for Security, Cost, and Compliance.

Protocol, Not Platform

The governance plane is the Cycles server — the same open protocol that already integrates with LangChain, Vercel AI SDK, Spring Boot, and MCP-based agents. Adding Salesforce and ServiceNow connectors would extend the same reserve-commit lifecycle to two more platforms. The protocol does not change. The server does not change. The governance model does not change.

Cross-platform attribution can carry dimensions.platform and dimensions.correlation_id on the Cycles Subject, but the application or downstream event store must use that metadata to build a correlated timeline. For enforcement, both connectors put the shared case identifier in a standard field such as workflow. When a Salesforce case triggers a ServiceNow incident, both connectors therefore submit the same enforceable workflow scope and the same correlation metadata.

A Salesforce reserve and a ServiceNow reserve against the same tenant look identical at the protocol level:

// From Salesforce Agentforce — send customer email
{
  "subject": {
    "tenant": "acme-corp",
    "app": "salesforce",
    "workflow": "case-4782",
    "agent": "agentforce-case-bot",
    "toolset": "customer-email",
    "dimensions": {
      "platform": "salesforce",
      "correlation_id": "CASE-4782"
    }
  },
  "action": { "kind": "tool.email", "name": "send-customer-reply" },
  "estimate": { "unit": "RISK_POINTS", "amount": 50 }
}

// From ServiceNow Now Assist — post Slack notification
{
  "subject": {
    "tenant": "acme-corp",
    "app": "servicenow",
    "workflow": "case-4782",
    "agent": "now-assist-incident",
    "toolset": "customer-notifications",
    "dimensions": {
      "platform": "servicenow",
      "correlation_id": "CASE-4782"
    }
  },
  "action": { "kind": "tool.slack", "name": "post-customer-channel" },
  "estimate": { "unit": "RISK_POINTS", "amount": 20 }
}

Both hit the same tenant budget. Both consume from the same risk-point pool. Both are governed by the same hierarchical scope enforcement. The Cycles server does not need to know anything about Salesforce or ServiceNow — it sees subjects, actions, and amounts. The platform-specific logic lives entirely in the thin connectors.

Why Now

Three forces are converging:

Agentforce and Now Assist are scaling to production. Salesforce shipped Agentforce GA in October 2024. ServiceNow introduced Now Assist AI Agents as part of the Yokohama release in early 2025. Enterprises that piloted these capabilities throughout 2025 are now deploying them to production at scale. The cross-platform governance gap becomes real the moment a customer interaction triggers agents on both platforms simultaneously — a pattern that becomes increasingly likely as workflows span both systems.

AI governance expectations are rising across compliance frameworks. Organizations are mapping AI agent activity into existing SOC 2 and ISO 27001 control programs, while newer AI-focused frameworks like NIST AI RMF and ISO/IEC 42001 increase expectations around governance, traceability, and risk management. The question "show me your AI audit trail" is appearing more frequently in audits — and a cross-platform audit trail that covers Salesforce, ServiceNow, and custom agents in a single ledger is significantly harder to produce than a platform-specific one.

AI spend is crossing the visibility threshold. As enterprises scale from pilot to production, AI spend that was acceptable during experimentation becomes a line item the CFO scrutinizes. The first question is always "can we see this by platform and by business process?" Without a unified governance plane, the answer requires manual reconciliation across multiple billing systems.

A common trigger is simple: an enterprise deploys Agentforce to production and discovers that a customer support interaction kicked off agents on both platforms, with no coordination, no shared limit, and no unified audit trail. The first cross-platform incident creates the urgency.

Getting Started

1. See what cross-platform governance looks like. The 60-second demo shows budget enforcement stopping a runaway agent in real time. The same mechanism works across platforms — one budget, multiple agents, shared enforcement.

2. Understand the action authority model. The action authority demo walks through a support agent where internal actions proceed but the customer email is blocked. Cross-platform action authority is the same pattern applied to agents on Salesforce, ServiceNow, and custom frameworks simultaneously.

3. Run the Cycles server. The Docker quickstart stands up the full stack — Redis, Cycles server, admin API — in one command. From there, adding platform connectors is a matter of pointing HTTP callouts at the server.

4. Read the protocol. The reserve-commit lifecycle is the same for every integration — Python, TypeScript, Java, and MCP. If you've used any Cycles integration, the cross-platform model is the same protocol with a shared tenant. Salesforce and ServiceNow connectors follow the same pattern.

Further Reading

• AI Agent Governance: Runtime Enforcement for Security, Cost, and Compliance — the three-pillar governance framework
• Action Authority: Controlling What Agents Do — RISK_POINTS and toolset-scoped budgets
• AI Agent Action Authority: Blocking a Customer Email Before Execution — step-by-step demo walkthrough
• What Is Runtime Authority for AI Agents? — the foundational concept
• Multi-Agent Budget Control — shared budgets across multiple agent frameworks

Related how-to guides

• Assigning RISK_POINTS to agent tools
• Multi-agent shared budgets
• Budget control for LangChain