ServiceNow Now Assist for ITSM: Security and Access Design

Role Model and Access Control Design

Now Assist accesses ServiceNow data to make recommendations to users. Access controls must ensure that the assistant respects user permissions. A user should not receive recommendations based on data they cannot normally access. The assistant should not process requests that involve confidential data unless the user has permission to access that data. Role-based access must be carefully designed so assistance works correctly for all user types.

The assistant might have its own service account that retrieves data from the platform. This service account must be restricted to retrieve only data that should be available to users who will see assistant recommendations. Excessive service account permissions create security risks. Insufficient permissions cause the assistant to provide incomplete or incorrect recommendations.

Least Privilege and Segregation of Duties

Now Assist implementation should apply least privilege principles. The assistant should be able to read information needed to make recommendations but should be restricted from making changes without user approval. The assistant should not be able to escalate its own permissions or bypass approval controls. Segregation of duties means that systems that should not be modified by the same account should not be accessible to the assistant.

Some organisations implement the assistant with read-only access to data retrieval but require human approval before the assistant can suggest changes or assignments. This approach reduces risk while still providing value through information retrieval and categorisation.

Audit Trails and Compliance Evidence

All assistant activity should be logged so that organisations can audit what data the assistant accessed, what recommendations it made, and what users did with those recommendations. Audit logs provide evidence that the assistant is functioning correctly and not accessing data inappropriately. Audit logs support incident investigations when questions arise about what happened and when.

Compliance frameworks may require specific logging and audit evidence. Healthcare organisations need to demonstrate that the assistant has not accessed patient information inappropriately. Financial organisations need to demonstrate that the assistant has not accessed sensitive financial data inappropriately. Audit logging must support these compliance requirements.

Integration and Data Flow

The assistant must have secure integration pathways to access the data it needs. Integration should happen through authenticated service accounts with restricted permissions. Data should flow through appropriate APIs rather than through direct database access. Integration design should enforce security at the architectural level rather than relying solely on access controls.

Data Privacy and Sensitive Information Protection

The assistant should be configured to handle sensitive information appropriately. Personal identifiable information, payment information, and other sensitive data should be protected from being logged inappropriately or displayed in places where users without permission might see it. Configuration should specify what types of information the assistant can process and how it should handle sensitive data.

Review and Validation of Security Design

Security design should be reviewed by security teams before the assistant goes into production. Reviewers should validate that access controls are appropriate, that audit logging is sufficient, and that sensitive data is protected. Security reviews prevent deployment of assistants with unintended security vulnerabilities. Regular re-review after deployment ensures security posture remains appropriate as usage patterns change.

Monitoring and Testing Ongoing Compliance

After initial security design, ongoing monitoring ensures that security posture remains appropriate. Regular reviews of service account permissions verify that the principle of least privilege is maintained. Periodic audit of access logs ensures that data access patterns are appropriate. Security testing before major updates validates that security controls remain effective.

Incident Response and Security Events

If security issues are discovered with the assistant, incident response procedures should be established. Can the assistant be quickly disabled if problems are found? Can problematic recommendations be rolled back? Having procedures in place before problems occur ensures fast response when issues are discovered.

Documentation and Compliance Artifacts

Security design decisions should be documented thoroughly. What access controls were implemented and why? What audit logging was configured and why? What testing was performed to validate security posture? Documentation supports compliance audits and helps teams understand security decisions made during implementation. Documentation also supports future modifications by explaining the rationale for current design.

Choose the identity the assist runs under before anything else

The first security decision is not about encryption or logging. It is about whose permissions the assist uses when it reads a record. There are broadly three models, and each one produces a different failure. If the assist runs as the requesting user, it can only show what that user could already open, which is the safest default but can leave suggestions thin for people with narrow roles. If it runs under a broad service account, it can surface content the requester should never see, and the security review then has to prove a negative across every table. If it runs under a dedicated account with a curated read scope, it can be tuned for usefulness, but that scope becomes a standing piece of privileged access that someone must own and re-certify.

Whichever model you choose, write it down with the reason. The reason is what the next person will need when the scope is questioned.

A review sequence for the access design

A review that starts with the feature list tends to miss the data paths. Start with the data and work outward. Working through the steps in order is what usually brings the real exposure to the surface before go-live.

1. List the tables and fields the assist can read under the chosen identity, including fields reached through references. A reference field is a common route to data that looked out of scope.
2. Mark the fields that carry personal, financial or health information, and decide for each whether it may appear in a suggestion, in a summary, or in neither.
3. Confirm the assist cannot write to any table that the requesting user could not write to, and that any proposed change still needs a human to accept it.
4. Trace where the assist’s inputs and outputs are stored, including any interaction log, feedback record or telemetry the feature creates, and apply the same field rules to those stores.
5. Run negative tests: a user with a narrow role asks for a suggestion about a record they cannot open, and the test passes only if nothing from that record appears.
6. Check the decommissioning path: how the identity is disabled, how its scope is removed, and how the assist is switched off without leaving suggestions cached on screens.

Logs that record the decision without copying the data

Audit trails are essential, and they are also a common way to create a second copy of sensitive content. An interaction log that stores the full record text, the prompt and the suggestion gives an investigator everything, and it also means the log now needs the same access control as the original table. A more defensible pattern is to log identifiers, the suggestion type, the confidence band, whether the suggestion was accepted, edited or rejected, and the user identity. That is usually enough to reconstruct what happened and to tune the feature, without replicating the personal data inside the record.

Agree the retention period for those logs with the same people who set the record retention policy, not with the team that built the feature. If the two periods differ, the logs will outlive the records they describe, which auditors often flag.

When the security review should stop the rollout

Some findings are not configuration issues to be tidied up after launch. A suggestion that reveals restricted content to an unrelated role is a stop. So is a service account with write access that nobody can justify, or a log that copies sensitive fields into a table with wider read access than the source. In each case the rollout pauses, the scope is corrected, and the negative tests are run again before the feature returns. Treat the first negative test that fails as a reason to slow down, not as a bug to patch and forget.

Questions security reviewers ask after go-live

How often should the access scope be re-certified?

Quarterly for the first year, then at least annually once the scope has stopped changing. Each certification should compare the scope with the feature list. A table that was added for one experiment and never removed is a common finding at this stage.

Can agents see that a suggestion was generated from a restricted article?

Only if the design allows it. A better default is that a suggestion is shown only when its source is visible to the viewer, and that the reason text describes the category of the suggestion without naming the hidden source. Confirm the behavior in the negative tests rather than assuming it.

Does a vendor patch change the access model?

It can. Release changes sometimes add new data sources or new default permissions to the assistant’s features. Treat every platform upgrade as a trigger for a short access review, and compare the new scope with the last certified one before the upgrade reaches production.

Should the security team own the assist’s configuration?

No. The security team should own the review and the sign-off. Configuration belongs to the platform owner, so that the reviewers can check decisions made by someone else rather than approving their own work.

Taking the access design to review

The design is easier to defend when the people who run the service desk and the people who review access sit at the same table. Requests from the self-service channel raise their own access questions. The service portal guide describes that interface.