--- 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 --- # Arc policies # Arc policies {#ariaid-title1} Release version: Australia Updated October 23, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Arc policies Arc policies allow ServiceNow customers to centrally control and govern the actions of ServiceNow Arc, an autonomous AI agent, on users' devices. These policies specify which tools, commands, network destinations, files, and connector permissions Arc can access and determine when certain actions require user approval. This control is managed through AI Control Tower, ensuring that Arc's behavior aligns with organizational security and operational requirements. Show full answer Show less ## Key Features * **Centralized Management:** Create and manage policies centrally via AI Control Tower, applying them to specific user groups. * **Granular Control:** Define which tools, hosts, files, and connector permissions Arc can use for different groups without affecting others. * **Approval Gates:** Configure actions that modify data, interact with external systems, or send messages to require explicit user approval before execution. * **Enforcement Built Into Arc:** Policies are enforced by Arc itself, preventing users or the agent from bypassing restrictions. * **Default and Group Policies:** Users start with a default policy; additional policies can be created for specific groups to tailor Arc's capabilities. * **Explicit Block Policies:** Separate from Arc policies, these can completely block users or all users from using Arc if needed. ## Practical Use Cases * **Restricted Network Access:** Allow specific teams, such as developers, to access internal sites or package registries by creating policies that whitelist necessary hosts while maintaining restrictions for others. * **Approval for Critical Changes:** For sensitive operations like infrastructure changes, policies can enforce approval gates so that changes only proceed after user confirmation. * **Pilot Auto Mode:** Enable auto approval and tool access for select teams to trial automated workflows without impacting the broader organization, which continues with default approval prompts. ## Benefits for ServiceNow Customers By implementing Arc policies, customers can retain operational efficiency by allowing routine actions to proceed automatically while safeguarding critical changes through approval requirements. This balance helps maintain security and compliance, supports tailored team workflows, and prevents unauthorized or potentially harmful actions by the AI agent on user devices. Control which tools, commands, network destinations, files, and connector permissions ServiceNow Arc can use on your users' devices, and which actions wait for a person's approval, from AI Control Tower. ## Key benefits {#gov-pol-arc-policies__key-benefits} * Keep routine work moving while actions that delete data, change external systems, or send messages wait for a person's decision. * Limit the tools, hosts, files, and connector permissions Arc can use on your users' devices. * Give specific teams different Arc behavior without changing the default for everyone else. {#gov-pol-arc-policies__ul_arc_benefits} ## How Arc policies work {#gov-pol-arc-policies__how-arc-policies-work} ServiceNow Arc is an autonomous AI agent that runs commands, reads and writes files, and reaches external systems on behalf of users. Because it acts for users, your organization needs control over what it can do. Arc policies give you that control. You manage them centrally from AI Control Tower, and Arc checks every action against the policies that apply to the user before the action runs. Enforcement is built into Arc itself, so neither the agent nor the user can bypass a policy. For how policies reach the desktop application, see . Every user starts with the default Arc policy. To change what Arc does for a group, you create a policy for that group and add rules for only the behavior you want to change. Explicit Block policies can also apply to Arc, but they do a different job. An Explicit Block policy stops a person, or everyone, from using Arc at all. An Arc policy shapes what Arc can do for the people who use it. For details on blocking access, see [Explicit Block policies](https://www.servicenow.com/docs/nSGgLgTqL4TK6prCUkr3uw "Stop a specific person, a department, or your whole organization from using an AI agent, model, or domain, enforced automatically everywhere that access could happen."). For installation, connectors, and everyday use of the desktop application, see . ## Use cases {#gov-pol-arc-policies__use-cases} Opening an internal site for one team : Your developers need Arc to reach an internal package registry that the default policy doesn't allow. A policy for the developer group with a network rule that allows the registry's host makes it reachable for developers only. Everyone else keeps the default allowlist. Pausing infrastructure changes for review : Your platform engineers use Arc to work on infrastructure code, and applying a change affects live systems. An approval pattern with a hard gate makes every apply wait for the engineer's approval. Planning a change and other commands that don't match the pattern aren't affected. Piloting auto mode with one team : Your organization wants to try auto mode with one team before rolling it out more widely.A policy for the pilot team turns on the auto approval capability and sets the tools the team uses most to auto approval. The rest of your organization keeps the default prompts.