ServiceNow Virtual Agent: Security and Access Design

Virtual Agent security design means deciding what data a conversation may contain, who can configure the agent, how conversations are logged and escalated, and who can view performance metrics. Passwords should never be requested in a conversation, so authentication is verified separately.

Data Sensitivity and Conversation Content

Virtual Agent conversations may contain sensitive information—passwords during password resets, account numbers, personal health information in healthcare contexts, or confidential business data. Establish policies about what data is allowed in conversations. Generally, passwords should never be requested or visible; authentication should be verified separately. Account numbers and other identifiers should be masked or abbreviated in logs. Personal or health information should be encrypted in transit and at rest.

Access Control for Agent Configuration

Restrict who can configure Virtual Agent. Only experienced admins should design agent behavior, define conversation flows, or integrate with backend systems. Subject matter experts should review agent responses for accuracy before publishing. Establish change control so agent changes go through review and approval, not ad-hoc modifications that could break functionality or leak sensitive information.

Audit Logging and Compliance

ServiceNow logs all agent conversations for training, quality assurance, and compliance purposes. Configure logging to capture agent responses, user feedback, and escalations. Retain logs long enough for regulatory requirements in your industry—healthcare and finance have longer retention requirements than most sectors. Ensure logs are encrypted and access is restricted to authorized staff.

Handling Escalations to Human Agents

When the virtual agent cannot resolve an issue, it escalates to human agents. Context passed to human agents should include what the agent tried and what information the user provided. But do not pass conversation history that would expose the user to viewing sensitive data inadvertently. Design handoff to balance context for human agents with data protection for users.

Privacy and Data Minimization

Collect only information needed to resolve the user’s request. Do not prompt for unnecessary details. Do not store information longer than needed for resolution. Provide users transparency and control: tell them what data is collected, how it is used, how long it is retained. Comply with privacy regulations in your jurisdiction and industry.

Role-Based Access to Metrics

Agent performance metrics should be viewable by agent managers and appropriate support staff, but not all employees. Performance data about response quality, escalation rates, and resolution effectiveness should be restricted to those needing it for performance management or improvement initiatives. Establish role-based access to dashboards and reports.

Monitoring Agent Behavior and Quality

Monitor Virtual Agent performance and behavior: response accuracy, user satisfaction, escalation rates. Review sample conversations to ensure the agent is providing appropriate responses and not sharing sensitive information inappropriately. Use monitoring data to identify retraining needs and to catch problems before they impact many users. Escalation patterns can indicate when the agent is reaching the limits of its capabilities.

Incident and Data Classification

Classify conversations by sensitivity: standard conversations have no special restrictions, sensitive conversations may contain patient health information or financial data requiring encryption and restricted access, confidential conversations contain proprietary business information. Classification drives how data is handled, how long it is retained, and who can access it. Train staff on how to classify conversations appropriately.

Escalation Security and Access Control

When Virtual Agent escalates to human agents, ensure context is passed securely. Sensitive data should not be exposed to unauthorized users. Implementation should use role-based access control so agents only see escalation details appropriate to their role. Background information needed for agents to help users should be available, but unrelated sensitive data should be masked or omitted.

Role-Based Conversation Handling

Different roles may need different access to Virtual Agent conversations. Administrators should be able to review all conversations for quality and compliance. Managers might review only their team members’ escalations. Support agents should see only conversations they are escalating or that require their response. Use role-based access control to ensure conversations are visible only to appropriate staff. This protects user privacy while ensuring necessary oversight.

Map the data each topic collects before writing the access rules

Access design for a conversational agent starts with the conversation, not with the roles. Users type what they believe is relevant, and that often includes material nobody asked for: an account number pasted into a sentence, a description of a medical appointment, a name of a colleague under investigation. The first security task is to list which topics ask for which fields, which fields are free text, and which fields the agent reads back from a record. Each one needs its own answer on storage, visibility and retention. Writing the access rules before this list exists produces rules that protect the table names but not the sentences people actually type. A classification scheme for this kind of data is described in data classification workflows.

The row that says never is the one that needs an enforced control rather than a written rule. Design the topic so it does not offer a field for credentials, and test with a deliberate attempt to paste one.

Who may build, read and switch off the agent

Three kinds of access need separating. The first is the right to design topics and change the wording, which should sit with a small group that has been trained on the platform’s tooling. The second is the right to read conversation transcripts, which should be granted by purpose: quality review, a specific investigation, or a user asking about their own conversation. The third is the right to switch the agent or a topic off, which should sit with an on-call group and be logged. Mixing these rights is common in early builds, because the people who test topics are often the same people who can read everything. Separate them before the pilot, when the list of people is still short. The accountability side is in the roles and RACI guide.

• Designers change topics in a non-production copy and promote them through a reviewed change.
• Reviewers read sampled transcripts under a named purpose, and the sample is recorded.
• Operators can disable a topic and must record the reason, but cannot edit its wording.

Identity, sessions and the anonymous visitor

A topic that answers a general question can be open to anyone who reaches the page. A topic that returns anything about a person’s account must not be. Decide this per topic, not for the agent as a whole. For signed-in topics, check that the lookup filters on the signed-in identity rather than on a value the user types, because a typed reference is the easiest way to read someone else’s record. Check also what happens when a session expires in the middle of a conversation. The agent should stop returning account detail and ask the user to sign in again, rather than continuing with the last record it fetched.

A review of data flows, step by step

A security review that only reads the configuration will miss what the conversation does. Walk a real flow end to end and note every place the data appears.

1. Choose one topic that reads an account and one that creates a record, and run each with a realistic but fictional request.
2. List every table, log and notification the flow touches, including the hand-off summary and any alert text.
3. For each location, note who can read the data, the retention period, and any copy held elsewhere.
4. Try to make the flow reveal something it should not, by changing the reference, letting the session expire, and typing a credential.
5. Record each failure, its owner, and the control that now stops it, and rerun the flow before sign-off.

Retention that matches the purpose of the conversation

Keeping conversations for quality review is reasonable. Keeping them indefinitely because nobody set a rule is not. Set separate retention periods for the raw transcript, the structured fields, and the summary written for a human. The raw transcript usually has the shortest life, because it holds the most unnecessary detail. The structured fields are kept as long as the record they belong to, and the summary follows the same rule. The retention period should come from the legal and records owners, and it should be written into the topic design so that a new topic inherits it rather than bypassing it. A retention approach that holds up is covered in data retention workflow design.

Monitoring access after launch

Access controls drift. A reviewer added for a short investigation stays on the list, a designer moves teams and keeps their rights, and a new topic is added with a broader read rule than its predecessors. Schedule an access review that compares the list of people with each right against the current roles, and check that the list of topics with restricted fields has not grown without a recorded decision. Pair the review with a sample of transcripts from the sensitive topics, since a rule that looks correct on paper can still let a sentence through that nobody anticipated. The general approach to recertifying access is in access recertification.

Common questions about securing the agent

Should the agent warn users not to share sensitive details?

A short, plain warning at the point where the user is asked for a description is useful. It does not replace the design rule that the topic should not ask for the detail in the first place. A warning shows intent. Only the design prevents the data from being stored.

Can the hand-off summary be generated without the transcript?

Yes, and that is often the safer choice. A summary built from the captured fields, with the user’s own sentence quoted only where it is needed to understand the request, gives the receiver what they need without passing the whole conversation.

What should happen if a user reports that the agent exposed their details?

Treat it as a security incident. Suspend the topic, preserve the relevant records under the incident process, identify who could read the exposed data, and record the control change before the topic returns. The reporting route should be visible to users from the first day of the pilot.

Does the agent need its own service account?

It needs one, scoped to the reads and writes its topics require, and reviewed like any other integration account. Sharing a broad administrative account for convenience is a common reason an agent can read far more than its design needs.

Next step

Before the first topic that touches a personal record enters the pilot, the data map and the access list should both exist on paper.