Securing ServiceNow AI Agents: ACLs, Roles and Logs

ServiceNow AI agents run inside the system of record for incidents, changes, HR cases and the CMDB, so an agent with the wrong identity or an unchecked tool can change production records at machine speed. ServiceNow controls agents with three separate mechanisms (ACLs on who can invoke, a run-as identity, and role masking), and each one is easy to misread. This guide explains how those mechanisms combine, which roles and tables matter, how to secure MCP and external agent connections, what AI Guardian and the agent properties give you for detection and containment, and how to roll out a hardened baseline. It is for ServiceNow platform owners, security administrators and architects building with AI Agent Studio. Feature names and defaults come from ServiceNow documentation and can change between family releases, so confirm them on your instance.

Key takeaways

ACLs decide who can start an agent, not what it does. What the agent can touch depends on the identity it runs as and on role masking, so all three must be set deliberately.
Dynamic user is the default identity. The agent inherits the invoker's roles, which is safe only when role masking trims them to an approved list; an AI user has fixed roles and no masking.
Deny by default is not automatic on upgraded instances. New instances deny agents that lack explicit ACLs, but upgraded instances must opt in.
Supervised tools and kill switches are the containment layer. Supervised execution, recursion checks and the kill switch properties limit damage when an agent misbehaves, and the kill switch ships in warn-only mode.
The execution tables are your audit trail. Execution plans, tasks, tool executions, messages and the generative AI log show what each agent did; export them before the 13 month expiry on tool executions.

How identity and access work in ServiceNow AI agents

In AI Agent Studio you build AI agents (an LLM with instructions and tools) and agentic workflows (an orchestrated objective that calls one or more agents). Tools include flows, flow actions, generative AI skills, catalog items, web search and MCP servers. ServiceNow's documentation describes agentic access control as three parts.

Mechanism	Controls	Where set	Common mistake
ACLs	Who can discover and invoke a workflow, agent, external agent or certain tools	AI Agent Studio (Allow-If) or the ACL table `sys_security_acl` (Deny-Unless)	Choosing "Any authenticated user" or "Public" for agents that change records
User identity (run as)	Which identity the agent executes as	Each workflow and agent: Dynamic user or AI user	Using an AI user with broad roles so the agent "just works"
Role masking (role filtering)	Which of the invoker's roles the agent may use	Workflow, agent and skill level, dynamic user only	Leaving it unset, so the agent gets every role the invoker has

ACL options

Users with specified roles (default): anyone with at least one listed role can invoke. Use this for nearly every agent.
Any authenticated user: every signed-in user, regardless of role. Acceptable for read-only knowledge agents, not for agents that write.
Public: includes unauthenticated guests. ServiceNow says to use it sparingly; treat it as an exception needing security sign-off.
Allow-If versus Deny-Unless: Allow-If grants access when any condition matches and does not stop other ACLs from granting it. Deny-Unless grants access only when all conditions are met and cannot be overridden, but it can only be configured in sys_security_acl, not in AI Agent Studio.
Downstream ACLs: the invoker must satisfy the ACLs of every component assigned to the agent, even ones not used in a given run. Conflicts make execution fail, which is safer than the alternative but needs testing.

Dynamic user or AI user

Question	Dynamic user	AI user
Identity source	Determined at runtime: the user, trigger, workflow or parent agent that invoked it	A `sys_user` record with identity type set to AI user
Roles	The invoker's roles, reduced by role masking	Fixed to the roles assigned to that user
Role masking	Applies	Does not apply
Choose when	The agent acts for a person and must never exceed that person's access	The agent runs from triggers or schedules, or needs access the invoker lacks
Main risk	An administrator invoking an unmasked agent gives it administrator roles	Every invoker borrows the AI user's roles; it becomes a shared privileged account

Treat every AI user as a non-human identity: a named owner, a documented purpose, the smallest role set that works, and an access review. Remember that an AI user lets low-privilege invokers act with its roles, so pair it with a strict invocation ACL. See the AI Agent Authorisation Guide.

Evaluation order

ServiceNow documents the order in which checks apply, which is the order to debug failures in:

Workflow ACLs are checked against the invoker's roles.
Workflow role masking, if configured, reduces those roles.
Agent ACLs are checked against the roles the workflow approved.
Agent role masking is applied, or the AI user's full roles are used.
Tool ACLs are checked against the agent's approved roles.
If the tool is a skill with role masking, the skill's mask is applied.

Deny by default

On newly activated instances, agents and agentic workflows without explicit ACLs are denied. ServiceNow implements this by setting the Security Attribute on the relevant ACLs to Never; wildcard ACLs deny only when no primary ACL exists and mostly serve legacy agents. Upgraded instances are not changed automatically and must opt in. AI Agent Studio shows warnings on its Home page and in guided setup when ACLs are missing; treat those warnings as defects.

Admin roles and privileged access

Role	What it grants	Guidance
`sn_aia.admin`	Full create, read, update and delete on the AI agent application	Small named group; changes through update sets and review
`sn_aia.viewer`	Read and report on all AI agent tables	Give to security reviewers and auditors
`agent_role_config_admin` / `agent_role_config_viewer`	Modify or view agent role configurations	The admin variant controls role masking, so treat it as privileged
`sn_mcp_client.admin`	Add MCP servers in AI Agent Studio	Restrict; each server is a new external tool and credential
`snc_internal`	Broad system-level privileges	ServiceNow says to use it only when an agent truly requires it and never as a fallback
Domain roles such as `itil`, `itil_admin`, `knowledge_admin`	Access to ITSM or Knowledge tables	Prefer the non-admin role for agents; add admin only for a documented action

Who can edit agents is who controls them: instructions, tool assignments, run-as settings and execution mode are all agent configuration. Version control in AI Agent Studio tracks changes to instructions sent to the LLM; review those diffs as you would code.
Separate build and production: build in sub-production and promote. AI Control Tower can synchronise its AI inventory from sub-production to production so governance starts before go-live.
Protect the platform administrators: anyone with the platform admin or elevated security roles can rewrite ACLs and AI users regardless of AI-specific roles. See the ServiceNow Security Guide for the wider administrator baseline.

Integrations, API tokens and service accounts

Agents reach external systems through IntegrationHub spokes, MCP servers and external agents, and external AI clients reach ServiceNow through its MCP server. Each path rests on a stored credential.

ServiceNow as MCP client

Users with sn_mcp_client.admin add MCP servers under AI Agent Studio > Settings > Manage MCP Servers. ServiceNow recommends OAuth 2.1 where the server supports it, with either dynamic client registration or manual registration of a client ID and secret, and a grant type of Authorization Code or Client Credentials. The server must be authenticated on its record before it can be added as a tool.

Scopes: request only the scopes the agent's tools need; scopes are entered comma-separated and are easy to over-grant.
Whose token: decide whether the connection represents a named service account on the remote side or an individual, and record it. An Authorization Code grant ties actions to whoever authorised it.
Revocation: capture the token revocation URL and test that revoking the remote client stops the tool.
Screen MCP output: the mcp_guardian_check agent property (default false) runs AI Guardian on MCP tool executions; it must also be enabled on the AI Agent Studio Settings page.

ServiceNow as MCP server and external agents

To let outside AI clients call ServiceNow tools, ServiceNow has you create an OAuth inbound integration for each MCP client, or authenticate users through a third-party identity provider. One integration per client keeps each client separately revocable. External agent features are off until sn_aia.external_agents.enabled is set to true; leave it off where you do not use them.

Data leaving the instance

The web search tool can use Grounding with Google Search, which ServiceNow notes is not data resident: requests may go to a global data centre outside the instance's processing location. Review that against your data policies before enabling it. See the Low-Code Agent Platforms Guide for the same pattern on other platforms.

Logging and detection

Table or page	What it holds	Detection use
`sn_aia_execution_plan`	Plan executions by conversation ID	Volume per agent and per invoker; spikes
`sn_aia_execution_task`	Tasks per execution plan	Unexpected steps for a known objective
`sn_aia_tools_execution`	Tools run per plan (records expire after 13 months)	Write tools invoked by read-only agents; new tools
`sn_aia_message`	Messages between agents and users	Injection attempts and data in replies
`sys_generative_ai_log`	Generative AI activity log	Model calls, prompts and responses for review
Now Assist Admin > Settings > Now Assist Guardian	Offensiveness, prompt injection and sensitive topic events	Injection trends by skill and agent
Agentic AI activity page and AI Agent Analytics dashboard	Execution logs filterable by version; usage and execution counts	Change impact after a new agent version

AI Guardian

Now Assist Guardian (AI Guardian) offers offensiveness detection, prompt injection detection and sensitive topic filters. Prompt injection detection covers generative AI features and can be set at instance level or per skill; where both are set, the more protective setting applies. Offensiveness and prompt injection default to Log only, which records the event but still shows the output. Block hides the response. ServiceNow recommends reviewing logs before switching to Block, which makes a natural pilot: run Log only for a few weeks, tune, then block for agents that write records. Skills using AI Guardian also remove personally identifiable information before the request reaches the LLM.

Containment properties

Kill switch: kill_switch.mode in sn_aia_property defaults to warn_only; options are off, warn_only and enforce. Related properties set the window size, fires per record and number of distinct records that classify a runaway. Move production agents that write records to enforce once thresholds are tuned.
Recursion checks: recursive_check.create_max_executions (default 50) and recursive_check.update_max_executions (default 5) over a 15 minute window abort further matching executions. Lower them for agents that create tasks or notifications.
Tool limits: sn_aia.continuous_tool_execution_limit (default 7) caps consecutive uses of the same tool, and sn_aia.maximum_agent_tools (default 20) caps tools per agent.
Autonomy override: sn_aia.enable_usecase_tool_execution_mode_override (default false) lets workflows run fully autonomously over non-automated tools. Keep it false and alert if it changes.

Threat mapping and metrics

Instructions planted in incident descriptions, emails or knowledge articles are indirect prompt injection (MITRE ATLAS AML.T0051.001, OWASP LLM01:2025); agents calling tools they should not maps to AML.T0053 AI Agent Tool Invocation and to OWASP LLM06:2025 Excessive Agency; misuse of an AI user or OAuth integration maps to ATT&CK T1078.004 Cloud Accounts and T1528 Steal Application Access Token. The ForcedLeak research on another CRM platform shows how an externally submitted form field can steer an agent with internal data access; ServiceNow record producers and inbound email actions are the equivalent entry points. See the Prompt Injection Guide.

ACL coverage: percentage of agents, workflows and tools with explicit role-based ACLs (target 100%, no Public without sign-off).
Masking coverage: percentage of dynamic user agents with role masking configured.
AI user privilege: roles per AI user, and count of AI users holding admin-level roles (target zero).
Supervision coverage: share of tools that write records running in supervised mode.
Guardian enforcement: agents with prompt injection detection in Block mode, and injection events per thousand executions.
Containment: production agents with the kill switch in enforce.

Hardening baseline

Inventory: list every agent, workflow, trigger, tool, MCP server, AI user and OAuth integration from the sn_aia_* tables, with an owner. Register them in AI Control Tower if you use it, where an AI steward role coordinates governance and skills approvals.
Opt into deny by default (upgraded instances): in sub-production, enable it, run each agent's Test access check in AI Agent Studio, add explicit ACLs for every failure, then promote. Roll back by reverting the opt-in while you fix ACLs.
Set identities: move agents that act for a person to dynamic user with role masking; keep AI users only for triggered or scheduled agents, each with a minimal role set.
Supervise writes: put tools that create, update or close records in supervised mode, which ServiceNow recommends for sensitive actions, and relax only with evidence from the execution logs.
Turn on AI Guardian: Log only first, review for two to four weeks, then Block for agents that write or that read external content.
Tune containment: lower recursion thresholds for record-creating agents, then move the kill switch from warn_only to enforce in a pilot group of agents.
Lock integrations: OAuth 2.1 for MCP servers with minimal scopes, one inbound integration per MCP client, external agents off unless needed.
Export logs: stream execution and generative AI logs to your SIEM and keep them beyond the platform expiry.
Review quarterly: ACLs, AI user roles, role masks, MCP servers and the property values above.

Small and large organisations: a small instance with a few ITSM agents can rely on role-based ACLs, dynamic users with masking, supervised writes and AI Guardian in Block. A large enterprise running agents across ITSM, HR and customer service needs per-domain AI users, release governance through AI Control Tower, central log export and a named owner for every MCP server.

Common misconfigurations

Upgraded instance never opted in: agents without ACLs remain reachable because deny by default was only applied to new instances.
AI user with admin roles: created to get a proof of concept working and never reduced, so every invoker borrows administrator rights.
Dynamic user without masking: an administrator asks a general agent a question and the agent runs with full administrator roles.
Kill switch left in warn only: a runaway agent generates warnings while it keeps updating records.
Guardian in Log only forever: injection attempts are logged and nobody reviews them, and responses still reach users.
Long-term memory enabled without review: sn_aia.ltm.enable_long_term_memory and episodic memory (sn_aia.enable_episodic_memory, default true) feed past interactions back into prompts; decide deliberately whether that data should persist.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Threat reference
AI user lifecycle and ownership	AC-2	PR.AA-05	T1078.004
Role masking and minimal roles	AC-6, AC-6(5)	PR.AA-05	OWASP LLM06:2025
Supervised tools, tool limits, autonomy override off	CM-7	PR.PS	AML.T0053
AI Guardian and input screening	SI-10	PR.PS	AML.T0051.001, OWASP LLM01:2025
Execution and generative AI logs	AU-2, AU-12, AU-6	DE.CM-09	AML.T0086
AI inventory and governance	CA-7	ID.AM-02	T1528

For other agent platforms, see the Securing Microsoft Copilot Studio Agents Guide and the Securing Salesforce Agentforce Guide.

Practitioner checklist

Inventory all agents, workflows, tools, AI users, MCP servers and OAuth integrations with owners.
On upgraded instances, opt into deny by default after testing each agent's access in sub-production.
Use "Users with specified roles" ACLs; justify any "Any authenticated user" and approve any "Public".
Configure role masking on every dynamic user agent and keep AI users to minimal, reviewed roles.
Run tools that write records in supervised mode and keep the autonomy override property false.
Enable AI Guardian prompt injection detection, review Log only results, then switch to Block.
Tune recursion checks and move the kill switch to enforce for production agents that write.
Use OAuth 2.1 with minimal scopes for MCP servers and one inbound integration per MCP client.
Stream sn_aia_* execution tables and sys_generative_ai_log to your SIEM.

Securing ServiceNow AI Agents Guide: Roles, Workflows and Governance