Best practices for monitoring and restricting SDK / pro-code access for ITIL (nonAdmin) users ?

[Vivek Verma]

Hi Community,

We are starting to use the ServiceNow SDK (`@servicenow/sdk` / now-sdk) for development, primarily in Global scope using Global Applications.

### Current Setup

- Developers authenticate via `now-sdk auth` (browser-based OAuth flow → token pasted into the terminal).
- The session is tied to the authenticated ServiceNow user and respects their roles + ACLs.
- We understand that an ITIL user who sets up the SDK with their own account can query and act on records (e.g. incidents) according to their privileges.

### Concern
We intentionally give ITIL users interactive UI access.
However, we do **not** want them to use pro-code tools (now-sdk / Table API / external IDEs) to perform the same (or broader) actions in a non-interactive way — for example creating dashboards, bulk querying, or other configuration changes that their role technically allows.

### What we already understand
- The SDK runs with the privileges of the authenticated user (no privilege escalation).
- Transaction logs (`syslog_transaction` with `type=rest`) can be used for monitoring.
- Options we are aware of:
- Activating the Table API ACL and removing `snc_platform_rest_api_access` from the ITIL role
- REST API Access Policies (role / group / IP based)
- REST API Auth Scopes and Machine Identity Access Controls
- Tightening table ACLs on sensitive objects

### Questions
1. What is the **recommended** way in current releases to allow ITIL users full interactive UI access while restricting or blocking their ability to use the Table API / now-sdk / external pro-code tools?

2. Are there any known side-effects of removing `snc_platform_rest_api_access` from ITIL (does it break legitimate platform features for those users)?

3. What is the best practical approach for **monitoring** who is using now-sdk or making REST calls from external tools (beyond basic transaction logs)?

4. For Global Application development with the SDK, is creating a dedicated Global Application (with its own Sys ID in `now.config.json`) still the official recommended pattern?

Any real-world experiences, recommended configurations, or official guidance would be highly appreciated.

Thank you!

[mugi-san]

Hello, @Vivek Verma .

Regarding point 1, as you noted, it is appropriate to handle this using REST API policy configurations (such as sys_authentication_policy).
In my personal opinion, creating custom roles or groups to manage these permissions makes them much easier to administer.
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2297612

Regarding point 2, the following knowledge base article serves as a helpful reference:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2976437

Regarding point 3, while it might be a somewhat passive or indirect suggestion, one option would be to develop a new Scripted REST API and build it so that it logs only the required detailed information to syslog or a custom table as needed.

Regarding point 4, it seems that this has only recently become supported in the latest SDK version. Whether it should be created in Global can be evaluated in the same way as development without using the SDK.
https://www.servicenow.com/docs/r/application-development/servicenow-sdk/create-application-now-sdk....

https://www.servicenow.com/community/forums/forumtopicprintpage/board-id/developer-forum/message-id/...

regards,

[Vivek Verma]

Hey, thanks for the detailed response. Honestly, at this point, I'm just trying to figure out if I'm not changing anything on the platform, then the ServiceNow architecture really lets non-admin users get into the instance using the SDK and IDE.

And if ServiceNow is allowing it, then I think there must be a good reason behind it.

[mugi-san]

I believe that executing the deployment command to deploy individually developed apps to the instance requires the Administrator role. In my personal opinion, anyone handling an administrative user account must fulfill their fiduciary duty.

regards,