Securing ServiceNow and Moveworks Native Agents

Moveworks security starts from an uncomfortable fact: an ITSM agent exists to close tickets faster, and closing a ticket usually means executing a privileged action. A password reset. A group membership change. A software entitlement grant. An account unlock. None of those are read operations. They are write operations against your identity and access systems, and they run under whichever service account the agent was provisioned with.

That design choice defines the agent's blast radius. The blast radius is not the data the agent reads. It is the set of actions the agent can execute. A helpdesk agent that can reset any employee's password is functionally a domain admin every time it is invoked, even when the person invoking it is a contractor on their second day.

Standard IAM controls check the human's permissions at the moment of the request. They do not check what the agent does next on that human's behalf. This is action chaining. The user takes an action by asking the agent. The agent takes an action by calling the fulfillment API. The downstream system trusts the agent's token and never revalidates whether the original invoker had the right to trigger that change. An over-permissioned agent turns into a machine insider the moment someone points it at a target it was never meant to touch, and industry estimates put roughly 90% of agents in the over-permissioned category.

The takeaway: securing an ITSM agent means governing the action layer, not just the authentication event.

Both platforms embed AI into ITSM workflows, but they sit on different surfaces and expose different controls. Understanding the split matters before you design anything.

Now Assist operates inside the ServiceNow platform. It summarizes tickets, drafts responses, and triggers Flow Designer actions, and its permissions inherit from ServiceNow roles and ACLs. The governance surface is native: role-scoped skills, audit tables within the Now Platform, and admin controls over which skills are enabled per instance. Confirm current capability names against ServiceNow documentation before you write them into internal policy.

Moveworks operates as an overlay. It connects to ServiceNow, Okta, Active Directory, chat tools, and other systems through its own integration layer, and its permissions come from the service accounts and OAuth grants configured during setup. That reach is the point of the product and also the reason a single conversation can fan out across identity, HRIS, and ticketing at once.

The security implication is not that one is safer than the other. It is that neither surface, on its own, tells you what an agent did on whose behalf across every system it touched. If your risk is contained inside ServiceNow, the native controls are a reasonable starting point. If a single agent reaches identity, HR data, and code repositories from one chat window, you need a view that spans all of them.

The first question most security teams cannot answer is simple: how many agents and workflows are running right now? Not how many were sanctioned. How many exist.

Native discovery is fragmented. ServiceNow admins can list Now Assist skills per instance. Moveworks admins can list configured workflows in the admin console. Neither view surfaces the shadow workflows built by business users, the orphaned agents whose creator has left the company, or the connectors that quietly bind the two platforms together.

Discovery has to produce the actual inventory: every agent, every workflow, every connector attached to it, and every account it authenticates as. Without that inventory, moveworks security is a theory. You are chasing ghosts across two consoles.

A practical discovery pass covers five things:

1. Export every configured workflow and skill from both admin consoles.
2. Identify the service account each agent authenticates with, then audit that account's ServiceNow role assignments.
3. Map the OAuth grants and API tokens issued to Moveworks, and record their scopes.
4. Correlate creators and owners against your HRIS to find agents whose owners are disabled.
5. Flag any agent configured as org-wide accessible or wired to a shadow application.

This is squarely inside what discovery and governance can deliver against these platforms today. It is also the foundation everything else stands on. You cannot govern an inventory you do not have.

The gap between theoretical configuration and effective access is where privilege escalation actually happens. The configuration says the agent holds a "ServiceNow user role." Effective access says the agent can execute the "Reset User Password" catalog item, which chains into Active Directory and rewrites a user's credential. Those are two very different statements, and only the second one describes real risk.

This is the moat, and it is worth stating plainly. The useful signal is not the vendor's settings page. It is the correlation between an agent's activity and its effective access inside the connected app: which service account it acts as, which tables and objects it can write, and which actions it can fire. A settings page tells you what someone intended. Effective access tells you what will happen when the agent runs.

For Moveworks specifically, this matters because workflows often connect to several identity systems at once. A single "unlock my account" conversation can trigger changes in Active Directory, Okta, and ServiceNow in sequence, each under a different grant.

The action categories worth inventorying fall into four buckets:

• Provisioning: create user, add to group, grant application access, issue a license.
• Access changes: reset password, unlock account, extend a session, elevate a role.
• Data changes: modify user attributes, update HR records, alter incident state.
• Fulfillment: approve a request, close a ticket, post to an internal channel.

The right question is not "does the agent have access to this action?" It is "given who is invoking this agent right now, should this action be allowed?" That correlation between the runner's identity and the agent's effective access is the runtime truth security teams are missing, and it is what turns a data-level review into an action-level one.

Individual risk factors on an ITSM agent often rate as medium. Stacked on a single agent, they become critical. A toxic combination is exactly that: several risk factors on one agent, arranged so that misuse or compromise produces disproportionate blast radius.

A few combinations show up repeatedly in ServiceNow and Moveworks environments:

• Shadow agent plus password-reset scope. An unmanaged workflow that can rotate any employee credential.
• Org-wide access plus a privileged service account. Any user can invoke fulfillment actions the service account holds.
• Orphaned owner plus an external connector. An agent whose creator is disabled still ships data to a third-party system.
• Maker-mode credentials plus HR data read. The agent borrows its creator's admin rights and exposes PII to any invoker.
• Public webhook plus a provisioning action. Any caller who knows the URL can trigger account creation.

Prioritize remediation by combination, not by raw count. One critical combination outweighs fifty low-severity misconfigurations, and a queue sorted by severity of individual findings will bury the thing that actually matters. This is also where correlation earns its keep: you can only see a toxic combination if you can tie one agent's identity, scope, and effective access together in a single view.

Governance for ITSM agents works in layers, and each layer answers a question your board will eventually ask.

Layer 1, inventory. What agents and workflows exist, who owns them, and what they connect to.

Layer 2, posture. What each agent is configured to do, and where that configuration violates least privilege.

Layer 3, runtime evidence. What each agent actually did, on whose behalf, and with what outcome. This is where ghost-chasing ends and evidence begins. Because the correlation runs from invoker identity to agent action to downstream effect, an incident review that used to take days across four consoles collapses into minutes, and the evidence generates itself as the agent operates.

For ServiceNow and Moveworks today, these first three layers are the deliverable. Obsidian discovers the agents, maps their effective access, and produces the runtime evidence that ties an action back to who triggered it. That is discover and govern, and it is available now.

Layer 4, enforcement. Deterministic guardrails that cut off an action before it completes. For ServiceNow and Moveworks this is a future roadmap item, not a present capability. Obsidian is not an inline gateway sitting in the request path for these platforms. The model on the roadmap is an "Intel Inside" decision engine that informs enforcement points rather than proxying traffic. Today, autonomous runtime blocking is available for Claude and Microsoft Copilot; for the ITSM platforms it is on the roadmap, and any control document should say so in those terms.

That distinction matters for how you plan. You govern ServiceNow and Moveworks agents now with inventory, posture, and runtime evidence, and you scope their access tightly by hand, because the platform will not yet block an out-of-policy action for you.

Revoking Access Cleanly

Revocation is a governance test you should be able to pass before you ever grant access. Disabling the integration in the admin console is not enough. A complete pass disables the Moveworks integration user in ServiceNow, revokes every OAuth token issued to Moveworks, removes the service accounts from all groups and role assignments, deletes any webhooks or REST endpoints the agent calls, rotates shared credentials provisioned for the integration, and then audits ServiceNow logs for any activity from the integration user after the cutoff. If you cannot confirm that no shadow connector still references the removed credentials, you have residual access risk.

Common Mistakes Worth Designing Out

The recurring failures are boring and preventable. Provisioning an agent with one high-privilege super-account for convenience. Enabling every out-of-the-box workflow instead of only what the business needs. Leaving workflows live after their owner departs. Treating admin-console audit logs as sufficient evidence without correlating them to invoker identity. Assuming a SOC 2 attestation covers customer-side configuration risk. Each one widens blast radius quietly, and each one is visible the moment you have real inventory and effective-access mapping in place.