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

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Enable AI

ft:clusterId :

    - platai

bundleId :

    - platai

workflow :

    - Platform


---

# Implement access control in AI Agent Studio

# Implement access control in AI Agent Studio {#ariaid-title1}

Release version: Australia  
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 Agent Studio

ServiceNow AI Agent Studio implements security for agentic AI through three key mechanisms: Access Control Lists (ACLs), user identities, and role filtering.
These controls determine who can invoke AI agents and workflows, under what identity they operate, and what actions they are permitted to perform.
Proper configuration across all AI components---including workflows, agents, and tools---is essential to ensure secure and functional AI operations.
Show full answer Show less  

## Access Control Lists (ACLs)

ACLs in AI Agent Studio define the roles required for users to invoke agentic workflows or AI agents. They are role-based and follow an "Allow If" model, granting access if any specified condition is met. ACLs can be set to:

* **Any authenticated:** Allows all authenticated users
* **Users with specified roles:** Requires certain roles to invoke the AI agent or workflow (default option)
* **Public:** Grants access to all users, including guests (use with caution)

ACLs only control invocation permissions, not the access rights of the agent once running. All downstream AI components with their own ACLs must also be accessible by the invoking user; otherwise, execution fails. Since ACLs are "Allow If" type, conflicts or incomplete access across components prevent successful execution.

## User Identities

The user identity (Run as) determines the privileges of the AI agent or workflow during execution. Two options exist:

* **Dynamic user:** Runs as the invoking user, inheriting their roles dynamically. This is the default and suitable unless elevated privileges are needed.
* **AI user:** Runs as a dedicated user with fixed roles, useful when the agent requires elevated privileges not held by the invoking user. Such AI users must be created as records in the User table.

## Role Filtering

Role filtering restricts which roles an AI agent can inherit from the invoking user when running as a dynamic user. This enforces the Least Privilege Principle by limiting the agent's capabilities to only those roles explicitly approved by the builder. Role filtering does not apply when running as an AI user, since roles are predefined and controlled in that context.

## Deny by Default

Starting with the Australia release, newly activated instances enforce a deny-by-default posture for AI agents and workflows. Access must be explicitly granted via ACLs; otherwise, invocation is denied. This reduces unauthorized access risks. Upgraded instances retain previous permissive defaults but are encouraged to adopt deny-by-default manually.

## Security Notifications

AI Agent Studio provides warnings in the interface when ACLs are missing from agents or workflows, including on the Home page and guided setup pages. This helps administrators identify and resolve security gaps during configuration.

## Security Mechanisms Summary

These three mechanisms form layered security:

* **ACLs:** Control who can discover and invoke agents.
* **User identities:** Define the privilege scope during execution.
* **Role filtering:** Limit what actions the agent can perform at runtime.

ACLs do not restrict agent actions; that responsibility lies with the user identity and role filtering. Both AI user and dynamic user configurations have distinct roles in managing security:

| Feature | AI user | Dynamic user |
|-|-|-|
| Definition | Predefined identity the agent runs as | Identity inherited from invoking user at runtime |
| Role filtering applies | No | Yes |
| Roles used | Fixed assigned roles | Scoped down by role filtering |
| Identity source | Configured statically | Determined dynamically at runtime |

Configuring all three security aspects together is necessary to close security gaps and ensure AI agents operate safely within their intended privilege boundaries.  
Implement security in AI Agent Studio through access control lists (ACLs), user identities, and role filtering.

## Security for AI agents {#implement-aias-security-new__section_ksd_q3z_kkc}

Access controls for agentic AI on the ServiceNow AI Platform comprise two 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) {#implement-aias-security-new__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 AI Agent Studio 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 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 AI Agent Studio.

{#implement-aias-security-new__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:  
  Use this configuration sparingly, and only when needed.

{#implement-aias-security-new__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.
  {#implement-aias-security-new__ul_j2b_pv4_lkc}
* When configuring these security settings, consider all aspects of the agentic system, including the agentic workflow, AI agents, and tools.

## User identities {#implement-aias-security-new__section_qwq_qnz_kkc}

After configuring the access control lists (ACLs), you must also configure the user identity (also
called 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=australia&pubname=australia-platform-administration&ft:locale=en-US) and select AI user as the identity type.
{#implement-aias-security-new__ul_xkr_mhg_hgc}

## Role filtering {#implement-aias-security-new__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 {#implement-aias-security-new__section_hng_rnz_kkc}

The ServiceNow AI Platform enforces a deny-by-default ACL (Access Control Lists) configuration for 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 ensures 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 the general guideline 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 {#implement-aias-security-new__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.

* 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.

{#implement-aias-security-new__ul_npm_dvp_lkc}

## Security mechanisms {#implement-aias-security-new__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 the invoking user has that access.

{#implement-aias-security-new__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 is determined by the user identity and role filtering. Use the
following summary to distinguish the mechanisms:
{#implement-aias-security-new__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]

{#implement-aias-security-new__table_ohj_mgr_jjc}{#implement-aias-security-new__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]

{#implement-aias-security-new__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 Skills, Flows, and Flow Actions.

For more information, see [Configure access controls across AI Agent Studio](https://www.servicenow.com/docs/VZBo6c4JMYjWrEqtBce9Yg "Configure access rules in AI Agent Studio for AI agents, agentic workflows, Model Context Protocol Servers, and external AI agents.").