Set up a read-only connection

1. Create a read-only integration user

1. User Administration → Users → New. Set User ID e.g. svc_instanceguard_ro. Check Web service access only and Internal Integration User. Make sure it is Active.
2. Assign snc_read_only. This makes the account read-only at the platform level — writes are blocked by ServiceNow itself, regardless of any other role. We check for this and show it as the strongest guarantee.
3. Grant the read access it needs to see the configuration being audited (ACLs, business rules, script includes, roles, recent changes). Because snc_read_only blocks every write, it is safe for the account to also hold broad read roles — including admin — for coverage; writes remain impossible. We refuse a connection only if the account is write-capable without snc_read_only enforcing read-only.
4. If your instance restricts REST access by role, also grant snc_platform_rest_api_access.

2. Register an OAuth app (client_credentials)

Requires Washington DC or later for inbound client_credentials. On older releases, contact us and we'll switch the connection to a supported mode.

1. System OAuth → Application Registry → New. On current releases choose the New Inbound Integration Experience → OAuth – Client Credentials grant; on older ones use Create an OAuth API endpoint for external clients. Both work.
2. Name it e.g. InstanceGuard. Leave the Client ID / Secret auto-generated. Do not enable “Public Client.”
3. Set the app's run-as / OAuth Application User to your svc_instanceguard_ro user. (In the deprecated UI this field may need to be added via Form Builder.) Tokens then act as that read-only user — this binding is required; without it every API call returns 401/403.
4. Confirm the system property glide.oauth.inbound.client.credential.grant_type.enabled is true (it is off by default — this is the master switch for the grant).
5. Copy the Client ID and Client Secret. The secret is shown once.

3. Let the token reach the platform APIs

On Zurich and later, OAuth clients are scoped by default and blocked from “unscoped” APIs — including the Table API InstanceGuard reads. This is the single most common setup snag, so do it up front:

1. On the OAuth app, set Scope Restriction → Broadly Scoped.
2. Add the built-in useraccount scope to the app's OAuth Entity Scopes (grants full API access, still governed by the user's roles — and your user is snc_read_only).

4. Connect

Paste the instance URL, Client ID, and Client Secret into New connection, set the integration username, and click Validate. We immediately:

• request a token via client_credentials (no password stored),
• resolve which user the token authenticates as,
• enumerate that user's roles, and
• refuse the connection if any write-capable role is present without snc_read_only enforcing read-only — surfaced as a trust signal.

Troubleshooting

If Validate fails, match the error to the fix:

• 401 on a Basic connection — the username/password is rejected. Reset the user's password (uncheck “Password needs reset”), or switch to OAuth.
• OAuth token request fails — the grant isn't enabled (step 2.4), the release predates Washington DC, or the Client Secret is wrong.
• 403 “Access to unscoped api is not allowed” — the token is scoped. Do step 3 (Broadly Scoped + useraccount). This is expected on Zurich+.
• Rejected: write-capable roles — the integration user can write. Add snc_read_only so writes are platform-blocked, or use a read-only user.