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.

6. Typical Error to Watch For

When invoke_from_ai ACLs are missing or misconfigured, the agent does not receive a clean error — instead it silently loses access to its available actions, and the LLM starts producing downstream failures. These are the patterns to recognise in AI Agent Studio logs and the agent execution trace.

FATAL ERROR Empty Action List

Observation : Fatal Error: You have chosen Empty list of Action(s) i.e. [].
This is Strictly Forbidden, always come up with an actionable list of Actions
deriving strictly from <agent_instructions> or <mission>.

What it means: The agent resolved zero available actions for its current step. This happens when the underlying flow or flow action is inaccessible due to a missing invoke_from_ai ACL — the action simply does not appear in the agent's permitted action set, so it has nothing to execute. The LLM interprets this as a constraint violation and flags it as fatal.

TOKEN LIMIT Execution Limit Exceeded

Thought : I have encountered a fatal error
(Error: The response generated by you has exceeded the token limit set within the system.
Keep the content within Thought, Observation and Action Reasoning brief
and short in the JSON response to keep the JSON format complete.
If absolutely required, keep values for Action Inputs short in terms of the content
to keep the JSON response complete. Make sure to keep the token count for your responses
strictly within this limit while still generating a full, parsable JSON response: 4096 tokens.)
with the ReAct output parser and would like to retry the same execution.

What it means: With no valid action available, the agent could enter a retry loop — repeatedly attempting to find a path forward, failing each time, and consuming tokens on every iteration. Eventually it hits the platform's execution or token limit and terminates. This is a secondary symptom of the ACL issue, not the root cause — but it is often what surfaces first in logs and is frequently misdiagnosed as a prompt engineering problem.

Pattern to recognise: If your agent works correctly in global scope but fails in a scoped app — producing empty action lists or hitting token limits with no clear prompt reason — check invoke_from_ai ACLs before spending time on prompt rewrites. The fix is a configuration change, not a prompt change.

#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