Deny-by-default ACL configuration

  • Release version: Australia
  • Updated May 26, 2026
  • 4 minutes to read
    • Summarize
    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 Deny-by-default ACL configuration

    The ServiceNow AI Platform enforces adeny-by-defaultAccess Control List (ACL) configuration for AI agentic types on freshly reset instances. This security measure ensures that AI agents and agentic workflows without explicit ACLs are denied access by default, reducing unauthorized access risks and aligning with secure-by-default best practices.

    Show full answer Show less

    ACL Configuration in AI Agent Studio

    ACLs for AI agents and agentic workflows in AI Agent Studio are role-based and primarily use the Allow If type, granting access if any specified conditions are met. These ACLs come with three access options:

    • Any authenticated user - Access granted to any authenticated user.
    • Users with specified roles (default) - Access granted to users possessing at least one selected role.
    • Public - Access granted to all users, including guests not signed in.

    Each AI agent and agentic workflow requires its own unique ACL. Deny-Unless ACLs, which strictly require all conditions to be met, can be configured only in the ACL [syssecurityacl] table, not within AI Agent Studio.

    Security Checks and Notifications

    The platform provides warnings in the AI Agent Studio interface to alert users when AI agents or agentic workflows lack explicit ACLs:

    • AI Agent Studio Overview page shows warnings for missing ACLs.
    • Guided setup pages for AI agents and agentic workflows display warning banners if required ACLs are not configured.

    These alerts apply to both users who have adopted deny-by-default and those using wildcard ACLs, prompting them to configure explicit ACLs for secure and uninterrupted operation.

    ACL Types and Enforcement Details

    Five new ACL types related to AI agentic components default to allow access, but the deny-by-default directive applies on freshly reset instances to prevent inadvertent exposure:

    • genaiagent
    • genaiworkflow
    • genaiskill
    • Flow
    • flowaction

    The enforcement sets the Security Attribute field for AI Agent and agentic workflows in the Access Controls table [syssecurityacl] to Never, which denies access unless an explicit ACL is present. Existing wildcard ACLs allow legacy agents to continue functioning but implementing deny-by-default is recommended for all instances.

    Scope and Applicability

    This deny-by-default ACL configuration applies only to freshly reset instances and affects ACL records of the specified agentic types that use wildcard patterns.

    Security Benefits

    • Reduces unauthorized access risks from permissive wildcard ACLs.
    • Prevents accidental exposure of records without explicit ACL entries.
    • Aligns AI agentic components with secure-by-default principles.
    • Provides a clear and auditable ACL model for agentic workflows and AI agents.

    The ServiceNow AI Platform enforces a deny-by-default ACL (Access Control Lists) configuration for AI agentic types on freshly reset instances, for any AI agents and agentic workflows that don't have an individual ACL configured to reduce unauthorized access risks.

    Configure ACLs in AI Agent Studio

    ACLs configured in the AI Agent Studio for AI agents and agentic workflows 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 it 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 the AI Agent Studio.

    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.
    Each AI agent and agentic workflow must have its own unique ACL.
    Note:
    If there are conflicting security requirements between agentic workflows, AI agents, and AI agent tools, or if the invoking user meets the criteria for some ACLs but not others, your agentic AI fails to execute. When configuring these security settings, consider all aspects of the agentic system- including the agentic workflow, AI agents, and tools.

    Security checks on AI Agent Studio

    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 Overview page: The AI Agent Studio overview page displays a warning when agents or agentic workflows don't have explicit ACLs configured on the instance.

      AI Agent Studio overview page displaying the number of AI agents and agentic workflows that don't have the access control lists configured.

    • AI agent guided setup: The AI agent guided setup page displays a warning banner when that agent doesn't have the required ACLs configured.
      An AI agent guided setup page displaying a warning banner when no ACLs are configured.
      Note:
      To configure access control lists for an AI agent, see Define security controls for an AI agent.
    • 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.
      An agentic workflow guided setup page displaying a warning banner when no ACLs are configured.
      Note:
      To configure access control lists for an agentic workflow, see Define security controls for an agentic workflow.

    These warnings indicate that ACLs are missing and should be configured to verify secure and uninterrupted operation. Users who have already switched to deny-by-default and users who still use wildcard ACLs will both see these warnings. For wildcard ACL users, the warnings are informational.

    ACL types

    The AI access control changes brought in five new ACL types that default to allow access, expanding the platform attack surface. The ServiceNow AI Platform enforces a deny-by-default directive for these agentic ACL types on the freshly reset instances. This configuration verifies that records without explicit ACLs aren't inadvertently exposed, aligning the platform with secure-by-default best practices for AI agentic components.

    The ACL types are:

    • gen_ai_agent
    • gen_ai_workflow
    • gen_ai_skill
    • Flow
    • flow_action

    How deny-by-default enforcement works

    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 verifies 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 that general guidelines 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 freshly reset instances. Any instances that aren't reset aren't affected by this configuration change.

    Scope and applicability

    The deny-by-default ACL configuration applies under the following conditions:

    • The instance is a freshly reset instance.
    • The ACL type is one of the five agentic types.
    • The existing ACL record uses a wildcard (*) pattern.

    Security benefits

    Enforcing deny-by-default ACLs for agentic types provides the following security benefits:

    • Reduces the risk of unauthorized access to AI agents and agentic workflows resulting from permissive wildcard ACLs.
    • Verifies that records without explicit ACL entries aren't inadvertently exposed.
    • Aligns the platform with secure-by-default principles for AI agentic components.
    • Provides a clear, auditable ACL model for agentic workflows and AI agents.