🚀 ServiceNow Arc AI Agent: AI Agent Security (2026)
Discover how the ServiceNow Arc AI agent delivers AI agent security with runtime + hardware safeguards. Learn NVIDIA OpenShell use cases & AI governance—test today.
Can ServiceNow and Nvidia Make Enterprise AI Agents Safer?
AI agents promise to handle work that usually takes a person several steps: reviewing an inbox, finding relevant meeting notes, and preparing follow-ups. That promise gets harder to accept when an agent can access company systems and act on a user's behalf. If its permissions are too broad, a mistake - or a compromise - can quickly turn into an operational and security problem.
ServiceNow and Nvidia are pitching Arc as an answer. Arc is a long-running AI agent that's available on Mac (with Windows support still coming) and intended to work with productivity tools like email and Microsoft Teams. The main claim isn't just that it can automate everyday tasks. It's that its actions can be constrained and monitored through multiple security layers, including controls at runtime and at the hardware level.
That architecture is worth a close look. But it isn't a replacement for testing. This article breaks down what Arc is designed to do, how its security model is supposed to work, what enterprise teams should verify before deploying it, and where this approach is likely to help - and where it may fall short.
What ServiceNow and Nvidia's Arc agent does
Arc is described by its creators as a personal, long-running AI agent for everyday work. It's designed to build memory and skills over time, use context from sources like inboxes and meeting notes, and proactively surface work and action items. The intended experience is less like asking a chatbot a single question and more like having an assistant that tracks recurring work.
That distinction matters. A chatbot typically answers a prompt. An agent can also decide which tools to use, retrieve information, and take steps toward a goal. Those extra capabilities can save time, but they also add failure modes. A system that can read email and call APIs still needs strong controls over what it can access - not just a filter on what it's allowed to say.
Local processing and model selection
Arc is designed to run on Nvidia's RTX Spark devices - either locally on an employee's desktop or within Nvidia OpenShell on a separate device. The companies say it keeps data local whenever possible and sends more complex tasks to frontier models only when needed. In theory, that reduces unnecessary data transfers and reserves the most capable models for work that actually benefits from them.
"Local" isn't the same thing as "never leaves the device." What happens in practice depends on the task, configuration, connected services, and the models involved. Before rollout, buyers should map out which information stays on-device, what gets sent elsewhere, and how prompts, outputs, and tool calls are logged. In other words, the details matter more than the headline.
There's also a plain, practical constraint: availability and compatibility. Arc is available on Mac, and Windows support is still on the way, according to the announcement. Since it's described as built for RTX Spark devices, organizations should confirm what configurations are supported and what hardware is required before planning a rollout. Those factors can directly affect timelines, support costs, and who gets access.
A practical use case - and its limits
Picture a project manager getting ready for a weekly customer meeting. Arc could pull the relevant email thread, summarize prior commitments, extract action items from meeting notes, and bring outstanding work to the user's attention. That's a straightforward productivity use case because it ties repetitive information gathering to a clear next step.
The key question is what comes after the summary. Reading and organizing information carries different risk than sending messages, changing records, or triggering workflows. A safer rollout can start with read-only access and human review, then expand to tightly scoped write permissions only after the team tests how the agent behaves.
Arc's promise of building context over time can make it more useful, but it also raises governance questions. What information is retained? Can a user inspect or correct it? Does the memory follow someone across tasks and systems? The announcement points to ongoing memory and skills, but organizations should demand clear answers on retention, deletion, access, and auditability before treating accumulated context as an operational asset.
How Arc's security layers fit together
ServiceNow and Nvidia say Arc's main differentiator is a multi-layer security framework. Their stated approach pushes enforcement beyond the software layer and into runtime and hardware layers. The idea is to make it harder for an agent - or compromised software around it - to bypass policy.
The components are meant to fit together. ServiceNow's Super Intelligence Control Tower is where IT sets policies. Nvidia OpenShell enforces those policies at runtime, restricting what the agent can do when it needs to. The companies also say administrators can control which systems an agent can access, which APIs it can call, and what data it can read.
Policy, runtime enforcement, and AI Passport
AI Passport is positioned as the bridge between ServiceNow's policy infrastructure and Nvidia's enforcement mechanisms. It's meant to carry an enterprise's rules for risk tolerance and which services an agent may use. In the companies' model, OpenShell can use that policy information to intervene if an agent attempts an action outside its permissions.
They describe the flow like this:
- IT defines the rules. Administrators specify permitted systems, APIs, and data access through the Control Tower.
- The agent receives scoped permissions. AI Passport represents the relevant rules for the agent and its allowed services.
- Runtime controls monitor actions. OpenShell constrains what the agent can do while it's working.
- A revoked permission stops the task. If a passport is revoked, OpenShell can contain the attempted task in a sandbox for later review.
- Other authorized work can continue. The companies say the interruption is task-specific, so other agent activity doesn't have to restart.
The goal here matches a real operational need: revoking access shouldn't require shutting down every approved activity, but a risky task shouldn't be allowed to continue while administrators investigate. Task-level containment could make incident response more precise - assuming the system can reliably separate the affected action from unrelated work.
What hardware enforcement can - and cannot - mean
The companies also say Nvidia BlueField can enforce a passport revocation at machine speed, before an agent proceeds. Their stated goal is enforcement in silicon that compromised software can't easily override. If it works as described, that gives you a control point below the application layer, where a compromised process may have less room to ignore policy.
But it's still not a magic shield. Hardware controls only help if the policy is correct, the system is configured securely, and you understand what actions are actually being mediated. They can't make an overly broad permission "safe," decide whether a business instruction is appropriate, or guarantee the agent's output is accurate. And the announcement alone doesn't establish how these controls behave across every integration, edge case, and failure condition.
For buyers, the useful distinction is between a security mechanism and a security outcome. A mechanism can block certain unauthorized actions. The outcome depends on how your organization defines permissions, connects systems, monitors activity, and handles what happens when the mechanism intervenes.
What enterprise buyers should test
A multi-layer design sounds attractive - but the details determine whether it holds up in real production. Your evaluation should test the entire workflow, including connected tools and the people who will administer the controls. Don't stop at the agent's performance in a polished demo.
Start with a bounded workflow
Pick one frequent task with measurable value and limited downside. Inbox triage or meeting preparation may be a better place to start than an agent that can send external messages, change financial records, or approve access requests. Define the task in operational terms: what it can read, what it can do, and what must remain a human decision.
Then build a baseline. Track how much time employees spend on the workflow today, how often errors happen, and what review is already required. Without a baseline, "time saved" is just a claim. Factor in the cost of configuring the agent, investigating incorrect actions, and maintaining its permissions.
Run permission and failure tests
Test normal use, but also test the moments when the agent should stop. For example: revoke access mid-task, provide a prompt that tries to get it to use an unapproved service, and verify it can't reach data outside the intended scope. Confirm that any attempted action is contained, recorded, and visible to the right reviewers.
A practical test plan should cover:
- Least privilege: Can the agent complete the task with read-only or narrowly scoped access?
- Permission revocation: If a passport is revoked, does the agent stop the relevant action quickly?
- Task isolation: If a task is blocked, can it be contained without disrupting unrelated approved work?
- Audit records: Can reviewers reconstruct what data the agent accessed and which tools it called?
- Human review: Can a user approve, reject, or correct consequential actions before they take effect?
- Recovery: What happens if a control service, integration, or device is unavailable?
- Data handling: Which data stays local, and what gets sent to external models or services?
These aren't edge cases. They're the scenarios that decide whether an agent can be operated safely when something unexpected happens.
Assign ownership before expanding access
Agent rollouts usually involve multiple teams. IT or security may own policy, business teams may define the workflow, platform teams may run integrations, and employees may be responsible for reviewing outcomes. If nobody owns permission changes or incident review, you can end up with controls that exist on paper but don't work in practice.
Before a pilot, agree on a short list of responsibilities:
- Who approves each new system or API connection?
- Who reviews blocked or suspicious tasks?
- Who can revoke an agent's access, and how fast?
- How are workflow and permission changes documented?
- What's the process for deleting stored context when an employee leaves or a use case ends?
Also measure more than completion. Track policy violations, human corrections, blocked actions, review time, and the share of tasks completed without intervention. A high completion rate isn't helpful if it comes with overly broad access or constant manual cleanup.
Where Arc fits in the AI agent market
Arc arrives as more businesses try to move beyond conversational AI toward systems that can take actions across tools. The business case is straightforward: agents can reduce the coordination work between email, meetings, and enterprise software. The security challenge is equally straightforward: each new tool connection expands what actions an agent might take and how much information it could reach.
ServiceNow and Nvidia's approach focuses on policy enforcement across software, runtime, and hardware. That's different from relying only on instructions in a prompt or permissions inside an application. The distinction is useful, but you still need to judge the product against what your organization already has - identity management, endpoint controls, data-loss prevention, logging, and incident response. You should be clear on whether Arc complements those systems, overlaps with them, or adds yet another layer of policy you'll have to manage.
There are trade-offs too. Running locally may help with data locality and responsiveness, but it can increase hardware and device-management requirements. Sending selected tasks to frontier models may improve performance, but it raises questions about data flow and service dependencies. Persistent memory can cut down on repeated instructions, but it also makes retention and user control more important. Tighter restrictions may reduce risk, but they can also limit the agent's usefulness.
A grounded adoption decision comes down to four questions:
- Is the workflow worth automating? Repetitive work with a clear outcome beats a vague goal to "use AI."
- Can permissions stay narrow? If the agent needs broad access just to be useful, the risk may outweigh the savings.
- Can the organization observe and interrupt it? Controls should be testable, auditable, and usable by the people who handle incidents.
- Do the measured benefits exceed the full cost? Include devices, configuration, oversight, integration work, and exception handling.
Arc looks strongest when its security layers work as described and fit cleanly into your existing controls. The announcement is a reason to evaluate - not a reason to skip the evaluation. Before deployment, verify supported configurations, data flows, retention behavior, policy administration, audit capabilities, and the exact boundary of hardware enforcement.
For more context, read ServiceNow and Nvidia's Arc announcement coverage from ZDNET, and review the vendors' documentation for current product and deployment details.
Conclusion
Arc's central idea isn't just a persistent assistant - it's the attempt to connect enterprise policy with runtime and hardware enforcement. That's a real response to a barrier many teams face when considering agents. Still, layered controls don't remove the need for careful permissions, testing, and operational ownership.
Start with one workflow. Grant only the access it needs. Test how the system behaves when permissions are revoked or when an action goes outside its boundaries. Measure time saved alongside corrections, blocked tasks, and oversight costs. If the controls hold up under those conditions, expand carefully. If they don't, keep the agent in a narrower role until they do.
A more reliable path to enterprise AI is to evaluate the controls you're betting on, not to assume the guardrails are enough. Review the current vendor documentation and run a controlled pilot before making Arc part of a production workflow.