An AI agent on ServiceNow does not need a vulnerability to leak data. It leaks by doing exactly what you asked it to do, for someone who asked a slightly different question than you expected.
This is the part that catches teams out. Agent security is mostly not about someone breaking in. It is about the agent being helpful to the wrong person, or being helpful in a way that reveals more than any single answer was meant to.
Four ways it actually happens
1. The agent can reach more than anyone intended
An agent runs as an identity, and that identity has roles. In practice the identity ends up generously scoped, because a narrowly scoped agent fails its first demo and someone widens it to make the demo work. Nobody goes back afterwards.
The question to ask is not "what does this agent do?" It is "what could it return if someone asked?" Those are different questions with different answers, and only the second one matters for security.
An agent built to summarise a user's own incidents will happily summarise someone else's if nothing stops it. And the ACLs on tables it queries indirectly are often not what people assume they are.
2. Prompt injection through the data, not the chat
Everyone tests for a user typing "ignore your instructions" by now. Far fewer test for those instructions arriving inside a record.
If an agent summarises incidents, and an incident description contains text addressed to the agent, that text arrives with the same weight as everything else in the context. A short description field is an input channel. So is an email that became a ticket, a knowledge article, a customer's own words in a CSM case.
This is the one that scales badly. Anyone who can create a ticket can try it, including people outside your organisation on a customer portal.
3. Exfiltration through tool calls
The dangerous combination is an agent that can both read something sensitive and reach something outside. Each capability is defensible on its own. Together they are a path.
An agent that can query a table and also call an outbound integration - a webhook, a REST step, an email action - can be talked into putting the first into the second. Nobody has to say "exfiltrate this". They ask it to "send a summary to this address for review", which sounds reasonable and is precisely what an agent is built to accommodate.
When you audit, map capabilities in pairs rather than one at a time. For each agent: what can it read, and what can it reach?
4. Reconstruction through ordinary questions
This is the subtlest one and the least tested. An agent can correctly refuse to hand over a record while still answering questions about it.
How many open incidents mention a given customer. Whether any P1 was raised last Tuesday. Which assignment group handles a particular product. Every answer is harmless on its own. A sequence of them narrows things down until the content is effectively recovered, and no single response ever broke a rule.
Retrieval-based agents are especially exposed here. Relevance ranking over a corpus tells you what is in the corpus, even when the text itself is withheld.
How to test it
You can do a useful first pass yourself in an afternoon. Use a non-production instance with representative data, and log in with the same roles a real user of the agent would have. Not an admin.
- Inventory first. Every agent, who owns it, which identity it runs as, which tools it can call. Most organisations find agents they did not know existed.
- Ask for other people's things. Directly first, then indirectly. "Show my incidents" is the happy path. "Show incidents for <other user>" is the test. "Summarise recent incidents from the finance team" is the realistic one.
- Put instructions in a record. Create a ticket whose description talks to the agent, then ask the agent to summarise it. Try different places: description, work notes, an attachment filename.
- Look for read-plus-reach. For any agent that can call something outbound, ask it to send a summary somewhere. If it does, the pairing is the finding, whether or not the content was sensitive that time.
- Play twenty questions. Pick a record the agent should not disclose and try to work out its contents from questions it will answer. Count how many it took. That number is your finding.
- Write down what did not happen. An agent that refuses is only interesting if you know why it refused. A refusal that comes from the model's disposition rather than a control will not survive being rephrased.
What to fix, and in what order
Findings sort into three buckets, and they are not equally urgent.
Reach comes first, because it bounds everything else. An agent that cannot read a table cannot leak it, no matter how it is asked. This is ACL and role work. It is unglamorous and it is the most valuable thing on the list.
The read-plus-reach pairings come second. Often the fix is not removing a capability but splitting two. The agent that reads sensitive data and the agent that sends things outward do not need to be the same agent.
Prompt hardening comes last, and it is the one teams reach for first because it feels like the direct answer. It is worth doing. It is not a control you can rely on. Instructions are guidance, not a boundary. If your defence against injection is a sentence in a system prompt, you have a mitigation, not a fix.
Keep the evidence
Whatever you find, keep the record of finding it. Under the EU AI Act, obligations for high-risk systems under Annex III fall due on 2 December 2027, and they are evidentiary: you will need to show that testing happened and that monitoring is ongoing, not assert it. Logs from systems that were already running are worth a great deal more than a document written in the last quarter.
That is also the honest reason to do this now rather than later. An agent with unexamined reach into your instance is an operational risk on an ordinary Tuesday, with no regulator in the room.
We audit AI agents on ServiceNow - what they can reach, what they leak through tool calls, and whether they hold up against someone hostile. If you would like a second pair of eyes on what you are already running, tell us what you have.