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

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Enable AI

ft:clusterId :

    - platai

bundleId :

    - platai

workflow :

    - Platform


---

# Define access

# Define access rules for an AI agent {#ariaid-title1}

Release version: Brazil  
Updated October 23, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read  
Define security controls for an AI agent to determine which users can access it and what permissions they have.

## Before you begin

Role required: sn_aia.admin

## About this task

The Access rules section is divided into two parts: Which users can access this AI agent (ACLs) and Which data this AI agent can access. The former creates an ACL that determines who can discover or invoke the AI agent. The latter defines the data that the AI agent has access to once it's invoked.

See [Security for AI agents](https://www.servicenow.com/docs/Cb~YXDNXD1Pfsl_fEzU0ZA "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.") for more information about creating ACLs and user identities for security for AI agents.

## Procedure

1. Define user access by selecting an option from the Allowed users dropdown.  
   The dropdown menu options are:
   * Users with specified roles
   * Authenticated users
   * Public

   If you select Users with specified roles, you can select exactly which roles can access the AI agent.

   AI agents installed with AI applications each require specific roles. To learn which roles needed for AI agents associated with ServiceNow Otto applications, consult the documentation for the AI agent or the agentic workflow that uses the AI agent.

   Selecting Public means anyone who can reach the instance can invoke the agent. Use it only for agents that expose no record data. Public should be used sparingly.

   An access control list (ACL) is generated based on the roles you select. Saving triggers the creation of an ACL for your AI agent. If you want to make changes later, you can return to the guided setup and change the options here. If you have the correct elevated role, you can also make edits directly on the ACL table.
2. Select whether third-party AI agents can access the AI agent.  
   If selected, only AI agents with the correct user access can invoke the AI agent.
3. Define data access by selecting a user identity type from the Identity type dropdown.  
   The user identity determines what data the AI agent can read and write while it runs.

   The two options are Dynamic user and AI user. The dynamic user is the user invoking the AI agent or the dynamic user of the agentic workflow calling on the AI agent. An AI user is a dedicated user that has its own specified roles that allow access, which could be more than the dynamic user. Every invocation reads and writes with the AI user's roles regardless of who started it.

   If you do not have an AI user but want to use the AI user identity, you need to create a new record on the User table. See [Create a user](https://www.servicenow.com/docs/access?context=t_CreateAUser&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US). Select AI user as the identity type.

   If you select Dynamic user, you can select the Approved roles that the AI agent runs with. By default, an AI agent runs as a dynamic user and has the roles of the invoking user. Select the approved roles to limit the data access that an AI agent could have. Role filtering must be applied for all AI agents and agentic workflows to run as dynamic users. If you don't select any roles, the agent inherits whatever roles the invoking user holds.

   To override the role filtering requirement for a specific agentic workflow or AI agent, an admin with the correct elevated access must first create an approved roles list for it. Then, in the Agent Access Role Configurations table \[sys_agent_access_role_configuration\], the admin selects the allow all roles check box. This removes the approved roles requirement in AI Agent Studio, so you can return to AI Agent Studio and finish configuring the agentic workflow or AI agent without role filtering.  
   Note:  
   Role filtering should be applied as security best practice and adherence to the principle of least privilege. Overriding the role filtering requirement isn't recommended.

   When testing an AI agent, run the AI agent with different roles to confirm that only the correct data is accessed for the user audience.


## Result

You have created an ACL that determines who can discover and access your AI agent, and you have assigned a user identity (and role filtering, if relevant) to the AI agent to determine what data it can access.

## What to do next

Scroll down to the next section of the guided setup, Triggers, to [define specific conditions where the AI agent should run](https://www.servicenow.com/docs/uWhxMqtSURzLrYHswAmPew "In the guided setup for an AI agent, add triggers to run the AI agent automatically when certain conditions are met."). Adding triggers is optional.