ServiceNow and NVIDIA Put an AI Passport on Enterprise Agents

The enterprise agent problem is no longer proving that a model can call a tool. It is proving which agent called the tool, under whose authority, with which limits, and whether the action can be stopped after the model changes its mind. ServiceNow and NVIDIA are addressing that problem with a joint stack described in October 2026 reporting: ServiceNow’s Arc and AI Passport connect with NVIDIA OpenShell and Sentry so an agent can carry an identity and policy through software and hardware. The name “passport” is useful because it implies a credential that travels, but the real test is whether the credential changes what the runtime permits.

[Primary reporting and source links are included near the claims they support. See the official OpenAI safety material for the first story, the Anthropic newsroom for the second, the ServiceNow press room and NVIDIA newsroom for the third, Google’s Shopping announcements for the fourth, and the Government Accountability Office for the fifth.]

flowchart TD
 A[Research or deployment pressure] --> B[AI system boundary]
 B --> C[Evidence and permissions]
 C --> D[Human decision]
 D --> E[Measured outcome]
 E --> F[Correction or next release]

Enterprise agents need identities that survive tool calls

An enterprise agent is often assembled from a model, an orchestration service, a connector, a policy engine, and a runtime. Each layer can claim that another layer is responsible for safety. The passport idea attacks that fragmentation by giving the agent a portable identity. If the identity is cryptographically bound to the task and policy, a downstream system can make a decision without trusting a paragraph of model-generated text.

A passport is not the same as permission

Identity and permission are different. A passport can tell a system that an agent is the procurement assistant assigned to a particular employee. It does not automatically justify a purchase. The runtime still needs scope, amount limits, time windows, target systems, and approval requirements. Buyers should reject diagrams that show identity as a substitute for authorization. It is the handle by which authorization can be evaluated.

Arc turns orchestration into an operating model

Arc’s significance is operational rather than theatrical. A platform agent must coordinate records, workflows, approvals, and business rules that predate generative AI. That makes the product closer to a control plane than a chatbot. The useful question is not whether Arc can produce a polished explanation. It is whether it can represent a task as a bounded workflow and leave a durable record when a step fails.

NVIDIA’s runtime layer supplies the enforcement point

NVIDIA contributes a different layer. OpenShell and Sentry are described as safety infrastructure that can constrain an agent while it executes. This is where policy becomes concrete: a call can be allowed, denied, rate-limited, isolated, or routed for approval. Hardware-adjacent enforcement is attractive because application code may be changed by the agent or bypassed by a compromised connector.

Why cryptographic identity matters after the demo

Cryptographic identity matters when logs are contested. An ordinary username in an application log may tell an investigator that a service account acted. A signed agent identity can add the model version, task instance, policy hash, and issuing authority. That does not make the action correct, but it narrows the question from “what happened?” to “which authorized execution path produced this event?”

The policy has to follow the agent across systems

The identity must travel across the whole chain. If ServiceNow knows the agent but a downstream database sees only a generic integration account, the passport has stopped at the boundary. Strong designs propagate claims or use a broker that re-evaluates them at every sensitive hop. The useful passport is not a sticker attached at login; it is a chain of custody that survives delegation.

Human approval is still a workflow, not a checkbox

Human approval often fails because it is treated as a button. A reviewer needs the proposed action, evidence, policy reason, material uncertainty, and an undo path. Arc and NVIDIA can make an approval event enforceable, but they cannot decide whether a person had enough context to approve. Workflow design remains a product responsibility for the buyer.

Where observability becomes part of governance

Observability is part of governance because agents create branching behavior. A single request may trigger search, retrieval, classification, a ticket update, and a message. If the log records only the final answer, an auditor cannot reconstruct the path. Runtime systems should capture tool calls, denials, retries, policy decisions, and the exact data presented to the model, subject to privacy controls.

A useful design for high-risk actions

High-risk actions deserve graduated controls. Reading a public knowledge base can be low risk; changing payroll data is not. A passport can carry risk tier, and the runtime can enforce different requirements: automatic execution for read-only work, dual approval for financial changes, and hard blocks for restricted exports. That makes governance proportional instead of equally annoying everywhere.

The integration story is also a lock-in story

The partnership also creates a strategic dependency. A customer that adopts ServiceNow workflows, NVIDIA runtime controls, and proprietary identity semantics may gain a coherent stack while making future migration harder. Open standards and exportable audit records should be purchase requirements. Safety that works only inside one vendor’s boundary is operationally useful but strategically fragile.

What buyers should ask before deployment

Buyers should ask who issues the identity, who can revoke it, whether policy changes are versioned, how long receipts are retained, and what happens when a connector is unavailable. They should request a red-team demonstration in which an agent attempts an unauthorized action through an alternate path. A slide showing “policy enforcement” is not evidence until the bypass is tested.

Failure recovery is the overlooked feature

Recovery deserves equal billing with prevention. If an agent creates a bad ticket, changes a record, or sends a message, operators need a kill switch and a replayable history. The system should distinguish a reversible update from an irreversible side effect and require stronger controls for the latter. Fast rollback is a form of agent safety that users feel immediately.

The threat model includes honest mistakes

The threat model includes honest model errors. A well-identified agent can still misunderstand a request, select the wrong customer, or infer authority from an ambiguous sentence. Identity limits blast radius but does not supply business judgment. Deterministic validation, typed tool inputs, and confirmation for unusual actions must remain outside the model.

How to measure agent governance

Governance needs metrics that can be compared over time: denied calls, approval latency, policy exceptions, rollback frequency, high-risk actions by agent version, and incidents caused by stale context. Without numbers, runtime safety becomes a procurement slogan. The ServiceNow-NVIDIA stack creates a place to collect those measures; customers must demand access to them.

What the announcement leaves open

The announcement leaves implementation questions open, including portability, third-party connector coverage, and the exact boundary between software policy and accelerator enforcement. Those gaps are not reasons to dismiss the design. They are the questions that separate a reference architecture from a production control.

The enterprise agent now has a chain of custody

Enterprise agents are heading toward a chain-of-custody model. The winning system will not be the one that lets an agent do the most. It will be the one that can explain every consequential action, enforce a narrow authority, and stop execution without destroying the business process. ServiceNow and NVIDIA are betting that identity can become the spine of that model.

The operational detail behind the headline

Portable identity becomes especially important when an agent delegates to another agent. A service desk agent may ask a procurement agent to obtain a quote, which may ask a supplier connector to retrieve terms. If each hop creates a generic service account, the original authority disappears. A better chain carries the initiating task, delegated scope, and expiration through every call. The recipient can then reject delegation that exceeds the parent permission rather than trusting the downstream agent’s description.

Policy enforcement must be fail-closed for selected actions and fail-open only where the business has deliberately accepted that risk. A read-only knowledge lookup may continue during a policy service outage. A payment, identity change, or production deployment should normally stop if the policy decision cannot be obtained. These choices belong in the design before an incident. Runtime infrastructure can enforce them consistently, but a customer still has to classify the actions.

Agent identity also helps with version changes. If a workflow behaves differently after a model update, operators need to know which model, prompt policy, connector version, and tool schema were active. Binding those details to an execution receipt makes rollback possible. Without versioned identity, the organization may know that an agent acted but not which software should be fixed. That is a familiar software-release problem with a more distributed actor.

An AI passport should not become a universal tracking token. If the same identifier follows a person’s work across unrelated systems, it can reveal more than is needed for authorization. Privacy-preserving designs can use scoped identifiers, selective disclosure, and short lifetimes. The runtime needs enough information to enforce policy, not a permanent record of every context in which an employee asked for help.

Connector quality will determine the practical ceiling. A platform may enforce rules perfectly for its own records while an old third-party integration accepts broad text commands. Buyers should test the least mature connector in the chain, because attackers and accidents look for the weakest boundary. The passport must either survive the connector or force the call through a broker that can re-check the action before it leaves the governed environment.

Runtime policy should be testable with adversarial tasks. Ask an agent to access a record outside its department, to use a credential from another task, to split a purchase into smaller amounts, or to hide a failed call in a summary. The expected result should be denial with an explanatory event, not merely a model refusal. These tests reveal whether the control sits below the language layer where a prompt injection can bypass it.

Organizations will also need a separation between policy authors and application owners. If the team building a workflow can silently loosen the policy that governs it, governance is circular. A review board does not need to approve every low-risk change, but high-risk scopes, new connectors, and model upgrades should have independent sign-off. The passport creates a place to attach that approval to the running system.

Cost and performance matter. Cryptographic checks, policy lookups, tracing, and sandboxing add latency to every tool call. A business process that once completed in a second may now wait for multiple decisions. That trade can be acceptable for high-risk changes, but not every read operation needs the same ceremony. Risk-tiered enforcement is how governance avoids becoming so expensive that teams turn it off.

The best enterprise audit record is useful to operators, not only auditors. A service owner should be able to see that an agent was denied because a customer record was outside scope, then correct the workflow without reading millions of raw events. Human-readable explanations can sit beside machine-verifiable claims. ServiceNow’s workflow expertise is relevant here because an agent control becomes real only when someone can resolve the blocked work.

If the partnership works, agent governance may start to resemble modern identity infrastructure: issuers, scopes, revocation, delegation, policy evaluation, and evidence. That is a healthier direction than treating every agent as a special chatbot with bespoke guardrails. The risk is that vendors define incompatible passports and make cross-platform work harder. Open claims, portable logs, and ordinary authorization concepts will determine whether the idea scales beyond one stack.

Questions the next review should answer

An identity chain can also support least-privilege debugging. When an agent is denied, the operator should see whether the problem was missing scope, expired authority, an unsafe destination, or a policy conflict. That makes the system repairable without granting broad access as a quick fix. In many organizations, access expands after the first denial because the reason is opaque. Explainable enforcement reduces that dangerous pattern.

Runtime safety should be independent of the model provider where possible. Customers may route a task between different models for cost, latency, or capability. If the permission boundary depends on one vendor’s prompt wrapper, model switching becomes a governance event. A passport and policy layer below the model can preserve controls while the model changes. That separation is one of the strongest arguments for treating agent identity as infrastructure rather than a feature of a chatbot.

There is a subtle distinction between a policy decision and a business decision. The runtime can enforce that a purchase above a threshold requires approval. It cannot determine whether the purchase is wise or whether a department’s budget is being used fairly. Enterprise programs should not present technical enforcement as a replacement for management controls. The passport makes the decision path clearer, which helps people see where nontechnical accountability begins.

Vendors should make the audit format exportable in ordinary tools. Security teams already know how to ingest identity events, data-access logs, and change records. A proprietary agent timeline that cannot be correlated with those systems creates a new blind spot. Open schemas, stable identifiers, and clock synchronization may sound mundane, but investigations depend on them. Interoperability is a safety property when an organization has more than one platform.

Agent-to-agent delegation will make revocation more difficult unless the chain supports cancellation propagation. If the initiating task is revoked, downstream work should stop or become read-only. A system that revokes only the front-end session can leave child jobs running with valid credentials. This is the kind of edge case that should be included in production tests before customers allow agents to operate on financial, identity, or operational records.

Hardware enforcement can reduce tampering, but it does not automatically solve policy interpretation. A signed request can still ask for the wrong customer record. The runtime should combine identity with typed parameters, resource-level authorization, and a deterministic validation layer. Model-generated natural language belongs at the edge of the control system, not at the final point where an irreversible action is accepted.

The partnership’s strongest long-term contribution would be a common vocabulary for agent accountability. Issuer, subject, task, scope, delegation, expiry, policy decision, receipt, and revocation are concepts that many platforms can share. If every vendor uses a different name and incompatible token, enterprise teams will rebuild the same controls repeatedly. The market needs usable implementation guidance, not only another branded architecture diagram.

The decision that cannot be delegated

Governance must also cover the people who configure the passport. An administrator who can widen scopes, disable a policy, or impersonate an agent is a high-value target. Those administrative actions need their own identity, approval, logging, and review. The control plane is part of the threat model.

Customers should insist on a test environment that mirrors production policy. A new connector or model can then be exercised against denial cases before it receives live authority. Staging is not only a release convenience; it is where the organization proves that a policy still means what it thinks it means.

The useful outcome is not an agent that never acts. It is an agent whose authority is legible, narrow, revocable, and portable across the systems where the work actually happens.

The final operational test

The identity record should be understandable during an incident, when an analyst has little time. It should connect the event to a task owner, policy version, resource, and remediation path without requiring a proprietary specialist.

Revocation should be tested as often as issuance. A passport that is easy to create but slow to invalidate leaves the most dangerous window open after compromise.

Organizations should also review inactive agents. Dormant identities, abandoned experiments, and expired projects are common sources of forgotten authority.

Runtime governance is strongest when it is boring, inspectable infrastructure rather than an impressive model behavior.

What durable trust would require

A passport also needs an expiration policy that matches the task. Permanent authority is convenient but difficult to review; short-lived authority is safer if renewal is automatic only when the same conditions still hold.

The practical value of the stack will be proven at the boundary between two vendors, where identity, policy, and logs are most likely to break.

The standard after launch

The control should be usable by a mixed team: security can inspect the claim, application owners can understand the workflow, and business owners can see the consequence. A system that only a specialist can operate will become a hidden dependency.

That is why the passport matters beyond branding: it can give an enterprise a shared language for authority, delegation, and evidence.

The proof point

The final question is simple: can an operator prove what the agent was allowed to do before the action happened? If the answer is yes, runtime governance is doing real work. If the answer is only that the model was instructed to behave, the enterprise is still relying on hope at the point where it needs evidence.

A production control must also survive failure between systems. If the policy service approves a call but the downstream application times out, the agent should not blindly retry an action whose side effect may have happened. Idempotency keys, explicit transaction states, and operator-visible retries matter as much as the identity token. Runtime governance is partly the discipline of making uncertain outcomes safe.

The evidence that will outlast the launch

The enterprise adoption path will likely begin with read-heavy workflows and expand toward changes only after the evidence is good. That progression is sensible, but it should not become an excuse to ignore the hard controls until after the first incident. Read access can expose sensitive records, and a search agent can still create harm by combining information that no single employee would normally see. Scope, purpose limitation, and output filtering belong in the first deployment. A passport should identify not only who the agent is but why it is allowed to ask this question now. That purpose claim can support data minimization and make later review far more precise.

The primary documents to keep open

Sources and reporting trail

The article distinguishes company announcements from independent reporting. Vendor descriptions are attributed rather than treated as independently verified performance claims. Readers should consult the linked primary documents for the original wording and release context.