The outcome tool runs as whoever signed in

On September 10, 2026, ServiceNow published a community post announcing generally available MCP servers for ITSM, ITOM, CMDB, and SPM, with Claude, Copilot, and Gemini named as supported clients. The pitch is tools built around outcomes rather than raw table access. Ask for a change with the right configuration items and a workable window, and the server reads and validates and creates the record on the ServiceNow side, then hands back focused context instead of broad table results.

The line in the post we'd underline is a quieter one. ServiceNow says table and record access follows the authenticated user's permissions, that MCP does not bypass ACLs, and that requests run in the user's context through the same platform controls. That is the right design. It also means the agent inherits every piece of role debt in your instance, and the role review you keep postponing now decides what a Claude session can do to production.

Whose roles the agent inherits

Start with which identity sits behind the connection. In the demo it is the architect's own account, which usually carries admin or close to it. In a rollout, teams reach for a shared integration user because it removes per-person setup and keeps the credential in one place. Once that happens, the phrase authenticated user's permissions stops protecting anyone, because that user is a service account holding itil, itil_admin, and whatever else was added during an upgrade and never removed.

The post doesn't walk through setup or describe how a client such as Claude establishes which ServiceNow user it is acting as. That is the part we'd ask about first. We asked the same question about Claudeforce in August, when we found that connecting data is easier than governing actions, and the answer holds here. The platform can promise to honour the user's permissions. Who owns authentication and permissions in the connection is still a decision your team makes, and a shared account quietly makes it for you.

The form never opens, so client-side rules never fire

An outcome tool goes straight to the server. ServiceNow's post says domain logic, workflow steps, validations, and supported actions execute on the platform, and we take that at face value. What it cannot cover is the years of controls your instance enforces only in the browser. The UI policy that makes a field mandatory when priority is one, the client script that blocks a save when the CI is retired, the onChange that clears the assignment group when the category flips. None of that runs when a request arrives through an API, and an MCP tool is an API.

ACLs, data policies, and business rules are the server-side floor, and on most instances we've seen it is thinner than process owners believe. Look for any control that was added because a person kept doing the wrong thing in the form. If it lives in a client script, an agent working through the ITSM server will do the same wrong thing without ever seeing the warning. The fix is unglamorous. Move the rule to a data policy or a business rule, then test it through the REST API rather than the form, because that is the path the agent will take.

Speed is the selling point and the exposure

The post cites a Change Management benchmark that ServiceNow says showed 52 percent lower Claude-side cost, 72 percent faster execution, and about six and a half times fewer output tokens than direct Table API access. Those numbers are the whole argument for outcome tools over letting a model loop through what the post calls read-query-reason-retry against raw tables. The same efficiency removes the moments where someone could step in. Five form submissions give a reviewer five chances to notice. One outcome tool gives them one.

That is why the ordinary controls carry more weight here. Role scope decides how far one call can reach. The audit trail decides whether you can tell afterwards that a change to a production CI came through an MCP tool rather than a person in a form, and the post doesn't say how that attribution shows up in the activity stream. If your governance group has already worked out where runtime policy belongs when tools are called through an agent, this is the identity half of that conversation, and it belongs in the same review as the rest of your ServiceNow agent estate.

What to check before a team gets a token

Handle the first MCP server as a new integration user request, because that is what it is. Name the person or account each client authenticates as, and if it is an account, write down which roles it holds and why. Then run the ITSM and CMDB tools against a sub-production clone with a test user holding only itil and see what the outcome tools refuse. If nothing is refused, the role model is wider than you thought, and it was that wide before the agent arrived.

Then read your own exception list, because most instances carry a handful of users who were granted roles for a migration or an incident and never lost them. Those are the accounts an agent connection gets pointed at, because they already work. The pattern for giving access exceptions an owner and an expiry date was written for people and applies here without change. Take one question into your next platform review. Which account will the first Claude session in your instance sign in as, and would you hand that role set to a new starter on their first day?