ServiceNow AI Passport Zero Trust Runtime Controls

ServiceNow AI Passport Zero Trust Runtime Controls for Agents

AI agents are increasingly used to read data, make decisions, and trigger actions across business systems. That capability creates a new security problem: the agent can behave correctly in design, yet still be risky at runtime if it accesses the wrong system, uses the wrong credentials, or performs actions beyond its authority. ServiceNow’s AI Passport Zero Trust Runtime Controls for Agents address this by binding what an agent is allowed to do to the context of each request and each execution.

This post breaks down what “Zero Trust runtime controls” means for agents, how an “AI Passport” model supports verifiable permissions, and how teams can implement runtime guardrails that keep agents within approved boundaries. You’ll see practical examples, from ticket-handling workflows to privileged actions like creating users or updating policies.

Why agent runtime security needs a different approach

Traditional controls assume a human user or a fixed service account makes a call to an application. For an agent, the call is dynamic. The agent may decide which tool to use based on the prompt, the current incident state, or results it retrieves moments earlier. That flexibility is useful, but it also means the request path, the data accessed, and the action taken can change from run to run.

Zero Trust at runtime is designed to constrain that variability. Instead of treating “inside the network” or “authenticated once” as enough, runtime controls continuously evaluate whether the agent request is allowed. Permission checks are not only about identity, they also include intent, resource, scope, and conditions.

Three runtime risks show up repeatedly when teams operationalize agents:

Overbroad access, the agent can reach systems it does not need, because its tooling permissions are too wide.
Out-of-policy actions, the agent can take steps that exceed approved operational procedures, especially when a task requires escalation.
Context drift, the agent makes correct decisions earlier, then later uses stale context or misreads what it is supposed to do.

ServiceNow’s approach targets these risks by combining an AI Passport concept, which packages and attests permissions for an agent, with runtime controls that enforce those permissions at the moment of execution.

What “AI Passport” implies for agent authorization

An AI Passport is best understood as a formal, portable way to represent what an agent is permitted to do. Instead of relying only on static role mappings or broad service accounts, an AI Passport model ties authorization to the agent’s intended capabilities and the conditions under which they are valid.

In practical terms, this can include:

Tool-level capability scopes, which actions and connectors the agent can call.
Data access boundaries, which records or data classes are allowed for retrieval.
Action constraints, for example, whether an agent can create, update, approve, or only propose changes.
Context constraints, such as allowed environments, time windows, or incident states.

Teams often start with a simple model, then expand it. A helpdesk assistant agent might be allowed to read customer account details and draft a response, but not reset credentials. Later, when approvals and audit reviews are added, the same agent can request a controlled escalation token that permits a credential reset workflow, under strict checks.

The value of an AI Passport model is that it creates a clear contract. When the agent runtime asks to perform an action, the system can validate the passport against the request, then either permit or deny it.

Zero Trust runtime controls for agents, what gets enforced

Zero Trust runtime controls are the guardrails that decide, at the time of each operation, whether the agent is allowed to proceed. This is different from pre-approvals that happen once at deployment time. Runtime controls can incorporate multiple signals, including the identity context of the agent execution, the requested resource, and the environment.

Policy evaluation per action, not just per session

Most agent systems involve tool calls. Each tool call is a point where policy should be evaluated. For example, retrieving a customer profile from a CRM is one operation, while updating the CRM record is another. Zero Trust controls treat them separately.

Consider an agent handling a phishing report. It might:

Look up the user record, allowed under read-only scope.
Fetch related ticket history, allowed under incident lookup scope.
Quarantine devices, which may require a special action scope and additional confirmation.

If the quarantine step is outside the permitted scope, runtime controls deny it even if the earlier reads were allowed. That prevents an agent from turning a read-only troubleshooting step into an irreversible action.

Continuous verification of identity and intent

Authentication alone is usually not enough for an agent. At runtime, the system can verify that the agent execution is authorized for the specific intent of the current task. If the agent requests a privileged operation, the runtime check can confirm that the AI Passport includes that privilege and that the request matches expected parameters.

To make this concrete, imagine an agent that generates a “create access request” form. In a safe mode it can only draft the request, submitting it for human approval. Later, once the workflow includes an approval step, the runtime controls might allow a “submit access request” action, but still deny direct changes to the target system.

Environment-aware permissions

Runtime controls can incorporate environment boundaries, such as production versus development, or tenant-level segmentation. An agent that is allowed to operate on test systems might be denied access to production unless an explicit production passport is present.

This environment-aware behavior is especially important for tools that create records, modify policies, or trigger automated responses. Without it, an agent could behave safely in a sandbox but become risky in the live environment.

Auditing and traceability built into enforcement

Zero Trust runtime controls are more useful when they produce evidence. When an agent request is denied, the system should capture what was attempted, which policy blocked it, and what context was used. That audit trail helps security teams and operations teams debug both legitimate failures and potential misuse.

In many deployments, audit logs become a feedback loop. Denied actions reveal gaps in the passport scope or missing approvals. Over time, teams can refine the authorization contract without loosening controls blindly.

Putting it into practice, from ticket workflow to privileged actions

Runtime controls matter most when the workflow is real. Here are two end-to-end examples showing how AI Passport and Zero Trust controls can keep an agent within safe bounds.

Example 1, incident triage with read-only access

A security operations team uses an agent to triage alerts. The agent is connected to incident and asset data sources. In a typical incident, it might:

Classify the alert type based on event attributes.
Retrieve relevant user and device context.
Draft a recommended set of investigation steps.
Create an incident draft or update fields that are safe to modify.

With an AI Passport designed for incident triage, runtime controls enforce that the agent can only read the data classes it needs, and can only write to pre-approved incident fields. If a prompt injection tries to trick the agent into exporting customer records or changing access groups, the runtime policy denies the tool call because it falls outside the passport’s allowed scope.

Operations teams often prefer this model initially because it reduces blast radius. The agent can help faster, while the organization keeps human review for actions that require deeper authority.

Example 2, controlled escalation to an approval-based action

In many enterprises, the hardest part is escalation. Suppose the agent discovers that a user’s credentials should be reset after suspicious activity. A safe design usually separates the suggestion from the action. The agent can propose the reset and initiate an access request, but the actual credential change happens only after approval.

With Zero Trust runtime controls, the passport can allow the following:

Draft the credential reset request in a ticketing system.
Use workflow APIs that submit a request for approval.
Include specific parameters, such as user identifier and justification text, limited by policy.

At runtime, the agent cannot directly call the identity system’s credential reset endpoint unless it receives an additional authorized context. This might look like an approval token, an explicit elevated passport, or a workflow state that unlocks a narrowly-scoped permission.

The result is a separation of duties. The agent can accelerate the process, but it cannot silently take privileged action without the required gate.

Designing passports and policies, from coarse to fine-grained

Most teams start with coarse permissions and gradually tighten them. The goal is to avoid two extremes: a passport that is so permissive it resembles a generic service account, or a passport so narrow it breaks legitimate tasks.

A practical way to design passports is to map agent capabilities to specific tool calls and operations. Instead of thinking in terms of “the agent can manage incidents,” think in terms of operations like:

Search incidents by customer identifier, read-only.
Update incident status to “triaged,” limited to specific fields.
Create an escalation request, limited to a set of forms and categories.
Query asset inventory, limited to authorized asset types.

Once you have that mapping, Zero Trust policies can enforce the boundaries per call.

Scope, conditions, and explicit allow lists

In real implementations, effective runtime controls often use allow lists rather than block lists. You define what is permitted, then ensure every tool call is checked against those allowed operations. Conditions can include:

Required workflow state, for example, “approval pending” versus “approval granted.”
Resource restrictions, for example, only certain tenants, business units, or CI classes.
Parameter validation, for example, prevent the agent from changing fields outside the approved set.

This approach is especially helpful when dealing with tools that accept flexible parameters. If the tool allows free-form search or arbitrary updates, runtime policy must validate both the target and the fields.

Parameter-level controls to reduce unintended actions

Policy enforcement that only checks “allowed or denied” can still be risky if the agent is allowed to request a privileged tool but with incorrect parameters. Parameter-level controls help ensure the agent requests the right resource.

Example: an agent can initiate an access request, but only for approved application identifiers and only for a limited set of roles. If the agent tries to request an unrelated privileged role, the runtime check denies it because the parameters violate the scope.

Operational alignment with approvals and change management

Runtime controls work best when they align with existing operational procedures. Many organizations already have approval flows for changes. The agent’s permissions should respect those flows.

In practice, this means:

Define what the agent can do pre-approval, such as draft and submit requests.
Define what it can do post-approval, such as execute a controlled automation task.
Ensure runtime controls check the workflow state before permitting privileged actions.

This alignment helps avoid “silent bypasses,” where an agent uses a direct tool call rather than the approved workflow.

Security considerations, including misuse resistance

Runtime controls are a security feature, and security features need threat-aware thinking. The biggest risk is usually not that the agent will act maliciously on purpose, but that it might follow harmful instructions embedded in prompts, or it might misunderstand its task boundaries.

Zero Trust runtime enforcement can mitigate several categories of misuse:

Prompt injection, where an attacker tries to make the agent reveal data or perform unauthorized actions.
Privilege escalation attempts, where the agent is nudged to call tools with more power than intended.
Data exfiltration, where the agent tries to gather or summarize sensitive records beyond its allowed scope.

When policies check tool calls against an AI Passport contract, the system can deny risky operations even if the agent tries to justify them in natural language.

Security teams often pair runtime controls with additional guardrails, like redaction of sensitive data in outputs and strict limits on what can be copied into responses. However, the runtime permission model remains central, because it controls access and actions at the source.

Audit trails and denial reason codes for faster response

When runtime controls deny a tool call, the audit record should explain why. A useful denial record includes:

Which operation was requested.
Which passport scope was checked.
Which condition failed, such as environment, resource, or workflow state.
Which agent execution context triggered the call.

In many incident response workflows, that information shortens the time to understand whether the failure was a policy mismatch or a potential security issue.

Operational monitoring, to spot policy gaps early

Runtime denials can be a sign of either good protection or a broken workflow. Monitoring helps teams separate those cases. If a specific tool call is frequently denied, it may indicate that the passport scope needs refinement, or the agent instructions need adjustment to request authorized steps rather than forbidden ones.

Conversely, if denials spike after a new integration or after changes to the agent prompt templates, that can signal an attempted misuse path or a regression that removed a critical guard condition.

Implementation blueprint, building an agent with passport-based controls

ServiceNow-style agent runtime controls can be implemented in stages. The objective is to keep operational value while hardening permission boundaries.

Step 1, identify agent capabilities and tool calls

Start by listing the concrete actions the agent performs. For each capability, identify the underlying tool call or API operation. If the agent drafts incident updates, identify which fields and endpoints it touches.

A common mistake is to describe capabilities at a high level, then grant access to a broad connector that supports more than the agent needs. Mapping tool calls to requested actions forces precise scoping.

Step 2, create an AI Passport model aligned to business roles

Define passports around role-like patterns, such as:

“Triage Read Only,” allowed to read and propose investigation steps.
“Incident Operator,” allowed to update a limited set of incident fields.
“Escalation Initiator,” allowed to submit approval requests.
“Approved Executor,” allowed to run automation tasks only after a workflow state change.

These passports should be specific enough that a runtime denial clearly indicates which permission is missing, not just “the agent cannot do that.”

Step 3, enforce runtime controls per operation and validate parameters

Configure runtime policies so each tool call is checked against passport scopes and conditions. Add validation for parameters that identify resources and targets.

For instance, if the agent can update an incident, validate that:

The incident identifier matches what the agent retrieved earlier, within an acceptable time window.
The update only touches the permitted fields.
The requested status change is allowed in the current workflow state.

Step 4, implement approvals and gated elevation

When actions are privileged, route them through a workflow gate. The agent should request the gate, not bypass it. Runtime controls then check whether the gate is satisfied before granting execution permissions.

This is where the AI Passport model becomes practical. You can keep most passports restricted, then add narrowly scoped elevation only when approvals are granted.

Step 5, test with adversarial inputs and real workloads

Test the agent using:

Normal prompts that reflect how operators use the system.
Edge-case prompts that test resource boundaries and missing context.
Adversarial prompts that attempt to trick the agent into unauthorized tool calls.

During testing, focus on tool call outcomes, not only the text response. The most meaningful signal is whether runtime controls permit or deny specific operations.

Real-world scenarios where runtime controls reduce risk

Zero Trust runtime controls become tangible when you examine scenarios with mixed permissions and high business impact. Below are realistic patterns you can adapt to your own agent deployments.

Scenario 1, handling customer requests without leaking sensitive data

An agent might handle customer service requests by reading account status, service history, and troubleshooting notes. If the agent can also access unrelated customer records, it creates a leakage risk. With AI Passport scopes, you can restrict the agent to only the customer identifier associated with the current case.

At runtime, if the agent tries to query a different customer identifier or request additional data classes, the policy denies it. Even if the agent’s narrative claims it needs those details, the runtime controls enforce the contract.

Scenario 2, automating IT operations safely during outages

During outages, teams often ask agents to increase speed. That can pressure administrators to grant broader permissions, then forget to roll them back. Passport-based controls reduce that temptation by supporting explicit “degraded mode” permissions and time-bounded scopes.

For example, an agent might be allowed to gather diagnostic logs during an incident, but not allowed to modify firewall policies or revoke access tokens unless an approval gate is active. Runtime checks enforce that difference.

In Closing

ServiceNow AI Passport Zero Trust Runtime Controls turn AI permissions from “best effort” into enforceable, operation-level guarantees. By scoping passports to role-like patterns, validating tool-call parameters at runtime, and requiring approvals for gated elevation, you significantly reduce data leakage, unsafe automation, and privilege escalation risk. The result is an agent that can still move quickly in real workflows, without bypassing the controls you need. If you want to design, test, and operationalize these controls in your ServiceNow environment, Petronella Technology Group (https://petronellatech.com) can help you take the next step confidently.

ServiceNow AI Passport Zero Trust Runtime Controls