{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":41702,"path":"platform-security/naai-tutorial-build-agent.md","title":"Build your agent","bundle":null,"doc_type":null,"release":"australia","body":"\n# Build your agent\n\nCreate 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.\n\nThis 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.\n\n## Create the agent\n\nNavigate to **All** > **AI Agent Studio** to begin. Every AI agent is composed of four core elements:\n\n-   **Agent identity**\n\n    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.\n\n-   **Descriptions**\n\n    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.\n\n-   **Tools**\n\n    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\\).\n\n-   **Instructions \\(the prompt\\)**\n\n    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 writing prompts for agentic AI](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/intelligent-experiences/gg-creating-aia.md) for guidelines on writing effective agent instructions.\n\n\n## Configure tools\n\nTools 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.\n\n**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.\n\n## Configure access controls\n\nAccess controls must be configured before you test or deploy your agent. There are two distinct layers to configure:\n\n**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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/intelligent-experiences/define-sec-controls-aia.md) for AI agents and [Define security controls for an agentic workflow](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/intelligent-experiences/define-sec-controls-aw.md) for agentic workflows.\n\n**What the agent can access \\(user identity\\):** User identity determines what data the agent has access to once invoked. Choose one of the following:\n\n-   **Dynamic user \\(recommended default\\)**\n\n    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.\n\n-   **AI user**\n\n    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.\n\n\nFor 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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/intelligent-experiences/aia-security-implementation.md).\n\n## Apply role masking\n\nIf 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.\n\nSee  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://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/intelligent-experiences/define-sec-controls-aia.md) for configuration steps.\n\n## Next step\n\nWhen your agent is built, tools are configured, and access controls are set, proceed to [Configure security controls](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/naai-tutorial-configure-security.md).\n\n**Parent Topic:**[Create and secure an AI agent in Now Assist](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/platform-security/naai-tutorial-overview.md)\n\n"}}