Now Assist: A Ticket Steers One Agent into a Privileged Teammate

For categorization, publish only typed operations scoped to the initiating ticket and required fields. Do not make a broad record reader/writer reachable through a teammate. Enforce permitted record IDs and field projection at the tool/service boundary with a least-privilege backend identity; adapting the guidance's database example to ServiceNow requires actual ACL and tool-dispatch tests, not a read-only prompt. This blocks the protected-record-to-attacker-record copy path.

Keep privileged tools supervised and require human approval bound to the exact source record, destination record, fields and operation at execution. Verify sn_aia.enable_usecase_tool_execution_mode_override does not silently make all tools autonomous; native supervised mode is a useful baseline, but a fully action-bound broker contract may require platform integration. An administrator merely starting categorization is not approval to copy a protected record elsewhere.

Tenant administrators should separate agent teams/channels by purpose and sensitivity, prevent low-trust workflows from discovering high-privilege teammates, and bind allowed tools and identities to the approved published agent version. Use ServiceNow-native team, channel and tool controls; the guidance's Power Platform example is not a ServiceNow configuration recipe. Independently test discovery and execution from the published low-trust workflow after each sharing or tool change.

At the Record Management receiving boundary, a platform developer can verify a server-issued delegation context containing the administrator-initiated categorization task, requesting/receiving agents, permitted ticket and capabilities, expiry and nonce. Refuse protected-record reads or copies outside that task before dispatch. The task scope must come from trusted orchestration, not the ticket description or the peer's assertion. This is a custom/native integration requirement and does not assume ServiceNow implements the A2A wire protocol.

At the final record-service adapter, authorize the exact record, fields, operation and run using trusted task/delegation attributes. A categorization run is not allowed to read INC0000001 just because the service identity is an administrator. Enforce the same canonical object and version at the backend and test alternate direct and delegated tool paths. This requires ServiceNow-side customization or vendor support where the platform does not expose a non-bypassable hook.

A record-transfer developer can retain source-record confidentiality and permitted-reader labels on server-owned content handles, then compare them with the authoritative destination ticket ACL before copying any field. Deny transfer to an attacker-readable record when its readers exceed the source authorization. Propagate labels through every supported transformation and reject unlabeled/free-text bypasses; a regex on the destination or trusting model-assigned labels is insufficient. This controls data flow even when both read and write tools are individually authorized.

For a custom categorization workflow, isolate raw ticket reading in an unprivileged model worker with no record-management tools. Transfer only a validated finite category and server-resolved ticket ID through a narrow broker to the privileged worker; no free-text summary or proposed action may cross. Separate identities, data access and execution paths, then verify the privileged worker cannot fetch the raw description by another route. This is an architectural replacement requiring platform hooks, not a native switch or a guarantee that two models are safe.

Use a signed release-bound safety contract stating that categorization cannot read or copy unrelated protected records. Replay the source-like malicious ticket and benign controls against the actual published agent/team/tool version; an independent record observer must prove no unauthorized read or write effect. Block publication on incomplete evidence or a boundary failure. This pre-release gate requires the complete signed suite and backend observation, not a model saying it rejected the prompt.