ServiceNow AI Security: Separate Guardian, Roles, and Request Policy

A ServiceNow generative-AI request can meet several controls before a response returns. AI Guardian evaluates supported requests and responses. AI Admin Hub exposes configuration. Generative AI Controller connects ServiceNow workflows to third-party LLMs, which can move customer-instance data into another ServiceNow environment and onward to a cloud provider. I want to separate those mechanisms because a single green Guardian status icon says nothing about the exact scope of every skill or the identity carried into an external model call. It also says nothing about the policy that approved the prompt.

TL;DR

• ServiceNow AI Guardian evaluates generative-AI requests and responses for prompt injection and offensive content. It also evaluates configured sensitive topics, with different coverage for each guardrail.
• Blocking and logging behavior must be verified at instance and skill level. Current ServiceNow Otto settings apply the more protective configuration when both levels exist.
• Generative AI Controller creates a distinct data path to third-party LLMs. Document the route, provider, identity, and prompt classification for each enabled integration. Record the decision as well.
• External enforcement applies only when customer-controlled authenticated HTTP LLM traffic is deliberately routed through the policy point.

AI Guardian controls have different scopes

ServiceNow's AI Guardian documentation names prompt-injection protection and offensive-content detection as guardrail categories. It also names sensitive-topic filtering. The same page assigns different scopes to them. Prompt-injection protection covers generative-AI applications and features. Offensive-content detection applies to supported skills and workflows. Sensitive-topic filters apply to specified Virtual Agent conversational use cases.

That distinction belongs in the control register. Write one row per enabled ServiceNow Otto or Now Assist skill. Record which guardrail evaluates its request and which one evaluates its response. Then record which configuration controls the outcome. A broad label such as "Guardian enabled" hides the coverage boundary.

I would reject a production review built around that label alone. The useful evidence is a named skill, a synthetic prompt, the configured threshold, and the observed log or block result. A reviewer should be able to point at one row and explain exactly which mechanism fired.

Blocking behavior requires a skill-level test

Current Zurich prompt-injection configuration guidance describes instance-level and skill-level settings for ServiceNow Otto. When both exist, ServiceNow applies the more protective setting. The same guidance documents log and block behavior, including settings that require explicit configuration for Platform and custom skills.

Run a controlled test for each custom skill. Send a benign request first, then a synthetic injection string that contains no production data. Preserve the skill name, threshold, timestamp, and response shown to the user. When blocking is active, the generated response is replaced by a standard error message. The corresponding log should identify the event under the configured Guardian control.

The concrete artifact is a browser window beside an exported CSV, with the blocked prompt timestamp highlighted in yellow. That pair proves the user-facing outcome and the administrative record. It also catches a common review error: assuming an instance default reached a custom skill without checking its effective configuration.

Guardian logs support investigation

ServiceNow documents default logging for offensive-content and prompt-injection events. An administrator with the documented sn_generative_ai.nsa_admin role can use the AI Guardian CSV export procedure to retrieve offensive-content and prompt-injection detections. The export also includes sensitive-topic detections.

Test that export before an incident. Record who holds the role, the filter window, export timestamp, and storage location. Open the file and find the synthetic event generated during the skill test. Then correlate it with the application request and the relevant ServiceNow user session.

The export provides native evidence about Guardian detections. Authorization evidence asks an additional question: which policy permitted this authenticated person or agent to send this classified prompt toward this model route at that moment? The post-authentication gap remains when identity is established but the specific AI request receives no independent, versioned decision.

Generative AI Controller creates another boundary

The Generative AI Controller overview describes the integration surface for connecting third-party LLMs to ServiceNow workflows. ServiceNow warns that this use can transfer data out of a customer instance into a centralized ServiceNow environment and potentially onward to a third-party cloud provider.

Map that route before enabling a provider. Name the originating ServiceNow application, business user or agent, integration credential, and destination hostname. Record the selected model and data classes permitted in prompts. Add an owner for provider configuration and an owner for request policy. The route diagram should show each HTTP hop instead of one arrow labeled "AI."

Provider credentials authenticate the integration. They rarely identify the originating employee by themselves. The application therefore needs to preserve the human or agent identity and supply it to any downstream policy point. An AI gateway architecture can enforce at a customer-controlled HTTP route, provided the connector is deliberately configured to send traffic through it.

A four-part production review

A practical ServiceNow AI security review produces four sets of evidence.

• Guardrail scope: list every enabled skill and the applicable prompt-injection or offensive-content control. Record the sensitive-topic control separately.
• Effective configuration: capture instance and skill settings, then preserve the more protective setting ServiceNow applies.
• Detection outcome: run benign and synthetic adversarial requests, collect the user-visible result, and export the matching Guardian event.
• External route decision: for each customer-controlled third-party LLM path, retain originating identity, prompt classification, destination, and policy version. Retain the outcome with them.

Keep ownership explicit. The ServiceNow platform owner manages AI Guardian and AI Admin Hub. Application owners decide which skills and business records are exposed. IAM owners govern administrative and user roles. Security owns the policy applied to a routed external request. These records should share a correlation value where the integration permits one.

Managed ServiceNow inference can stay entirely inside ServiceNow's trust boundary. That traffic sits outside an external HTTP interception point unless ServiceNow exposes a customer-controlled route and the customer configures it accordingly. ServiceNow roles, native logs, instance settings, and credential management remain native responsibilities.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy for routed authenticated HTTP AI traffic between users or agents and LLM endpoints. When a customer-controlled ServiceNow integration sends its model request through that path, DeepInspect evaluates application-supplied identity, role, prompt classification, and destination before forwarding it. It also evaluates the versioned policy.

AI Guardian continues to provide its native detection, blocking, and logging inside ServiceNow. DeepInspect adds an independent allow or deny decision for the routed HTTP request, with redaction available as another outcome. It creates a signed, tamper-evident per-decision record. Managed ServiceNow inference, administrative roles, instance configuration, and credential security remain outside that boundary. Book a technical deep dive at deepinspect.ai.