ServiceNow Action Fabric is a generally available MCP Server that lets any AI agent, whether it runs on Claude, Copilot, or a team's own stack, trigger ServiceNow flows, approvals, and catalog items over a standard protocol instead of a custom integration. Every action still routes through ServiceNow's AI Control Tower for identity verification, permission scoping, and an audit trail. The agent triggering the action no longer has to live inside ServiceNow to touch it.
That is a real shift for IT teams running ServiceNow as their system of record. Until this release, getting an outside AI agent to open a ticket, approve a request, or provision access meant a custom REST integration your team owned and maintained end to end. Now it is a supported protocol with a console for publishing and governing which tools get exposed. ServiceNow rolled this out at Knowledge 2026 alongside an expanded AI Control Tower built around five functions: discover, observe, govern, secure, and measure.
The convenience is real.
So is the exposure.
This post covers what actually changed in the MCP Server release, where the new attack surface sits, what AI Control Tower governs on its own versus what still needs your configuration, and the specific settings worth reviewing before you enable this for anything beyond a pilot.
Action Fabric is not a new product. It is ServiceNow's existing system of action, the flows, playbooks, approvals, and catalog items that already run your instance, exposed through a standard Model Context Protocol server instead of a proprietary API. The MCP Server is generally available now and included in every Now Assist and AI Native SKU. A separate MCP Server Console handles publishing, OAuth management, session tracking, and role-based tool packages, so an admin decides which actions an external agent can call rather than exposing the whole instance by default.
In practice this replaces a class of integration work IT teams used to build by hand. A custom bridge that let a chatbot open an incident record used to take a developer a few weeks to build and longer to maintain. Now it is a console setting, which is the appeal and also why the governance question moved from "can we build this safely" to "did we configure this safely."
Every credential an MCP client holds is a credential an attacker can steal, and MCP clients now include agents your security team did not provision and may not know exist. According to Gravitee's State of AI Agent Security 2026 Report, based on a survey of more than 900 executives and technical practitioners, 88% of enterprises had a confirmed or suspected AI agent security incident in the prior year.
In May 2026, Sysdig's Threat Research Team documented the first confirmed in-the-wild attack where an LLM agent, not a human operator, ran the post-exploitation phase of an intrusion. Starting from a Marimo remote code execution flaw (CVE-2026-39987), the agent harvested AWS credentials and exfiltrated a full PostgreSQL database in under 60 minutes with no human directing the individual steps. None of that ran through ServiceNow. The lesson still applies: an autonomous agent runs a multi-step attack chain as fast as its tool access allows, and the thing that stops it is scope, not intent.
AI Control Tower is the mechanism ServiceNow points to when it says every Action Fabric call is governed. It is real, but it covers five distinct functions, and only some of them do useful work without configuration on your side.
| Control Tower Function | What It Does Automatically | What IT Still Has to Configure |
|---|---|---|
| Discover | Finds AI assets across ServiceNow plus 30+ integrations, including AWS, Azure, GCP, SAP, Oracle, and Workday | Reconciling the discovered inventory against your own asset list; discovery is not a policy |
| Observe | Runtime visibility into agent reasoning and decisions, added through the Traceloop acquisition | Deciding which alerts route to a human and how quickly |
| Govern | Risk scoring across agents, models, datasets, and prompts | Setting the risk thresholds that trigger a block instead of a log entry |
| Secure | Identity and access governance extended to hyperscaler environments through Veza's access graph | Assigning least-privilege scopes in the first place; Secure enforces what you define, it does not define it for you |
| Measure | Cost tracking and ROI dashboards for AI spend | Setting an actual spend ceiling; the dashboard reports, it does not cap |
None of this means Action Fabric is unsafe to use. It means the default state after enabling it is broader access than most IT teams intend to grant on day one.
This is the same tiering logic we apply across every IT automation deployment: read-only actions run unattended, state-changing actions need admin enablement, and anything privileged needs explicit confirmation every time, a pattern we detail in our three-tier security model for IT automation. Action Fabric does not replace that model. It adds a new class of caller that has to fit inside it.
For a narrow use case, yes. If you already run an internal automation platform and want it to open ServiceNow catalog items or update incident records without a custom REST bridge, the MCP Server removes real integration work, and the governance layer, once configured correctly, beats most home-built bridges. Turning it on broadly before tool packages are scoped and SIEM export is wired up is a different decision, and it is the one we push back on in a client conversation. We covered a related question, when ServiceNow's own built-in Virtual Agent is not enough and a custom agent makes more sense, in ServiceNow Virtual Agent vs. Custom AI Agents. The same scoping discipline applies either way.
The protocol is new.
The governance mistakes are not.
It is ServiceNow's generally available MCP Server that lets external AI agents, including ones built on Claude or Copilot, trigger governed ServiceNow flows, approvals, and catalog actions instead of requiring a custom integration. Every call still routes through AI Control Tower for identity verification and audit logging.
No. The MCP Server itself is included in every Now Assist and AI Native SKU as of the 2026 release, with additional capability scheduled for the second half of 2026. The MCP Server Console, where you configure tool packages and OAuth settings, ships with the same entitlement.
Not through Action Fabric itself; every action routed through the MCP Server is identity-verified and logged by Control Tower by design. The real risk is a role-based tool package or OAuth grant configured too broadly, which lets a legitimately authenticated agent take actions nobody intended to authorize.
Virtual Agent is a conversational interface for end users inside the platform. Action Fabric runs the other direction: it lets agents that live outside ServiceNow, on any protocol supporting MCP or A2A, call into ServiceNow workflows. A team can use either, both, or neither depending on whether the agent doing the work is ServiceNow-native or built elsewhere.
For a specific, scoped use case, like letting an internal automation platform open catalog requests, yes; the integration savings are real and the governance layer is stronger than a hand-built bridge. Enabling it broadly before tool packages are scoped and audit logs are exported to your SIEM is where teams get burned, not the protocol itself.
We help IT teams scope AI agent access into ServiceNow before it goes live, from tool package boundaries to SIEM export. Bring your instance and your agent roadmap to the first call.
Talk to UsFree 2-minute assessment. Get an industry-specific score and action plan — no call required.