Custom Now Assist Skill not executing after adding custom role in Security Controls (Zurich)

BhavaniYamsani · 3 weeks ago

Hi Everyone,

I am working on ServiceNow Zurich using Now Assist Skills in AI Agent Studio.

I created a custom Now Assist Skill for Security Incident Correlation because the out-of-the-box skill does not meet my use case. The custom skill works as expected and returns the expected results.

However, I have a new requirement from the client. They want certain confidential fields to be visible only when the logged-in user belongs to a specific custom role or custom group.

To achieve this, I added the custom role under the Security Controls section of the skill. After doing so, the skill no longer executes. However, if I assign the sn_si.read role in the Security Controls, the skill executes successfully.

The fields that need to be displayed are not limited to the Security Incident table. They are also retrieved from related tables such as:

Incident
Vulnerable Item
Problem
Change Request

I'm trying to understand whether the issue is related to cross-table access, ACL evaluation, or how Security Controls are enforced for custom skills.

I have a few questions:

Does the role configured in the Security Controls section need read access to every table and field referenced by the skill?
Are there any additional ACLs or Now Assist-specific permissions required for custom roles when using AI Agent Studio skills?
Is there a recommended approach for restricting confidential fields based on user roles or groups without relying on field masking or using a Script Tool after prompt execution?

Has anyone implemented a similar requirement or faced this issue? Any suggestions, best practices, or documentation would be greatly appreciated.

Thank you

Yamsani Bhavani

ServiceNow Developer - SecOps, IRM, NowAssist, Custom Applications

Vikram Reddy · 3 weeks ago

Hi @BhavaniYamsani,

Assuming your skill is still running as the "Dynamic user" (the default in AI Agent Studio, not a preconfigured AI user), here's why swapping in the custom role breaks it: the role in Security Controls is just an invocation gate, who is allowed to discover and run the skill. It doesn't grant that role any data access. sn_si.read works because it already carries baked-in ACL grants across sn_si_incident and the related SecOps tables. Your new custom role starts with zero ACL entries anywhere, so once the skill's tools try to query Incident, Vulnerable Item (sn_vul_vulnerable_item), Problem, or Change Request, the ACL evaluation against the invoking user (or the masked role set, if role masking is enabled) fails and the skill has nothing to return.

Before assuming it's a Now Assist bug, verify each of these:

ACLs on sn_si_incident, incident, sn_vul_vulnerable_item, problem, and change_request all list the new custom role (or a role it inherits) on the read operation, at both table and field level for the confidential fields.
Role masking (Zurich Patch 4+) isn't stripping the custom role out of what actually propagates to the tool's ACL check, since it restricts execution to a subset of the invoking user's real roles.
Run-as entity for the skill/agent, Dynamic user vs AI user, since an AI user needs the custom role directly assigned to it, not just referenced in Security Controls.
Field-level ACLs on the confidential fields specifically, rather than relying only on the table-level role, since that's the supported native way to hide fields per role without a post-prompt script tool.

Once the custom role actually has read ACLs on every table the skill's data resources hit, it should execute the same way sn_si.read does.

References

Thank you,
Vikram Karety
Octigo Solutions INC