Secure Your Data (Before Your Agents Touch It)

[BriBos]

A Cybersecurity Awareness Month follow-up: from knowing your data to protecting it on the ServiceNow AI Platform 

In our last post, we made the case for knowing your data. Discovery finds the sensitive information hiding in descriptions, attachments and screenshots. Classification tells the platform what to do with it. 

Knowing is half the job. The other half is deciding who, and what, gets to touch that data, and proving it later. 

That "what" matters more every month. Your newest users are agents. They don't log in with a badge. They work through service accounts, API integrations, OAuth tokens and credentials, and they inherit whatever access those identities have. If a machine identity can read a table, every agent running behind it can too. 

This week's checklist item is simple: protect the data and the identities that reach it. Here's how that works on the ServiceNow AI platform. 

Layer 1: Access controls that deny by default 

Access Control Lists (ACLs) are the foundation of any platform security journey. Every ACL names an object (a table, a field, a record, an endpoint), an operation (read, write, create, delete, execute) and the conditions someone must meet to get through. 

Some design choices are worth knowing: 

• Conditions stack. A user can be required to hold a role, pass a security attribute, meet a data condition on the record, and satisfy a script. They must pass all of them. 

• Deny by default. An empty or invalid ACL denies access completely. An ACL with no role, attribute, condition or script, or one pointing at a role that doesn't exist, doesn't quietly open the door. 

• Granularity down to the record and field. The Applies-to setting lets you scope a rule to something like P1 incidents only, so you aren't stuck choosing between protecting a whole table and protecting nothing. 

• Table and field must both agree. For records, both the table-level and field-level rules have to pass. A permissive table rule can't override a restrictive field rule. 

• Changing the rules takes a deliberate step. Admins must elevate to the security_admin role to create or modify ACLs, so a routine admin session can't casually rewrite your access model. 

Why this matters for AI: an agent retrieves data under a user's or service's permissions. Tight ACLs, where the rules are narrow and specific, mean a summary or search result can't surface a field the requesting identity was never meant to see. Your data labels from last week tell you which fields deserve the strictest rules. 

Layer 2: Know who has access, and what they'd actually reach 

Writing good ACLs is one thing. Verifying them is another. ServiceNow AI Platform security includes tools that show you the real picture: 

• Access Analyzer and the access simulator allow you to see what a given user can actually reach, before an auditor or an incident asks. 

• Access findings and the Access management console surface risky or over-broad access in one place. 

• Security Attributes and Field Query Roles let you express access as reusable logic and control which roles can query sensitive fields at all. 

Run these against the "top 10 AI-touched tables" from last week's checklist. That's the shortest path to finding out whether your most sensitive, most agent-exposed data is as locked down as you think. 

Layer 3: Put limits on admins, too 

Powerful roles are a risk even when the people holding them are trusted. Granular admin roles allow you to split what used to be one broad "admin" into narrower responsibilities, such as who manages security configuration and who administers logging. No single role needs to see or change everything. 

This helps with least privilege, and it limits damage if an admin account is ever compromised. It also helps give you a cleaner answer when an auditor asks who could change what. 

Security Center, a centralized application that helps organizations monitor, manage, and improve the security posture of their ServiceNow instances through a central hub, supports this with a security posture score, security tasks and configuration monitoring, so you see drift before it becomes an incident. It's a free app for administrators. 

Layer 4: Don't forget the machines 

Most organizations review human access on a schedule. Far fewer review the machine identities that agents and integrations run on, and that's where the exposure grows quietly. Credentials get created for a project and never retired. OAuth apps stay active long after their owners moved on. API access ends up wider than anyone intended. 

The Machine Identity Console, part of ServiceNow Vault, puts these identities in one place. It brings security scoring, OAuth management and API access controls together, so you can see which machine identities are risky, tighten them, and retire the ones nobody uses. 

If NHIs are your new workforce, this is the console that can help answer who they are and what they can do. 

Layer 5: Help protect the data itself with ServiceNow Vault 

Access controls decide who gets in. ServiceNow Vault helps protect the data even if something goes wrong: 

• Encryption with keys you control. Encrypt sensitive fields at rest and manage your own keys, with the labels from last week's classification driving which fields get protected. 

• Anonymization. Mask or anonymize personal data, so non-production copies and downstream uses don't carry live PII. This also helps to support GDPR "right to be forgotten" requests. 

• Zero Trust Access. Add session-level controls on top of role-based access, so a valid login alone isn't enough to reach your most sensitive data. 

• An audit trail you can export. The Log Export Service sends security logs to your SIEM, so "prove it" doesn't mean digging through the instance. 

Platform security controls come built in. ServiceNow Vault is for organizations that want to go further: visibility, keys they own, policies that follow the data, and evidence on demand. 

Your "secure your data" checklist for October 

1. Review ACLs on your top 10 AI-touched tables. Confirm that every sensitive field has a role, condition or security attribute behind it, and no wide-open rules. 

1. Run Access Analyzer on a few high-privilege and service identities to see what they can really reach. 

1. Audit your machine identities. Open the Machine Identity Console, sort by risk score, and retire or restrict the bottom of the list. 

1. Split a broad admin role. Identify one place where granular roles can replace blanket admin access. 

1. Check your Security Center posture score and work on the top security tasks. 

1. Tie protection to classification. Make sure fields labeled PII, PHI or Restricted are encrypted or anonymized as policy requires. 

The bottom line 

Cybersecurity Awareness Month usually asks people to protect their passwords. This year, extend that to everything that signs in on your behalf. AI agents move fast, and they will use whatever access they're given. 

Know your data. Then make sure the right people, and the right machines, are the only ones who can reach it. In our next post, we'll look at what securing AI itself looks like.