Your ServiceNow agent reads tickets written by strangers.
An ITSM agent reads incident descriptions, portal submissions, email-to-ticket bodies, work notes from contractors. Nearly every word of its primary input was written by someone you don't control — sometimes anyone on the internet with your support address. In security terms, a ticket queue is a feed of untrusted content, and your agent's job is to swallow it.
That would be fine if reading were all the agent did. It isn't. The same agent that reads tickets can usually look up users, query the CMDB, and post comments or notify people. That combination has a name. Simon Willison calls it the lethal trifecta: private data, untrusted content, and an outbound channel in one session. Hold all three and a single poisoned message can steer the agent into leaking data, with no software vulnerability anywhere. In 2025, researchers showed a single malicious public GitHub issue could push an agent into exfiltrating private repositories; variants were still working in 2026. A ticket queue is the same attack surface wearing a service-desk badge — the injection just arrives with an incident number.
So this guide is about the real problem: putting an agent on the system that holds your CMDB and your entire workforce's requests, fed by text from strangers, in a way you can defend in a security review.
ServiceNow ships its own MCP server now. Use it for what it's good at.
Since late 2025, ServiceNow has offered an MCP Server Console: a control plane where admins publish platform capabilities as MCP tools, register AI clients, and control access, with the tool surface expanding from Now Assist Skills to full platform action. ServiceNow has explicitly opened its system of action to outside agents — Claude, Copilot, or your own. If your agents live inside the ServiceNow ecosystem, that console is real governance and you should use it.
Notice what it governs, though: what an agent may do inside ServiceNow. Two hard problems sit outside that boundary.
First, the console can't make ticket text trustworthy. No admin setting turns an inbound incident description into safe input. If your agent reads tickets while holding broad read access and any outbound tool, the trifecta is assembled, with every individual permission correctly configured.
Second, your agent's run doesn't stay inside ServiceNow. A real triage run reads the ticket, checks a runbook in GitHub, posts to Slack, maybe queries a database. ServiceNow's console sees one silo; GitHub's controls see another; the attack lives in the seams. A poisoned ticket read in ServiceNow can exfiltrate through Slack, and neither vendor's dashboard will ever show you the whole story.
The pattern that survives contact
1. Narrow tools per task, not platform access per agent
"Full platform action" is a capability, not a starting point. Define the two or three verbs each task needs and expose nothing else:
search_incidents(query, assignment_group, limit)— read-onlyget_incident(number)— read-onlyadd_work_note(number, note)— write, guarded
Small tool lists are a security control and a reliability control at once. Published measurements of large MCP deployments show tool definitions alone consuming half a context window before the first user message, and wrong-tool calls climbing with catalog size. An agent with three verbs picks the right one; an agent with ninety has options you'll regret. On OBTO a tool is a record you create at runtime, so shipping search_incidents today and add_work_note next week is a data change, not a redeploy — the pattern from our guide to building an MCP tool.
2. Break the trifecta per session
This is the step most setups skip, and it's the one that answers the poisoned ticket. Decide, per task, which legs the agent holds. A session that reads inbound tickets gets no sensitive reads beyond what triage needs and no free-form outbound channel; its only write is a work note on the ticket it's triaging. A session that queries the CMDB or user tables doesn't read raw inbound text in the same run. You are not trying to detect injections — injected instructions have no reliable signature. You're making the session shape such that following one can't reach anything worth stealing.
3. Credentials server-side, least-privilege account underneath
The agent never sees a ServiceNow secret. The tool handler authenticates as a dedicated integration account scoped to exactly the tables and operations the tools need:
// 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
});
}If add_work_note should only ever add a work note, the account'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.
4. Writes are deliberate, and every call leaves a receipt
A work note posts to a ticket a human will read; a state change can trip an SLA. Writes get input validation, idempotency, and — for anything irreversible — a human in the loop, enforced by a server-side policy rather than a request in the prompt. And every call, allowed or refused, lands on a ledger:
{
"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-07-24T14:22:09Z"
}The GitHub exfiltration that opened this class of attacks was discovered by researchers, not victims — without a per-run record, a leak looks like a normal afternoon. On a system of record, "the AI did it" is not an answer your change board will accept; the receipt is. We go deeper in the agent observability guide and AI ticket triage.
Where OBTO fits
OBTO sits above the silos, at the level of the run. Wrap ServiceNow's MCP tools or the Table API directly; either way the agent's calls pass through a policy you control — allow, refuse, require-a-human, per verb — and every call across ServiceNow, GitHub, Slack, and the rest lands on one Glass Receipt. Cross-system rules like "sessions that read inbound tickets can't post outside the ticket" become configuration, not hope. By default OBTO hosts this for you; if your posture requires ServiceNow integrations inside your perimeter, the same setup self-hosts on your Kubernetes at the Enterprise tier. Same pattern as connecting GitHub to an agent, where the strangers write public issues instead of tickets.
The question to ask before your ITSM agent goes live isn't "can it summarize an incident?" It's the one the trifecta forces: when a hostile ticket arrives — and one will — what can the session that reads it actually reach? Make that answer short. The getting-started guide walks through your first tool, and pricing starts free on the Builder tier.
Frequently asked questions
Does ServiceNow have an official MCP server?
Yes. ServiceNow ships an MCP Server Console — a control plane where administrators publish platform capabilities as MCP tools, register AI clients, and control access — and has opened its platform to external agents built with Claude, Copilot, or custom frameworks. It governs what agents can do inside ServiceNow; you still need a plan for what the same agent does across your other systems.
How do I connect ServiceNow to an AI agent?
Use ServiceNow's MCP Server Console or wrap specific Table API calls as narrow MCP tools — search incidents, read a change request, post a work note. Either way, keep the tool list small per task, authenticate server-side with a least-privilege integration account, and treat every ticket's text as untrusted input when deciding what else that agent session can reach.
Can an AI agent be prompt-injected through a ServiceNow ticket?
Yes. Incident descriptions, portal submissions, and email-to-ticket bodies are authored by whoever submits them, which makes them untrusted content. Researchers demonstrated this class of attack against GitHub in 2025, where a public issue steered an agent into leaking private data, and a ticket queue has the same shape. An agent that reads tickets while holding broad data access and an outbound channel can be steered the same way.
Is it safe to give an AI agent access to ServiceNow?
Yes, with structure. Give the agent narrow tools per task rather than broad platform access, back them with a least-privilege integration account, keep credentials server-side, and separate ticket-reading sessions from sessions that hold sensitive reads or outbound channels. Enforce the split with a server-side policy, not prompt instructions.
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, then add writes — like posting a work note — with input validation, idempotency, human approval on state changes that trip SLAs, and an audit record of every call against every ticket.