Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Sensitive Records Do Moveworks Agents Access?

Moveworks agents, now part of ServiceNow, reach whatever the dedicated service accounts behind each connector can read, which for HR, IT and knowledge systems means employee tickets, cases, profiles and knowledge articles at the table level. Check each connector's documented table scope and service account rather than the end user's permissions.

A dedicated connector node links four stacks of employee, case, and knowledge records.

Moveworks agents, now part of ServiceNow, reach whatever the dedicated service accounts behind each connector can read, which for HR, IT and knowledge systems means employee tickets, cases, profiles and knowledge articles at the table level. Check each connector's documented table scope and service account rather than the end user's permissions. ServiceNow completed its acquisition of Moveworks on December 15, 2025, folding its assistant, enterprise search and Reasoning Engine into the ServiceNow AI Platform as an AI-native front door for employee engagement (ServiceNow, 2025). The integration model predates the acquisition and still defines what agents can read: a dedicated account per back-end system with read access to named tables (Moveworks, 2026), so the record set is fixed by connector configuration, not by who is asking. That is the question an audit of sensitive data access across enterprise applications has to answer first: what can the integration identity see? This page traces how the agents connect to employee systems, which record types a connector's scope covers, what the documented controls govern, how standing access differs from a user's permissions as governance moves to AI Control Tower, how to measure reach, and which claims to refuse.

Key findings

  • Moveworks' access requirements for a knowledge-base connector state that the account must have read access to a named list of tables through a dedicated production account, which fixes the agent's reach at the connector rather than at the user (Moveworks, 2026).
  • End-user access is governed by launch rules administrators use to choose who can use a plugin, a control on who may ask rather than on what the service account can read (Moveworks, 2026).
  • Strict log redaction, which prevents exposure of private and user data to developers, is applied automatically for plugins launched to ten or more users, so smaller launches depend on the setting being chosen (Moveworks, 2026).
  • The plugin critique checklist requires confirmation for destructive actions, which places the human check at the destructive write rather than at the read (Moveworks, 2026).
  • ServiceNow's AI Service Graph Connector for Moveworks discovers and imports AI assets from Moveworks environments into ServiceNow AI Control Tower, which is where inventory and governance of those agents is moving (ServiceNow, 2026).
  • A standing identity with broad read access to employee systems is the profile CISA's insider threat guidance treats as needing monitoring, whether it belongs to a person or an integration (CISA, 2020).

How do Moveworks agents connect to the systems that hold employee records?

Through dedicated service accounts, one per connected system, each granted read access to specific tables. Moveworks' access requirements for connecting a ServiceNow instance as a knowledge-only source are explicit: the account must have read access to a listed set of tables, starting with the knowledge table, and the connection runs through a dedicated production account (Moveworks, 2026). The same pattern, an integration identity with table-level read grants, is how the product reaches ticketing, HR and identity systems; the table lists for those connectors are not described in the pages reviewed.

The consequence is that the agent's reach is set when the connector is configured, by whoever grants the service account its roles, and it does not change with the person asking. Consider a single record type: an HR case in a human resources system, carrying the employee's name, manager, the case category (a leave request, an accommodation, a grievance), free-text notes from the HR partner and attachments. If the HR connector's service account can read the case table, the agent can read every case in it. The agent may be designed to answer only the requesting employee's own questions, but the read grant underneath is to the table.

This is what the distinction between standing access and per-request access means in practice. Zero trust guidance describes evaluating each access at the time of the request, for the specific resource, rather than relying on a grant made in advance (NIST, 2020). A service account with table-level read is a grant made in advance. The question for the organization is what tables each of its connectors was granted, and the answer is in the connector configuration, not in any agent's description of itself.

Which sensitive record types fall within a connector's scope?

Whatever tables the service account can read. For an IT service management connector, incidents, requests and work notes, carrying employee names, device identifiers and whatever the employee pasted into the ticket, including credentials and screenshots. For an HR connector, cases and employee profiles: compensation, leave balances, home addresses, dependent information, performance notes. For a knowledge connector, articles, occasionally holding internal procedures or configuration details never meant for every employee. For an identity connector, group memberships and account attributes.

The knowledge-only access requirements show how the scoping works: a named list of tables, read access to each, through one account (Moveworks, 2026). The same mechanism that makes the scope auditable, a finite list, makes it blunt. Table-level read does not distinguish a routine password-reset ticket from an incident in which an executive's mailbox was compromised, or a leave request from a grievance. The grant is to the table.

OWASP's sensitive information disclosure entry describes the resulting risk: a model given access to data surfaces it in response to a request that should not have elicited it (OWASP, 2025). On the HR case record, an employee asking the assistant about leave policy should receive a policy answer; an agent with table read on cases could, depending on how its retrieval is constrained, also surface the HR partner's notes on a colleague's case. How retrieval is constrained to the requesting user's own records, for each connector, is not described in the pages reviewed, and it is the question a buyer should ask about every connector that touches employee data.

What do Moveworks' documented access controls govern, and what do they leave open?

Dimension Moveworks, per its documentation What a buyer should verify
Back-end access Dedicated production account with read access to named tables The table list granted to each connector's service account
Who can invoke Launch rules choose who can use a plugin Whether launch rules narrow the read, or only who may ask
Log exposure Strict redaction keeps private and user data from developers; automatic at ten or more users The setting for plugins launched to fewer than ten users
Destructive actions Confirmation is required for destructive actions (critique checklist) Which actions are classed as destructive and what the confirmer sees
Governance inventory AI Service Graph Connector imports Moveworks AI assets into AI Control Tower Whether the import carries connector scopes and grants
Per-user retrieval scoping Not described in the pages reviewed How results are limited to the requesting employee's own records

Three documented controls surround the service account. Launch rules let administrators choose who can use a plugin (Moveworks, 2026); they govern the audience. Strict log redaction keeps private and user data from developers and is automatic for plugins launched to ten or more users (Moveworks, 2026); it governs who among builders can see what employees typed. The plugin critique checklist requires confirmation for destructive actions (Moveworks, 2026); it governs the write.

None of the three narrows the read; the grant to the HR case table is untouched. The threshold matters: a pilot plugin launched to eight people, common for the HR workflows that most need redaction, falls below it and depends on an administrator choosing the setting.

How does standing service-account access differ from a user's own permissions, and what is changing under ServiceNow?

In a permission-mirroring design, the agent reads as the user and can reach no more than the user could. In a service-account design, the agent reads as the integration, and the user's own permissions are a separate layer applied, if at all, at retrieval. Moveworks' documentation describes the integration layer and the audience layer. How the two combine for a given query, so that an employee receives only records they could open directly, is not described in the pages reviewed.

That gap is why insider threat guidance applies to integration identities as much as to people. CISA's guide treats accounts with broad standing access to sensitive systems as requiring monitoring, baselining and periodic review of what they can reach (CISA, 2020). A service account that can read every HR case is such an account. It is also, under prompt injection, the identity an attacker inherits: an instruction planted in a ticket is executed by an agent reading with the connector's grant, not the attacker's permissions.

The ServiceNow acquisition changes where this is governed. ServiceNow's Zurich release documentation describes an AI Service Graph Connector for Moveworks that discovers and imports AI assets from Moveworks environments into ServiceNow AI Control Tower (ServiceNow, 2026). An inventory is the precondition for governance. Whether the import carries each agent's connector scopes and service account grants, so that the Control Tower view answers the title question, is not described in the pages reviewed. The acquisition announcement frames Moveworks as a front door for employee engagement; the service accounts behind that door remain the organization's to audit.

How should an organization measure what its Moveworks agents can reach?

Start from the connectors, not the agents. List every connected system, the service account used, and the tables or objects it has been granted. For each table, classify the records it holds: routine, sensitive, regulated. The sum of sensitive and regulated tables across connectors is the agent reach figure, and it is available from the back-end systems' own role assignments without touching Moveworks at all. Compare that figure with what the AI Control Tower inventory shows after import, and record any difference.

Then test one agent against one record. Create a test HR case or IT ticket with known content, including a sensitive note, and have an employee who should not be permitted to see it ask the assistant questions that approach it. Record whether any part of the note surfaces. Repeat with a request that should trigger the confirmation for a destructive action and observe what the confirmer sees. Harvard's guidance on managing generative AI systems recommends this kind of institution-specific review, classification first and then controlled testing of what the system returns (Harvard University, 2026).

Finally, check the redaction setting for every plugin launched to fewer than ten users, since those fall outside the automatic threshold. The output is three artifacts: a connector scope table, a test log, and a redaction settings list. An AI control record that captured every screen the agent read and every action it took would make the second artifact a byproduct of operation rather than a separate exercise; the pages reviewed do not describe one, so the exercise is manual.

What does a governed environment change?

A governed environment changes the question from what the connector's service account can read to what the model receives when it reads it, which the documented Moveworks controls do not address. The integration model is a dedicated production account with read access to a named list of tables (Moveworks, 2026), and the launch rule governs who may ask, not what the account reaches. An agent running directly on those systems holds every field in scope; in the environment, the sensitive fields arrive as tokens.

This class of control works at the rendered screen. Employee identifiers, case notes and profile fields are replaced with consistent tokens before any model reads the page, and the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action, such as a case update. A named person confirms what is tokenized and approves consequential actions. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This supplies the test the previous section asked for on a record the vendor did not prepare: the exported record shows what the model saw, field by field, and where each token resolved. It also bounds what the model behind a standing identity with broad read access to employee systems receives, the profile CISA's insider threat guidance treats as needing monitoring (CISA, 2020). The service account's grants, the redaction threshold and per-user scoping still need to be verified from the configuration.

The control does not alter the connectors, the service account's permissions or the model, and it covers the rendered page, not the retrieval behind it.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Where a service-account design fixes the agent's reach at the connector and leaves the model to read whatever the table grant returns, RedactSure's design governs what the model sees on each screen regardless of the identity behind it. Work runs in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so the employee name, case notes and identifiers on an HR case or IT ticket appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, a model RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own HR or IT service workflow would show, record by record, which sensitive fields a connector-scoped agent would have read and which the model saw as tokens instead, with the AI Control Record as the evidence. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Moveworks' published documentation: the access requirements for a ServiceNow knowledge-only connector, the security and privacy settings page, the Agent Studio end-user access control page and the plugin critique checklist. It draws on ServiceNow's December 2025 acquisition announcement (vendor press release) and the Zurich release documentation for the AI Service Graph Connector for Moveworks (vendor documentation), on CISA's Insider Threat Mitigation Guide and NIST Special Publication 800-207 (official guidance), on OWASP's Top 10 for LLM Applications entry on sensitive information disclosure (industry standard), and on Harvard University's best practices for managing generative AI systems (institutional guidance). All sources were read as of October 16, 2026.

No hands-on testing of Moveworks, ServiceNow or any other named product was performed. Where this page says a capability is not described in the pages reviewed, it means the specific pages listed below do not describe it, which is not a statement that the capability is absent; connector table lists other than the knowledge-only page were not reviewed. Vendor features change, and the integration of Moveworks into the ServiceNow AI Platform is under way; the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The HR case, IT ticket and knowledge article examples describe record types, not any organization; no customer or prospect is described.

Whether a given Moveworks deployment, its connector grants, its launch rules and its redaction settings meet an organization's obligations for employee and customer records is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Moveworks' documentation locates the answer at the connector. Each connected system is reached through a dedicated account with read access to named tables, so the sensitive records an agent can access are the rows in those tables: HR cases, IT tickets, employee profiles and knowledge articles, with whatever their free-text fields contain. Launch rules govern who may ask, strict log redaction governs who sees the logs once a plugin reaches ten users, and confirmation governs destructive writes; none of the three narrows the read. Under ServiceNow's ownership, the AI Service Graph Connector brings Moveworks agents into AI Control Tower's inventory, which is where governance is heading. A render-layer design of the kind RedactSure describes would govern what the model sees regardless of the service account's grant. The test is to name one agent and one task, pull the table list for the service account behind it, and ask an employee who should not see a test record to try.

Frequently asked questions

Does Moveworks read data as the employee or as a service account?

As a service account, according to the access requirements documentation, which describes a dedicated production account with read access to a named list of tables for each connected system. The employee's own permissions are a separate layer; how they are applied at retrieval so that a person receives only records they could open directly is not described in the pages reviewed. A buyer should ask for that mechanism connector by connector, since it decides whether table-level read becomes employee-level exposure.

What sensitive records sit inside a typical Moveworks connector scope?

Whatever the granted tables hold. For IT service management, incidents and requests with work notes, device identifiers and anything an employee pasted into a ticket. For HR, cases and profiles carrying compensation, leave, addresses and performance notes. For knowledge, articles that occasionally contain internal procedures or contact details. The grant is to the table, so a routine row and a highly sensitive row in the same table are equally readable by the agent's account.

Do launch rules limit what a Moveworks agent can access?

Launch rules limit who can use a plugin; Moveworks' Agent Studio documentation describes administrators using them to choose the audience. They do not change the tables the agent's service account can read. An agent launched to a small group still reads with the full connector grant. Launch rules are an audience control and should be reviewed alongside, not instead of, the service account's role assignments in each back-end system.

Who can see what employees type to a Moveworks agent?

Moveworks' security and privacy settings describe strict log redaction that prevents exposure of private and user data to developers, applied automatically for plugins launched to ten or more users. For plugins below that threshold, the setting depends on an administrator's choice. Pilot groups for sensitive HR workflows are often smaller than ten, so check the redaction setting for every small launch rather than assume the automatic protection applies.

How does the ServiceNow acquisition change Moveworks data access?

ServiceNow completed the acquisition on December 15, 2025, and its Zurich release documents an AI Service Graph Connector that imports Moveworks AI assets into AI Control Tower for inventory and governance. The connectors to HR, IT and identity systems still run on their own service accounts; the pages reviewed describe no change to that model. Whether the Control Tower import carries each connector's table grants is not described, so the scope audit remains the organization's task.

How should an organization audit its Moveworks agents' reach?

List every connector, its service account and the tables granted, classifying each table as routine, sensitive or regulated; that list is available from the back-end systems' role assignments. Then test one agent with a known test record and an employee who should not see it, and check the redaction setting on every plugin launched to fewer than ten users. A governed environment that records every screen the model read as tokens, as RedactSure's design does, turns the test into a standing record.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.