When Agents Talk to Each Other

ServiceNow's Now Assist is a generative AI platform embedded into one of the world's most widely deployed enterprise service management products. Companies use it to automate help-desk operations, incident management, workflow routing, and dozens of other tasks that used to require a human looking at a ticket and deciding what to do with it. The pitch is exactly what every enterprise AI product promises: fewer people handling more tickets, faster resolution times, lower costs.

Now Assist doesn't rely on a single AI agent to handle everything. It uses multiple specialized agents that collaborate on tasks. An agent designed to triage customer requests can pass work to an agent designed to retrieve data, which can hand off to an agent that sends notifications. This multi-agent architecture is pitched as a feature - agents can discover each other, divide labor, and handle complex workflows without manual configuration.

In November 2025, Aaron Costello, chief of SaaS Security Research at AppOmni, published findings showing that this agent collaboration feature could be weaponized through second-order prompt injection to exfiltrate sensitive corporate data, modify records, and escalate privileges - all without any human ever seeing it happen.

Three Defaults

The vulnerability isn't a coding error. It's a consequence of three default configuration settings that ship with Now Assist.

First, the underlying large language model has to support agent discovery. Both Azure OpenAI LLM and Now LLM (which is the default choice for Now Assist deployments) support the feature. So on a standard installation, agent discovery is available out of the box.

Second, Now Assist agents are automatically grouped into the same "team" by default. Any agent on the team can invoke any other agent on the team. There's no approval step, no permission boundary between them. If Agent A needs something from Agent B, it just asks.

Third, every agent is marked as "discoverable" by default when it's published. An administrator would have to go in and explicitly turn off discoverability for each agent individually. On a platform where companies may have deployed dozens of agents across different departments, this means they're all visible and callable by any other agent from the moment they go live.

Each of these defaults is individually reasonable. Together, they create a system where any agent that processes external input can recruit any other agent to do anything that agent is capable of doing.

"This discovery is alarming because it isn't a bug in the AI; it's expected behavior as defined by certain default configuration options," Costello said.

Second-Order Prompt Injection

Standard prompt injection attacks involve a user directly feeding malicious instructions to an AI system. Second-order prompt injection is different. The malicious prompt isn't submitted by the user interacting with the AI. It's planted in data that the AI reads during the course of its normal operations.

In the ServiceNow case, an attacker embeds carefully crafted text into content that a low-privileged agent routinely ingests - a customer support ticket, a knowledge base article, a form field, or any other data source the agent is configured to read. The agent processes the text as part of its normal workflow. The embedded instructions redirect the agent to recruit a more powerful agent and use that agent's capabilities to perform actions the original agent couldn't do on its own.

The part that makes this particularly effective: Now Assist agents run with the privileges of the user who started the interaction, not the user who planted the malicious prompt. If a system administrator happens to trigger a workflow that causes an agent to read the poisoned content, the entire chain of agent actions executes with administrator privileges.

AppOmni laid out a concrete scenario. A low-privileged "Workflow Triage Agent" receives a malformed customer request containing the injection payload. The agent interprets the embedded instructions and generates an internal task requesting a "full context export" of an ongoing case. That task is automatically routed to a higher-privileged "Data Retrieval Agent," which treats the request as legitimate since it came from another agent on its team.

The Data Retrieval Agent compiles a package of sensitive information - names, phone numbers, account identifiers, internal audit notes - and sends it to an external notification endpoint that the system trusts as a valid destination. Both agents assume the other is acting on a legitimate request. The data leaves the organization without any human reviewing or approving the action.

Built-in Protections Don't Help

Now Assist does include prompt injection protections. Costello's finding was that the attack works even with those protections enabled. The guard rails are designed to catch direct prompt injection - someone typing malicious instructions into the chat interface. They don't adequately address second-order injection via data that agents read during their workflows.

A benign agent can parse the injected prompt embedded in content it's authorized to access, recruit a more capable agent, and direct that agent to read or modify records, copy data, or send emails. The built-in protections don't flag inter-agent requests as potentially tainted by external input, because the system treats agent-to-agent communication as internal and trusted.

This is a pattern that shows up repeatedly in multi-agent AI systems. The trust boundary between agents is implicitly set to "full trust" because the agents are all part of the same platform. But if any agent in the chain processes data from outside the trust boundary - which is the entire point of customer-facing agents - that implicit trust becomes a liability. One compromised agent can act as a proxy for an attacker, leveraging the capabilities of every other agent it can discover.

ServiceNow's Response

Following AppOmni's responsible disclosure, ServiceNow's initial position was that the system "works as intended." The agent-to-agent discovery and the default configurations that enable it are features, not bugs. ServiceNow did update its documentation to more clearly describe the potential risks associated with these configuration settings.

The company didn't ship a patch because, from their perspective, there was nothing broken. The defaults were designed to make agent deployment easy. Requiring administrators to manually configure security boundaries for each agent would add friction to the setup process, and adding friction to setup is not how enterprise software companies sell more seats.

Costello recommended several mitigations: configure supervised execution mode for privileged agents, disable the autonomous override property (a setting called "sn_aia.enable_usecase_tool_execution_mode_override"), segment agent duties by team so they can't freely recruit across departmental boundaries, and implement real-time monitoring of agent behavior.

These are all configuration changes that administrators can make. The question is whether they will. A property named "sn_aia.enable_usecase_tool_execution_mode_override" is not the kind of thing that shows up on a deployment checklist unless someone already knows to look for it.

A Separate Vulnerability in the Same Platform

AppOmni's work on ServiceNow didn't stop with the agent-to-agent injection finding. Costello also discovered a separate vulnerability in the integration between the Virtual Agent API and Now Assist that allowed unauthenticated attackers to impersonate any ServiceNow user by providing only an email address.

The vulnerability chained a hardcoded, platform-wide secret with account-linking logic that trusted a bare email address for authentication. An attacker could impersonate an administrator and use AI agents to override security controls and create backdoor accounts with full privileges. The affected versions were Now Assist AI Agents (sn_aia) 5.0.24 through 5.1.17 and Virtual Agent API versions up to 3.15.1 and 4.0.0 through 4.0.3.

ServiceNow treated this second finding differently. The company acknowledged receipt on October 23, 2025, deployed a fix on October 30, emailed affected customers, and published a knowledge base article crediting Costello and AppOmni.

The contrast between the two responses is instructive. When the problem is a clear-cut authentication bypass, ServiceNow moved quickly to patch and notify. When the problem is a design-level issue with default configurations, the response was to update the documentation. Both findings came from the same researcher examining the same platform, but only one produced a code fix.

Configuration as Attack Surface

"If organizations using Now Assist's AI agents aren't closely examining their configurations, they're likely already at risk," Costello said.

The ServiceNow case demonstrates a specific risk that grows as enterprises deploy more AI agents: the attack surface isn't just in the AI model or the code. It's in configuration defaults that were chosen for convenience rather than security. Agent discovery, team grouping, and discoverability are all features that make it easier to set up and manage agents at scale. They also make it easier for a single poisoned data point to cascade through an entire agent ecosystem.

Auditing agent configuration and monitoring agent-to-agent communication at scale becomes harder as the number of agents increases. Each new agent adds relationships to every other discoverable agent in its team. The number of potential interaction paths grows faster than the number of agents. An organization that deploys fifty agents doesn't have fifty things to monitor - it has thousands of possible agent-to-agent communication paths, any one of which could be carrying instructions planted by an attacker in a support ticket submitted three weeks ago.

The mitigations are available. The defaults, however, favor usability. And in enterprise software, the defaults win most of the time.