Give your AI agent a safe key to ServiceNow

The hard part of putting an AI agent on top of ServiceNow was never the model. It's the access. ServiceNow holds the incidents, the CMDB, the change requests — the exact context that would make an agent useful — behind an enterprise permission model that exists for good reasons. The question isn't whether GPT or Claude can write a decent incident summary. It's how you let a language model read incident records without handing it your admin credentials.

The Model Context Protocol is what makes this tractable. MCP gives you a standard way to expose specific ServiceNow operations — "search incidents for this group," "read this change request," "post a work note" — as discrete tools an agent can call, each with its own schema and its own boundaries. The agent never touches ServiceNow directly. It calls a tool, and the tool decides what's allowed. This guide covers how to wire that up without loosening anything you'd have to defend in a security review.

Start with the Table API, not the agent

Almost everything in ServiceNow is reachable through one REST surface: the Table API. A GET against /api/now/table/{table} with an encoded query returns records from any table your credentials can see. An incident lookup is a single call.

GET /api/now/table/incident
  ?sysparm_query=active=true^assignment_group=Network
  &sysparm_fields=number,short_description,priority,state
  &sysparm_limit=5
Authorization: Bearer <server-side token>

That endpoint is the foundation. Wrapping it well — rather than exposing it raw — is the entire job.

Wrap each operation as its own MCP tool

The instinct to build one do-everything servicenow_query tool is the instinct to resist. A single tool that accepts an arbitrary table and query hands the agent the whole instance and pushes every guardrail into prompt text, which is no guardrail at all. Define narrow tools instead, each mapped to one job:

• search_incidents(query, assignment_group, limit) — read-only
• get_incident(number) — read-only
• add_work_note(number, note) — write, guarded

Narrow tools are easier for the model to call correctly, easier for you to secure, and far easier to read back in an audit log. On OBTO an MCP tool is a record you create at runtime — a name, an input schema, and a handler — not a binary you redeploy, so you can ship search_incidents today and add add_work_note next week without taking the server down. Tools are data. It's the same pattern from our guide to building an MCP tool.

Keep the credentials server-side, always

The agent should never see a ServiceNow secret. The tool handler authenticates — ideally as a dedicated integration account scoped to exactly the tables and operations the tools need — and the credential lives in server configuration the model can't read.

// add_work_note handler (sketch)
async function addWorkNote({ number, note }) {
  const sysId = await resolveIncident(number);        // read first
  return snFetch(`/api/now/table/incident/${sysId}`, {
    method: "PATCH",
    body: { work_notes: note },                        // only this field
    auth: server.config.SN_INTEGRATION_TOKEN          // never in context
  });
}

The least-privilege account is doing the real security work. If add_work_note should only ever add a work note to an incident, the integration user's roles should make anything else impossible at the ServiceNow layer — not merely discouraged in a prompt. The tool narrows the surface; the account narrows it again.

Make writes deliberate

Reads are cheap to get wrong: an agent that pulls the wrong incident wastes a few tokens. Writes are not. A work note posts to a ticket a human will read; a state change can trip an SLA. Treat write tools as their own class. Expose reads first, get the agent genuinely useful, then add writes with explicit guardrails — validate the input against the record's current state, keep the operation idempotent where you can, and have the agent confirm the target record before it mutates anything. Ticket triage is the canonical case of getting this balance right, which we walk through in AI ticket triage.

See every call — the part teams skip

The first time an agent posts a wrong work note to a customer's incident, "the AI did it" is not an answer your change board will accept. You need a record of which tool ran, with which arguments, against which record, and what ServiceNow returned. On a system of record that isn't a nice-to-have; it's the line between an agent you can run in production and a demo you can't ship.

This is what OBTO's Glass Receipt gives you by default — every tool call leaves a per-step ledger you can query in real time:

{
  "run_id": "run_2f91",
  "tool": "add_work_note",
  "args": { "number": "INC0012345", "note": "Triaged: routed to Network." },
  "servicenow": { "table": "incident", "sys_id": "9d3...", "status": 200 },
  "actor": "agent:triage-bot",
  "ts": "2026-06-18T14:22:09Z"
}

Observability and trust are the same plumbing here — a point we make at length in our agent observability guide.

Where this runs

By default OBTO hosts the MCP server for you: managed cloud, no infrastructure to stand up. You bring the model and the client — Claude, GPT, Cursor, or your own agent — and point them at the endpoint. If your security posture requires ServiceNow integrations to stay inside your perimeter, the same setup self-hosts on your own Kubernetes at the Enterprise tier. The tools, the credential handling, and the Glass Receipt are identical either way; what changes is whose network it runs in.

That's the whole connection: ServiceNow's Table API, wrapped as narrow MCP tools, authenticated by a least-privilege account, with every call on the record. Describe the tools, ship them, and own the audit trail. When you're ready, the getting-started guide walks through your first tool, and pricing starts free on the Builder tier.

Frequently asked questions

How do I connect ServiceNow to an AI agent?

Expose ServiceNow operations through the Model Context Protocol. Wrap specific Table API calls — search incidents, read a change request, post a work note — as narrow MCP tools the agent can call. The agent never touches ServiceNow directly; each tool authenticates server-side and enforces its own limits.

Is it safe to give an AI agent access to ServiceNow?

Yes, if access goes through narrow MCP tools backed by a dedicated, least-privilege integration account. The agent only sees the tools you define, credentials stay in server configuration the model can't read, and write operations are guarded separately from reads.

What is a ServiceNow MCP server?

It's a server that exposes ServiceNow operations as MCP tools, mediating between an AI agent and the ServiceNow REST Table API. Any MCP-speaking client — Claude, GPT, Cursor — can then call a defined set of ServiceNow actions, with access control and auditing in between.

Do I need to give the AI my ServiceNow admin credentials?

No. The agent should never receive a ServiceNow credential. The tool handler authenticates with a dedicated integration account scoped to only the tables and operations the tools need, and the secret lives server-side where the model can't reach it.

Can an AI agent update ServiceNow tickets, not just read them?

Yes, but treat writes as a separate, guarded class of tool. Expose read tools first to make the agent useful, then add write tools — like posting a work note — with input validation, idempotency, and an audit record of every call against every ticket.