Building an MCP-Exposed Action Without Opening a Security Hole

The generally available MCP Server is one of the most consequential things ServiceNow shipped this cycle, and it lands squarely on your desk, because the person who exposes an action through it owns the blast radius. MCP lets external agents (Claude, Copilot, a homegrown agent) call governed, headless actions inside ServiceNow. Done right, it turns the platform into safe, audited hands for whatever AI your organization prefers. Done carelessly, it is a remotely-callable backdoor into your system of record. Here is how to do the former.

What you are actually exposing. Through the MCP Server, an external agent can discover and invoke actions you have made available, supplying parameters, and ServiceNow executes them through its normal permission and audit machinery. "Headless" means no UI, no human in the loop at call time. "Governed" means the action still runs subject to ACLs and is logged. The value is precisely that combination: external reasoning, internal control. Your job is to make sure the "control" half is real.

Step one: enable MCP and A2A deliberately. Enabling the MCP Server (and the related agent-to-agent capabilities) is covered in ServiceNow's Zurich-era guidance, updated through Patch 4. Confirm you are on a release that supports it and turn it on as a conscious decision with an owner, not as a default someone flipped. Know who can register external agents against your instance.

Step two: expose one narrow action first. Resist the urge to expose a broad, powerful capability. Start with a single, well-bounded action with a clear, limited purpose. Define exactly what it can read or change. Every action you expose is a permission you are granting to an external party, so treat the list of exposed actions like a firewall rule set: default deny, open the minimum, justify each entry.

Step three: give the external agent a real, scoped identity. Do not authenticate external agents with a shared, over-privileged service account. Each external agent should authenticate as a first-class identity with least-privilege access scoped to exactly the actions it needs. This is what makes "let an external AI touch production" defensible: the agent can only reach the narrow surface you granted that specific identity, and you can revoke it independently. This connects directly to the machine-identity problem the platform now tools for; an agent is a privileged actor and should be governed like one.

Step four: log everything and actually read the logs. Exposing actions is not the end of the work; observing their use is. Confirm that every external invocation is captured: which identity, which action, what parameters, what result. Then review it. An audit trail nobody looks at is theater. Set alerts for unexpected volume or out-of-pattern calls.

Step five: test with the blast radius turned down. Validate against non-production or against reversible actions before you expose anything consequential. Walk through the full path: external agent authenticates, discovers the action, calls it, ServiceNow enforces ACLs, the action executes, the audit captures it. Confirm the agent can do only what you scoped and nothing adjacent.

The A2A accountability trap. Agent-to-agent chains, where an external agent calls a ServiceNow agent that calls an action that triggers another agent, are where accountability gets genuinely murky. When something goes wrong three hops deep, can you reconstruct who initiated what? Before you enable long A2A chains, make sure your logging lets you trace the full causal path. If you cannot answer "what started this," you are not ready to widen the surface.

Expand only as trust and observability hold. The teams that get burned by MCP are the ones that opened a broad action with a shared credential and no log review. The teams that win expose narrow actions to scoped identities and watch everything. Be the second kind.