---
sourceDocument: Zurich Enable AI
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/intelligent-experiences

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich Enable AI

ft:clusterId :

    - platai

bundleId :

    - platai

workflow :

    - Platform


---

# Security for AI agents

# Implement access control in AI agents {#ariaid-title1}

Release version: Zurich  
Updated September 1, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Implement access control in AI agents

ServiceNow's AI Agent Studio provides a comprehensive security framework to control access and execution privileges for AI agents and agentic workflows.
This framework uses Access Control Lists (ACLs), user identities, and role filtering to ensure that only authorized users can invoke AI agents and that these agents operate within defined privilege boundaries.
Effective configuration of these components is essential to maintain security and proper functionality in AI-driven workflows on the ServiceNow AI Platform.
Show full answer Show less  

## Access Control Lists (ACLs)

ACLs specify which users or roles can invoke AI agents, agentic workflows, and related tools (such as generative AI Skills, Flows, and Flow Actions). Configured as Allow If rules in AI Agent Studio, ACLs grant access when any specified condition is met, with three main options:

* **Any authenticated user:** Grants access to all authenticated users regardless of roles.
* **Users with specified roles:** Default option requiring selection of roles authorized to invoke the agent.
* **Public:** Grants access to all users, including guests (use sparingly).

ACLs only control who can invoke the agent, not what the agent can do during execution. All downstream components in the agentic system must have compatible ACLs; conflicting ACLs or unmet ACL conditions cause execution failures. New instances default to a deny-by-default ACL posture, requiring explicit ACL configuration to permit access, which enhances security by preventing unauthorized use.

## User Identities (Run As)

User identities determine the permissions and data access of AI agents during execution. Two configurations are available:

* **Dynamic user:** The agent runs under the identity of the invoking user, dynamically inheriting their roles. This is the default setting.
* **AI user:** A dedicated user identity with fixed roles assigned to the AI agent or workflow, enabling execution with consistent privileges regardless of the invoking user's rights. Useful for scenarios requiring elevated privileges.

Proper configuration of user identities is critical to ensure agents operate within intended privilege scopes and to avoid execution failures due to insufficient permissions.

## Role Filtering

Role filtering restricts the set of roles an AI agent inherits from the invoking user when running as a dynamic user. This limits the agent's capabilities to a pre-approved subset of roles, ensuring adherence to the Least Privilege Principle even if the invoking user has higher privileges. Role filtering does not apply when the agent runs as an AI user, since the AI user's roles are statically assigned and controlled.

## Deny-by-Default Enforcement

Newly activated ServiceNow instances enforce a deny-by-default ACL policy for AI agents and agentic workflows, requiring explicit ACLs to permit access. This prevents unauthorized access by default. Existing instances upgraded to recent releases must opt in to adopt this more secure posture.

## Security Notifications in AI Agent Studio

The AI Agent Studio interface provides warnings on the Home page and guided setup pages when AI agents or workflows lack required ACL configurations. This helps administrators ensure security settings are properly applied before deployment.

## How These Mechanisms Work Together

* **ACLs** control who can discover and invoke AI agents.
* **User identities** define the privilege context in which the agent executes.
* **Role filtering** limits the agent's effective roles during execution when using dynamic users.

Configuring all three components is essential for a robust security posture, preventing unauthorized invocation, privilege escalation, and unintended agent actions. Neglecting any mechanism can leave security gaps.

## Practical Guidance for ServiceNow Customers

* Define explicit ACLs for all AI agents, workflows, and tools to control invocation.
* Choose user identities carefully---use dynamic users for context-aware privileges or AI users for fixed elevated roles.
* Apply role filtering when using dynamic users to enforce least privilege access.
* Leverage AI Agent Studio warnings to verify security configurations before deployment.
* Understand that ACLs govern access, while user identities and role filtering govern execution privileges and capabilities.
* For new instances, proactively configure ACLs due to deny-by-default enforcement.

By following these guidelines, customers can securely implement AI agents that comply with organizational policies and minimize security risks on the ServiceNow AI Platform.  
Implement security in AI Agent Studio through access control lists (ACLs), user identities, and role filtering with the access control-based security measures in the agentic system.

## Security for AI agents {#aia-security-implementation__section_ksd_q3z_kkc}

Access controls for agentic AI on the ServiceNow AI Platform comprises the major aspects: determining which users can access agentic AI resources and what access each of those resources has once invoked. These aspects are controlled through three main components:
access control lists (ACLs), user identities and role filtering. The interaction between these components at the agentic workflow, AI agent, and tool levels within AI Agent Studio influences their overall security and functionality.

## Access Control Lists (ACLs) {#aia-security-implementation__section_njv_q3z_kkc}

The access control lists (ACLs) in AI agents determine which role(s) a user must have to be allowed to invoke an agentic workflow or an AI agent. ACLs must be configured individually for each agentic workflow, AI agent, external AI
agent, and certain AI agent tools such as generative AI Skills, Flows, and Flow Actions.  
ACLs configured in the AI Agent Studio for are role-based and of the Allow If type:

* Allow-If: Grants access to data or resources when any of the specified conditions in the ACL are met. Allow If ACLs don't prevent other ACLs from granting access to the same resource even if it that specific ACL itself doesn't grant access.
* Deny-Unless: Grants access only when the invoking user identity meets all the specified conditions. No other ACLs can override or grant access to that resource once a Deny Unless ACL is in place. This is available when configuring ACLS in the ACL \[sys_security_acl\] table and not in the AI Agent Studio.
{#aia-security-implementation__ul_is3_ydh_xgc}

There are three possible options for ACLs created in AI Agent Studio:

* Any authenticated user: Grants access to any user who is authenticated on the instance, regardless of the role.
* Users with specified roles: The default ACL option that requires you to select the specific roles required to invoke an AI agent or an agentic workflow.  
  Note:  
  As the ACLs are Allow If ACLs, any user with at least one of the roles will be able to invoke the AI agent or agentic workflow.
* Public: Grants access to all users, including guests who aren't signed in.  
  Note:  
  Understand that this configuration should be used sparingly and only when needed.

{#aia-security-implementation__ul_qdz_hrg_njc}  
Note:  
* ACLs configured in AI Agent Studio only determine the roles required for users to invoke an agentic workflow or an AI agent. They don't determine the access that the agentic workflow or an AI agent has once it's invoked.
* For an agentic workflow or AI agent to successfully execute, the invoking user (or relevant AI user) must meet the criteria of all of the ACLs of any downstream components which have their own ACLs and are assigned to the agentic workflow or AI agent (even if the specific execution might not need to invoke all of those AI agents or tools). Therefore:
  * If there are conflicting security requirements between agentic workflows, AI agents, and AI agent tools, your agentic AI fails to execute.
  * The same occurs if the invoking user meets the criteria for some ACLs but not others. This includes components assigned to the agentic AI that might not be required for the specific execution.
  {#aia-security-implementation__ul_j2b_pv4_lkc}
* When configuring these security settings, consider all aspects of the agentic system- including the agentic workflow, AI agents, and tools.
{#aia-security-implementation__ul_i5n_2s4_skc}

## User identities {#aia-security-implementation__section_qwq_qnz_kkc}

After configuring the access control lists (ACLs), you must configure the User identity (also called as Run as) which the AI agent or agentic workflow will run as during execution.

After configuring the access control lists (ACLs), you must also configure the user identity (also
called as Run as) which the AI agent or agentic workflow will run as during execution.  
The user identity determines which user the AI agent or an agentic workflow operates as during execution, and therefore the data it can access and the actions it can take, depending on the roles assigned to the user identity.  
Note:  
Each agentic workflow and AI agent has its own user identity configuration.  
There are two possible user configurations to select from:

* Dynamic user: The user identity of the person or resource (automated trigger/agentic workflow/parent agent) which invokes the execution of an AI agent or an agentic workflow. The roles assigned to the agentic workflow or AI agent will change dynamically depending on the identity of the invoking user.  
  Note:  
  Dynamic user is the default user identity, and you can use the dynamic user unless there's a specific need that justifies an AI user.
* AI user: A dedicated user identity that the AI agent or an agentic workflow runs as during execution, which has assigned roles that remain consistent regardless of who or how the execution is invoked. For example, an AI agent or an agentic workflow may need to be run with elevated privileges that the dynamic user might not have. If configured as a dynamic user, the execution would fail. However, if the AI agent or agentic workflow is configured to run as an AI user that has the elevated roles assigned to it, the execution will succeed even when invoked by a user with lower privileges.  
  Note:  
  If you don't have a suitable AI user but want to use the AI user identity, you must create a record on the User \[sys_user\] table. See [Create a user](https://www.servicenow.com/docs/access?context=t_CreateAUser&version=zurich&pubname=zurich-platform-administration&ft:locale=en-US) and select AI user as the identity type.
{#aia-security-implementation__ul_xkr_mhg_hgc}

## Role filtering {#aia-security-implementation__section_q3h_qnz_kkc}

Role filtering restricts the roles that AI agents can inherit from the invoking user to a subset of
approved roles. This limits the capabilities of the agent, ensuring it can only use the roles that the builder of the AI agent has specifically permitted, even if the user possesses additional roles.

Role filtering only applies when the agent runs as a dynamic user --- because the identity (and
resulting roles) of the invoking user can't be known in advance. There could be situations in which high-privileged users invoke AI agents that should not run with high privileges. By applying role filtering, the builders of AI
agents can make sure that their agents adhere to the Least Privilege Principle. Role filtering is not required when an AI agent runs as an AI user. Since the roles of the AI user are preconfigured and can (and should) be set to meet
the needs of the specific AI agent -- no additional filtering is required to conform to the Least Privilege Principle, which can be controlled entirely by the AI user configurations.

## Deny by Default {#aia-security-implementation__section_hng_rnz_kkc}

The ServiceNow AI Platform enforces a deny-by-default ACL (Access Control Lists) configuration certain types of agentic components on newly activated instances. In earlier releases, these record types defaulted to allow access unless
an ACL was configured for a specific record. In Australia release, newly activated instances start from a deny-by-default posture instead, so access has to be configured explicitly by creating an ACL for the specific record, rather than inherited through
permissive defaults. This applies to any AI agents and agentic workflows that don't have an individual ACL configured, reducing unauthorized access risks.  
The deny-by-default enforcement works as follows: The Security Attribute field value for AI Agent and agentic workflow on the Access Controls table \[sys_security_acl\] is set to Never, enforcing the deny behavior and leaving the Decision Type field value as is, that is, Allow If. This configuration verifies that if an AI component already has a primary ACL in place, access continues to be governed by that ACL. The backup (wild card) ACLs deny access only when no primary ACL is present. The old wildcard ACLs allow users with agents that predate the availability of access controls in agentic products to continue to run their agents, but that general guidelines is to implement deny by default in all instances. The replacement means that the AI agents and agentic workflows must have explicit ACL entries to operate. Without explicit ACLs, access is denied by default.  
Note:  
The enforcement applies only to the newly activated instances. Any instances that are upgraded to Australia release from previous releases aren't automatically affected by this configuration change and the adoption of the deny-by-default ACL configuration will require admins to proactively opt in.

## Security check on AI Agent Studio {#aia-security-implementation__section_owh_j5p_lkc}

To inform users about security checks on the agentic system, the platform provides the following notifications in the AI Agent Studio interface:  
* AI Agent Studio Home page: The AI Agent Studio Home page displays a warning when AI agents or agentic workflows don't have explicit ACLs configured on the instance.

* AI Agent guided setup: The AI agent guided setup page displays a warning banner when that agent doesn't have the required ACLs configured.  
  Note:  
  To configure access control lists for an AI agent, see [Define security controls for an AI agent](https://www.servicenow.com/docs/dXvvVFPByrXRUHxE_roitw "In the guided setup for an AI agent, define security controls for who can access the AI agent and what data the AI agent has access to.").
* Agentic workflow guided setup: The agentic workflow agent guided setup page displays a warning banner when that agentic workflow doesn't have the required ACLs configured.  
  Note:  
  To configure access control lists for an agentic workflow, see [Define security controls for an agentic workflow](https://www.servicenow.com/docs/J8tIMMU4bpuaMo8GLEwcFQ "In the guided setup for an agentic workflow, define security controls for who can access the agentic workflow and what data the agentic workflow has access to.").
{#aia-security-implementation__ul_npm_dvp_lkc}

## Security mechanisms {#aia-security-implementation__section_mt1_r5b_lkc}

Using ACLs, user identities, and role filtering together provides layered security for AI agents.

* ACLs prevent unauthorized users from reaching and invoking the agent.
* User identities verify the agent operates under the correct privilege scope at runtime, preventing escalation beyond what the assigned dynamic user permits.
* Role filtering verifies that agents can't take actions that exceed defined boundaries even when invoking use has that access.
{#aia-security-implementation__ul_n54_wtb_lkc}  
A common source of confusion is assuming that ACLs define agent actions. They don't! ACLs determine who can invoke the agent. The scope of permissible agent actions are determined by the user identity and role filtering. Use the following summary to distinguish the mechanisms:{#aia-security-implementation__table_ohj_mgr_jjc__entry__4}

| Feature | ACLs | User identities | Role filtering |
|-|-|-|-|
| Controls | Who can access the agent | Which identity the agent acts as | What the agent can do |
| Applied to | Users, groups, and roles that invoke the agent | The user identity with which the agent executes at runtime | The agent's runtime execution context |
| Security purpose | Restricts agent discoverability and invocation | Determines privilege scope during execution | Restricts agent actions and data access |
[Table 1. Distinguishing ACLS, user identities, and role filtering]

{#aia-security-implementation__table_ohj_mgr_jjc}{#aia-security-implementation__table_nck_mwg_njc__entry__3}

| Feature | AI user | Dynamic user |
|-|-|-|
| Definition | A predefined identity the agent runs as | The identity of the agent at runtime which is inherited from the invoking user. |
| Role filtering applies | No | Yes |
| Roles used | Fixed to the AI user's assigned roles | Scoped down by role filtering |
| Identity source | Configured statically | Determined dynamically at runtime |
[Table 2. Distinguishing AI user and Dynamic user]

{#aia-security-implementation__table_nck_mwg_njc}  
Note:  
Configuring only one of these mechanisms leaves a gap in the agent's security posture. Therefore, it is necessary to configure the security mechanisms across the AI Agent Studio and other AI components such as generative AI Sills, Flows, and Flow Actions.

For more information, see [Define security controls for an AI agent](https://www.servicenow.com/docs/dXvvVFPByrXRUHxE_roitw "In the guided setup for an AI agent, define security controls for who can access the AI agent and what data the AI agent has access to.") and [Define security controls for an agentic workflow](https://www.servicenow.com/docs/J8tIMMU4bpuaMo8GLEwcFQ "In the guided setup for an agentic workflow, define security controls for who can access the agentic workflow and what data the agentic workflow has access to.").