In November 2025, AppOmni researcher Aaron Costello disclosed that ServiceNow Now Assist's agent-to-agent discovery feature could be manipulated through second-order prompt injection to make one agent recruit another, more privileged agent to perform unauthorized create, read, update, and delete (CRUD) operations on records and exfiltrate data by email — while ServiceNow's built-in prompt-injection protection was active. ServiceNow reviewed the finding, confirmed the underlying behaviors were intended given the platform's design, and updated its documentation to clarify the distinction rather than issuing a conventional patch. The incident is a useful case study not because a vendor made a mistake, but because it shows how a legitimate, well-documented collaboration feature can create an authorization gap that content filtering alone cannot close.

What agent-to-agent discovery does

Now Assist agents can be built to complete a single task by calling on other agents rather than requiring every capability to live in one workflow. If an agent it is talking to cannot complete a request itself, it can hand the task to another, more capable agent on the same team without a human explicitly wiring that connection in advance. Three configuration properties control this, all enabled by default: the LLM backing Now Assist must support agent discovery (both the default Now LLM and Azure OpenAI support it), the agents involved must belong to the same team (which happens automatically when agents are deployed to the same conversational channel, such as the default Virtual Agent experience), and each agent must be marked "discoverable," which is also the default when an agent is published. Behind the scenes, an orchestration component finds the most suitable discoverable agent on the team for a sub-task, and a reasoning engine manages the handoff.

None of this is a bug by itself — it is a genuinely useful pattern that reduces how much orchestration logic a builder has to hand-wire. The risk appears in how privilege and trust flow once that handoff exists.

How the second-order injection worked

Costello's research showed that any agent whose task involves reading a field populated by someone other than the person who invoked the agent is a candidate for this attack. In the demonstrated scenario, an admin user triggered a routine, low-privilege-looking task — summarizing an incident ticket — using an out-of-the-box "Categorize ITSM incident" agent. A separate, low-privileged user, who could create tickets but could not read other users' tickets, had earlier submitted a ticket whose description field contained instructions rather than an ordinary problem report: instructions directing whatever agent read it to retrieve the contents of a different, higher-privilege ticket the low-privileged user could not access directly, and copy that content back into a ticket the low-privileged user did own.

When the admin triggered the summarization task, the categorization agent read the planted instructions as part of the ticket content, could not complete them alone, and — through agent discovery — recruited the more capable "Record Management" agent on the same team, which could read and update records across the task table hierarchy. The critical detail is which privilege governed the resulting actions: Now Assist agents run with the privilege of the user who started the interaction — the admin — not the privilege of the user who planted the malicious content. The low-privileged user who could not read the sensitive ticket directly ended up with its contents copied into a ticket they did own, entirely through the admin's own session and without the admin taking any action beyond a routine summarization request. In further testing, the same pattern was used to attempt privilege escalation by assigning roles to a malicious account, and, on SMTP-enabled instances, to exfiltrate data out of band by email.

This is a second-order injection specifically because the payload does not act directly — it manipulates one agent into invoking a second, more powerful agent that carries out the actual damage. It is also a textbook instance of the confused deputy problem: a party without permission to perform an action gets a more privileged party to perform it on their behalf. For the general pattern, see the confused deputy problem in AI agents.

Why ServiceNow treated this as intended behavior, not a bug

ServiceNow's response, after Costello's disclosure, was to confirm that the individual behaviors — agent discovery, team-based grouping, running with the invoking user's privilege — were each working as designed, and to update platform documentation so administrators understand the interaction between them more clearly. That is a materially different outcome from the CVE-and-patch cycle typical of a code-level vulnerability, and it reflects something specific to this class of finding: the risk here is not a flaw in any single component but an emergent property of how several individually reasonable defaults compose. Disabling any one of the three enabling properties — LLM support, team membership, or discoverability — would break the collaboration feature outright rather than fixing a narrow bug. That framing does not make the finding less serious for an affected customer; it means the mitigation is a configuration decision each organization has to make deliberately, not a vendor-issued patch to apply and move on.

This distinction matters when evaluating any agent platform: ask not only "was this patched" but "was this a code defect or a composition of correct defaults," because the second category needs administrators to actively choose safer configuration, not wait for an update.

Documented mitigations

ServiceNow and AppOmni's research point to configuration controls that reduce exposure without disabling agent discovery entirely:

  • Use supervised execution mode for any agent with privileged tools. Tools that perform CRUD operations or send email should require human confirmation before executing, rather than running fully autonomously. Second-order injection is only exploitable end-to-end when the recruited agent's powerful tools run without a review step.
  • Confirm the sn_aia.enable_usecase_tool_execution_mode_override system property is set to false (its documented default). Setting it to true forces every tool on an agent with at least one autonomous tool to run autonomously, silently overriding any tool that was deliberately configured for supervised execution.
  • Segment agent duties by team. Grouping agents so that low-privilege, content-reading agents cannot discover high-privilege, record-modifying agents limits how far a successful injection can reach, even though it does not eliminate the underlying pattern.
  • Treat any field populated by a user other than the one invoking an agent as untrusted input, and review which agents read such fields as part of routine tasks — ticket descriptions, comments, and similar free-text fields are the highest-risk surfaces.
  • Monitor agent-to-agent conversations, not just individual agent outputs, for deviation from the task a human originally requested. A summarization request that results in a record update or an outbound email is the kind of divergence worth alerting on — the same detection principle covered in how to detect prompt injection.

What this means for multi-agent systems generally

The broader category of risk this incident sits within is covered in the AI agent security guide. The Now Assist incident generalizes past ServiceNow. Any platform that lets one agent delegate to another — a pattern increasingly common as A2A protocols mature — inherits the same question: when agent A recruits agent B, whose authorization actually governs the resulting action, and does the content that triggered the recruitment get to influence that decision? Securing inter-agent communication (A2A) and threat model: A2A delegation abuse cover this as a design question independent of any specific vendor. Sub-agent delegation with scoped tokens covers one structural mitigation: binding a delegated task to a narrower, purpose-specific credential rather than letting the recruited agent inherit the full privilege of the original invoker.

Praesidia is an AI agent security and governance control plane covering agent identity and access, guardrails, audit evidence, and cost controls; scoping what one agent can authorize another agent to do, independent of any single platform's default configuration, is directly relevant to closing gaps like the one this incident demonstrates.

Common questions

Was this vulnerability assigned a CVE? No. ServiceNow reviewed the finding and confirmed the individual behaviors involved — agent discovery, default team grouping, and agents running with the invoking user's privilege — were each functioning as intended, and addressed the issue by updating documentation rather than issuing a patch. This differs from a conventional code-level vulnerability disclosure, and is worth understanding when evaluating how seriously to weigh the finding for your own environment.

Does disabling agent discovery eliminate the risk? It removes this specific attack path, but agent discovery is also what allows agents to collaborate on tasks they could not complete alone, so disabling it outright is a real functionality trade-off. ServiceNow's documented mitigations — supervised execution for privileged tools, disabling the autonomous-override property, and segmenting agents by team — are designed to reduce risk while keeping the feature usable.

Why did ServiceNow's built-in prompt-injection protection not stop this attack? Because the exploited behavior was not primarily a content-filtering problem. The injected instruction did not need to evade a filter designed to catch malicious prompts; it exploited how privilege and task delegation flow once an agent decides to recruit another agent, which sits outside what a prompt-content filter inspects. This is a useful reminder that input filtering and privilege design are separate controls, and a strong filter does not substitute for scoping what an agent (or the agents it can recruit) is authorized to do.

Is this specific to ServiceNow, or does it apply to any multi-agent platform? The specific configuration properties are ServiceNow's, but the underlying pattern — one agent delegating to a more privileged agent, with the delegated action executing under the original invoker's authorization rather than the content author's — applies to any agent-to-agent collaboration architecture. Teams evaluating or building multi-agent systems on any platform should ask the same questions about privilege inheritance and delegation scope.

How should an organization detect if this pattern has already been exploited? Review agent-to-agent interaction logs, where available, for cases where a routine, low-privilege task resulted in a record modification, role assignment, or outbound communication that a human did not directly request. Post-incident forensics for AI agents covers how to reconstruct an agent's actual decision path from logged tool calls and delegation events when investigating a suspected case.