AWS DevOps Agent talks to ServiceNow over MCP, reads incidents and writes findings back

AWS published a walkthrough on August 6, co-written with ServiceNow's MCP product lead, showing AWS DevOps Agent talking to ServiceNow over the Model Context Protocol. For on-call, the operational read is narrow and concrete: the incident record itself becomes the surface the agent reads from and writes to, and the engineer stops shuttling CloudWatch panels into a ServiceNow work note by hand.

How the wire is drawn

The agent is the MCP client. ServiceNow runs an MCP server that exposes its capabilities as discoverable tools. Authentication is OAuth 2.0. The post traces one end-to-end flow. A new ServiceNow incident triggers the agent. The agent discovers the ServiceNow tools it is authorized to call, queries incidents, changes and the CMDB for context, and correlates that with AWS telemetry the post names as CloudWatch, deployment data and code changes. It writes its findings into the incident and, where allowed, opens a change request through ServiceNow's Action Fabric. Two ServiceNow-side controls sit in the middle of this: the MCP Server Console governs which tools are exposed and which roles are masked, and the AI Control Tower observes and audits agent invocations. That governance surface belongs to the ITSM side, not to the agent.

Where the trust boundary now lives

Two things worth flagging before anyone treats this as a runbook. The AWS post does not label the integration preview or generally available, and it names no version. Read it as a reference architecture until AWS says otherwise. Second, once an agent can open change requests, the load-bearing configuration moves to ServiceNow: Action Fabric policies decide what the agent can actually do, and role masking on the MCP Server Console decides what it can see. Dynamic tool discovery resolves at call time, so a policy change on the ServiceNow side will change agent behaviour without any deploy on the AWS side. If you adopt this, the AI Control Tower log is not optional; it is the only after-the-fact record of what an autonomous actor did inside your ITSM.

A smaller point on the "open standard" framing. AWS presents MCP as an open protocol for agent-to-tool communication, and it is, but the walkthrough is single-vendor on both ends. The interesting test is a non-AWS agent hitting the same ServiceNow MCP server, or this agent hitting a non-ServiceNow ITSM. The post does not go there.