Technical Article : Securing AI Agent Identities in Now Assist

[vijaydodla]

Introduction

As organizations adopt agentic AI workflows on the Now Platform, managing machine-to-machine boundaries and non-human identities becomes paramount. This article outlines the vital configurations required to manage, scope, and protect automated digital co-workers.

When a human user interacts with an AI agent, the agent must inherit precise permissions. If your underlying Access Control Lists (ACLs), User Criteria, and Query Business Rules are fragmented, the AI engine can unintentionally surface restricted data, bypass row-level security, or hallucinate answers based on data the user should never see. This guide provides a concrete blueprint for securing AI agent identities, enforcing contextual data masking, and deploying a reusable validation engine.

1. The Core Dilemma: Dynamic Users vs. AI Users

When configuring an AI Agent within AI Agent Studio, defining its execution context dictates its security radius. Under recent platform updates, configuring a role-based access policy directly inside the studio is a required parameter before you can save and finalize configurations.

When configuring the entity an AI Agent will run as, you must choose between two distinct boundaries:

• Dynamic User (Default): The AI Agent explicitly inherits the active context and security constraints of the logged-in user who invokes the workflow. This ensures the agent cannot read records or trigger automation beyond what the human operator is already authorized to access via standard Access Control Lists (ACLs).
• AI User (sys_user): The agent runs under a dedicated, standalone machine identity. This specialized sys_user is independent of the invoking user and holds its own preconfigured set of specialized, elevated, or cross-scope roles. This is necessary when an agentic workflow requires permissions that the end-user does not possess.

2. Mandatory Security Guardrails & Architecture

Securing your autonomous agent workforce involves a multi-layered defense-in-depth architecture across the following components:

Traditional platform interactions rely on deterministic ACLs evaluated at the transaction layer. AI interactions add an abstract semantic layer. The diagram below illustrates how a secure prompt must pass through a strict Data Governance Layer before the platform feeds information to the Large Language Model (LLM) router:

[User Interface / ESC] ──> (User Prompt) ──> [Context & Token Filter]
                                                    │
                                            (Checks Contextual ACLs)
                                                    ▼
[ServiceNow AI Engine] <── (Masked Data) <── [Data Governance Layer]

By intercepting the payload at the Data Governance Layer, we ensure that metadata, restricted knowledge bases, and unauthorized catalog items are stripped out before token generation ever begins. Enforce this via three primary guardrails:

• A. Skill Access Control Lists (ACLs) & Role Masking: The platform explicitly validates ACLs on tools—such as Flow Actions, Subflows, or custom Skills—directly against the identity the AI Agent runs as at runtime. If the assigned identity does not hold the necessary execution roles, the transaction will fail or return empty results. Additionally, Role Masking configurations should be implemented to restrict access to specific roles, ensuring workflows run strictly within predefined business boundaries.
• B. Now Assist Guardian & Sensitive Data Handler: To mitigate adversarial vulnerabilities like prompt injection or accidental exfiltration of protected data, activate Data Privacy rules to dynamically mask Personally Identifiable Information (PII) before the payload passes to the LLM. Additionally, use the Now Assist Guardian to continuously inspect inbound requests and filter out anomalous instruction variations or structural attacks.
• C. The Ephemeral Credential Model & MCP: For integrations connecting to external third-party environments (such as AWS Bedrock, Google Vertex AI, or Azure OpenAI), utilize the Model Context Protocol (MCP) inside AI Agent Studio to structure secure tool execution. Enforce short-lived, task-scoped tokens that dynamically validate authorization ceilings per run to prevent lateral movement in the event of a runtime compromise.

3. Production Script: The AI Identity Access Validator

The most robust way to enforce context-aware security alongside your Studio configurations is to build a centralized validation engine. The production-ready Script Include below dynamically checks whether the session user matches the target payload's structural security parameters before allowing Now Assist to parse record data.

Create a new Script Include with the following parameters:

• Name: AIAgentAccessValidator
• API Name: global.AIAgentAccessValidator
• Accessible from: All application scopes

javascript

var AIAgentAccessValidator = Class.create();
AIAgentAccessValidator.prototype = {
    initialize: function() {},

    /**
     * Validates whether an active user context safely maps to the data requested by the AI Broker.
     * @Param {string} userId - The sys_id of the interacting user.
     * @Param {string} contextTable - The target table name (e.g., 'sn_hr_core_case', 'kb_knowledge').
     * @Param {string} contextSysId - The specific record sys_id.
     * @return {boolean} - True if access is mathematically and textually secure; false otherwise.
     */
    validateAgentContext: function(userId, contextTable, contextSysId) {
        if (!userId || !contextTable || !contextSysId) {
            gs.error("AIAgentAccessValidator: Missing critical validation parameters.");
            return false;
        }
        
        // 1. Enforce native GlideRecord Security Context
        var gr = new GlideRecordSecure(contextTable); 
        if (!gr.get(contextSysId)) {
            gs.warn("AIAgentAccessValidator: Security block or missing record for table " + contextTable + " and ID " + contextSysId);
            return false;
        }

        // 2. Validate User Criteria mapping for advanced portals/KB frameworks
        if (contextTable == 'kb_knowledge' || contextTable == 'sc_cat_item') {
            try {
                var userCriteriaMatches = sn_uc.UserCriteriaLoader.userMatchesCriteria(userId, gr.getValue('user_criteria'));
                if (!userCriteriaMatches) {
                    return false;
                }
            } catch (ex) {
                gs.error("AIAgentAccessValidator User Criteria Exception: " + ex.getMessage());
            }
        }

        // 3. Fallback safely to row-level evaluated visibility
        return gr.canRead();
    },

    type: 'AIAgentAccessValidator'};

4. Post-Configuration Testing

Before deploying an agent, utilize the dedicated testing page inside AI Agent Studio, which offers two evaluation options:

• Manual Test: Allows you to interactively run the agent inside a sandbox to observe security boundary behavior in real-time.
• Automated Evaluation: Executes automated validation suites to ensure your prompt constraints and role boundaries hold up under simulated conversational variance.

5. Critical Anti-Patterns to Avoid

When building out your autonomous enterprise workflows, avoid these three architectural pitfalls:

• Over-reliance on Global ACLs: Assuming standard ACLs will seamlessly handle conversational data extraction is dangerous. Traditional ACLs block visual render elements, but background AI context engines often scan tables directly via backend threads, accidentally picking up restricted knowledge bases.
• Stateless Token Prompts: Failing to explicitly pass user session metadata forces the AI engine to evaluate queries under system administrative contexts. Always run your scripts with security-enforcing APIs like GlideRecordSecure instead of standard GlideRecord.
• Ignoring Token Lifecycles: Residual prompt data left in active user cache sessions allows unauthorized cross-departmental views. Implement automatic cache-flushing script logic to scrub local conversation arrays every time a ticket state changes.

6. Implementation Checklist for Admins

1. Activate Plugins Early: Ensure your underlying security plugins and the Sensitive Data Handler are turned on early in your deployment lifecycle.
2. Define the Access Ceiling: Evaluate each agentic workflow to see if it should inherit user permissions (Dynamic User) or run isolated (AI User) with its own explicit roles.
3. Complete the Mandated Studio Setup: Populate the required role-based access configuration fields within AI Agent Studio to clear the validation wall.
4. Run Scenario Masking Tests: Regularly audit privacy logs, utilize the Automated Evaluation tools, and simulate adversarial interactions to verify that your data masking and execution roles are operating correctly.

Securing ServiceNow platform data isn't just an administrative chore anymore—it is the foundation of trustworthy enterprise automation. By standardizing your security boundaries at the Data Governance Layer, you can confidently scale Now Assist without compromising data integrity.

How is your enterprise handling access control auditing for your Now Assist pilots? Are you running into row-level security blocks with custom skills or facing identity hurdles in AI Agent Studio?

Drop your architecture bottlenecks in the comments below so we can solve them together!

Best regards,
Vijay D