---
sourceDocument: Australia Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Build your agent

# Build your agent {#ariaid-title1}

* Release version: Australia
* 
* Updated March 26, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Build your agent

This guide explains how to create and configure an AI agent using AI Agent Studio in the ServiceNow platform.
It covers the essential steps to define the agent's identity, capabilities, and security settings to ensure proper functionality and secure access.
Show full answer Show less  

## Creating the Agent

Start by navigating to **All \> AI Agent Studio**. An AI agent consists of four key elements:

* **Agent identity:** Defines the agent's persona, domain, and behavior context.
* **Descriptions:** Specify the types of requests the agent can handle, including trigger phrases and instructions (skill domains).
* **Tools:** Enable the agent to perform actions and access data via script tools, sub-flows, or knowledge retrievers.
* **Instructions (prompt):** The core directive describing the agent's identity, capabilities, behavior, and boundaries.

## Configuring Tools

Select only the tools necessary for the agent's use case to adhere to least-privilege principles. When using script tools that access data, prefer **GlideRecordSecure** over GlideRecord to enforce table-level ACLs and maintain security compliance.

## Setting Access Controls

Before testing or deployment, configure two layers of access control:

* **Invocation control (ACLs):** Specify which users can discover and invoke the agent by creating ACLs for each agent and associated workflows.
* **Data access (user identity):** Decide the agent's data access mode:
  * **Dynamic user (recommended):** The agent inherits the roles of the invoking user, limiting access to what the user is entitled to.
  * **AI user:** The agent runs under a dedicated AI user account with fixed roles, used only when elevated access beyond the invoking user's roles is necessary.

Role masking can be applied with dynamic user mode to restrict the roles the agent inherits, further enforcing least-privilege access and preventing unauthorized actions.

## Next Steps

After building the agent, configuring tools, and setting access controls, proceed to configure additional security controls to finalize the agent's setup.  
Create your agent in AI Agent Studio, configure its tools and
knowledge sources, and set the access controls that determine who can invoke it and what data
it can access.

This phase covers the core build work in AI Agent Studio. Security
configuration --- access controls and role masking --- is part of this phase, not a separate
step. Configure it while you build the agent, not after.

## Create the agent {#naai-tutorial-build-agent__section_create}

Navigate to AllAI Agent Studio to begin. Every AI agent is composed of four core elements:

Agent identity
:   Defines who the agent is, what domain it operates in, and how it should behave.
    This is the persistent system-level context that frames every decision the agent
    makes.

Descriptions
:   Define the categories of requests the agent can handle. Each description has a
    name, trigger utterances that route conversations to it, and specific instructions.
    Think of descriptions as the agent's skill domains.

Tools
:   Give the agent the ability to take actions and retrieve data. Tools include script tools (server-side JavaScript), sub-flows (Flow Designer workflows), and retrievers (knowledge source searches).

Instructions (the prompt)
:   Defines who the agent is, what it can do, how it should behave, and what it must
    never do. This is the most important configuration artifact. See [General guidelines for creating AI agents and agentic workflows](https://www.servicenow.com/docs/access?context=gg-creating-aia&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US) for guidelines on writing effective
    agent instructions.

## Configure tools {#naai-tutorial-build-agent__section_tools}

Tools give your agent the capabilities it needs to complete its tasks. Add only the tools
your agent needs for its defined use case --- tools expand the agent's access to platform
data and actions, so limiting them to what is necessary is part of applying least-privilege
principles.  
Important:  
When configuring tools, consider the access each tool requires. A script tool using GlideRecord bypasses table-level ACLs --- use GlideRecordSecure instead to ensure ACL checks are enforced.

## Configure access controls {#naai-tutorial-build-agent__section_access_controls}

Access controls must be configured before you test or deploy your agent. There are two
distinct layers to configure:

**Who can invoke the agent (ACLs):** ACLs determine which users can discover and
invoke your agent. Configure a separate ACL for each agent and each agentic workflow.
For instructions, see [Define security controls for an AI agent](https://www.servicenow.com/docs/access?context=define-sec-controls-aia&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US) for AI
agents and [Define security controls for an agentic workflow](https://www.servicenow.com/docs/access?context=define-sec-controls-aw&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US) for agentic
workflows.

**What the agent can access (user identity):** User identity determines what data
the agent has access to once invoked. Choose one of the following:

Dynamic user (recommended default)
:   The agent runs with the roles of the user who invoked it. Use this option unless
    the agent requires elevated access that the invoking user does not have.

AI user
:   The agent runs as a dedicated AI user account with fixed assigned roles, regardless
    of who invoked it. Use this option only when the agent needs access that cannot be
    granted through the invoking user's roles.

For a full explanation of how ACLs and user identities interact across the agent,
agentic workflow, and tool layers, see [Implement access control in AI agents](https://www.servicenow.com/docs/access?context=aia-security-implementation&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US).

## Apply role masking {#naai-tutorial-build-agent__section_role_masking}

If your agent runs as a dynamic user, use role masking to define an allow-list of roles the agent can inherit from the invoking user. This enforces least-privilege access during tool execution and helps prevent agentic overreach ---
the agent cannot use roles beyond what is explicitly permitted, even if the invoking user has broader access.

See [Role masking in AI agents](https://www.servicenow.com/docs/access?context=aia-role-masking&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US) for an explanation of how role
masking works across the agent, workflow, and tool layers, and see [Define security controls for an AI agent](https://www.servicenow.com/docs/access?context=define-sec-controls-aia&version=australia&pubname=australia-intelligent-experiences&ft:locale=en-US) for configuration steps.

## Next step {#naai-tutorial-build-agent__section_next}

When your agent is built, tools are configured, and access controls are set, proceed to
[Configure security controls](https://www.servicenow.com/docs/2uEcJ8xOUsVQuos99J7vmQ "Set up AI Guardian guardrails and data privacy controls to protect your AI agent interactions before testing begins.").

*[\>]: and then