Understanding invoke_from_ai ACL in ServiceNow: AI Agent Flow Security Explained

[Luis Estéfano]

Security · Access Control · Agentic AI

Understanding invoke_from_ai ACL in ServiceNow

The invoke_from_ai ACL operation type controls whether a user has permission to invoke specific flows or flow actions via AI Agent, Now Assist, or Agent Tools. This article explains what it is, when it applies, and what you need to configure when building custom AI experiences on ServiceNow.

Author

Luis Estéfano

Applies to

Now Assist · AI Agents · Agentic Workflows

Release

Zurich and later

1. What is invoke_from_ai?

invoke_from_ai is an ACL operation type for records of Type = flow or Type = flow_action. It answers one question: "Does this user have permission to invoke this specific action from AI?"

Think of it like other ACL operations you already know — read, write, report. A user may have read access to the Incident table but not be allowed to run reports on it, or invoke AI against it. Each operation is independently controlled. invoke_from_ai is the AI-specific gate for flows and flow actions.

Key point: The subject of the ACL is the user, not the AI agent. Access is evaluated based on the roles and conditions of the user who triggered the AI interaction — the AI acts on their behalf.

2. How it Works

Evaluation

invoke_from_ai is evaluated immediately before an AI Agent or AI Controller executes a flow or flow action. It is always enforced — there are no bypass paths. Standard ACL ordering applies: Deny Unless is processed before Allow If.

It is evaluated against the user interacting with the AI, or a system user if no interactive context is present.

Global scope vs. custom scope

Global Scope

Covered out of the box

Two wildcard Allow If ACLs from the Flow Designer Designer Model app cover all flows and flow actions — no action needed.

Custom Scope

Manual configuration required

The global wildcards do not extend to custom application scopes. You must explicitly create invoke_from_ai ACLs for your scoped flows.

Most common failure cause: Building flows in a custom scope without creating the corresponding ACL. The global wildcards do not help — scope-specific ACLs are always required.

3. What it Does NOT Cover

These execution paths are not evaluated through invoke_from_ai — standard ACL rules apply instead:

Traditional Virtual Agent topics

UI Actions

Subflows run directly from Flow Designer

Flow Triggers

Direct system or user execution

4. How to Configure

Navigate to All > Access Controls > New and set the following fields:

Field	Value
Type	flow or flow_action
Operation	invoke_from_ai
Name	Flow sys_id or internal name — use * to cover all flows in scope
Decision Type	Allow If — add role or condition checks as needed
Application	Must match the scope of the target flow — most commonly missed field

5. Troubleshooting Checklist

1 Is the flow in a custom scope?
   If yes, a manual invoke_from_ai ACL is required — OOB wildcards don't apply.

2 Does the ACL's Application field match the flow's scope?
A global-scoped ACL cannot cover a custom-scoped flow.

3 Is the ACL Name correct?
Use the exact flow internal name or sys_id, or * for a scoped wildcard.

4 Is the flow actually invoked by AI?
If triggered directly by a user or system, invoke_from_ai is never evaluated.

5 Don't trust the Now Assist UI warning ("This subflow has no ACL")
It is static and does not reflect actual ACL state. Verify in Access Controls directly.

#servicenow #agentic-ai
#now-assist #acl #invoke_from_ai #flow-designer #security #best-practices

If this article was useful, please consider marking it as helpful. Feedback is always welcome.

Kind regards — Luis Estéfano