An AI agent that can call tools, read documents, or take actions on a user's behalf is a different kind of attack surface than a traditional web form. It does not just accept input, it interprets it, and interpretation can be manipulated. This is a plain-language walk through what a security review of an AI agent actually checks, why it is a distinct discipline from normal QA, and what it looks like when it is done well.

What an AI agent security review actually is

It is an independent, adversarial check of an AI agent, run before launch or during a build, that deliberately tries to make the agent misbehave rather than confirming it behaves correctly. This is the core distinction from functional testing: functional QA asks "does the agent do what it is supposed to do," and a security review asks "can the agent be made to do what it is not supposed to do." Those are different questions, and answering the second one takes a different mindset, not just more test cases.

A review of this kind typically centers on three categories, each covered below: prompt injection (getting the agent to ignore or override its own instructions), tool misuse (getting the agent to call a tool it has access to outside the scope it was meant for), and data exposure (getting the agent to reveal information it should not, including its own system prompt or another user's data).

Why this is a different problem from a normal bug

A conventional software bug is an unintended behavior that shows up under unusual but not adversarial conditions, an edge case nobody thought to test. Prompt injection is not that. It is an attacker deliberately crafting input specifically to make an AI system act against its own instructions, and the input does not have to arrive through the obvious channel. Direct injection happens in the chat box itself: "ignore your previous instructions" and its many variations. Indirect injection is the more consequential category, and the one that most internal QA misses: an instruction hidden inside a piece of content the agent reads as part of a normal task, a note field in a support ticket, the title of a document the agent retrieves, metadata attached to a file, anything the agent processes that was not typed directly by the person it is talking to.

Consider an illustrative example: a customer support agent that reads order notes to help resolve a ticket. If a note field on an order can contain arbitrary text, and nobody has treated that field as untrusted input the agent will read, an attacker who can influence that field (through a return request, a form submission, anything upstream) has a channel into the agent's context that a security review would specifically go looking for and that ordinary functional testing, which only exercises the paths the team already expects, would not.

What tool misuse means, concretely

Most AI agents built for real work are not just chatbots, they can call tools: look up a record, issue a refund, send an email, update a database, trigger a workflow. Each of those tools is a capability, and a capability is exactly what an attacker wants to redirect. Tool misuse testing asks, for every tool the agent can call, whether it can be manipulated into calling that tool outside its intended authorization, including through a multi-step, social-engineering-style conversation rather than a single obvious request. Can a scheduling agent be talked into accessing a calendar it should not see? Can a support agent be talked into approving a refund it should not have discretion over?

The reason this deserves its own category, separate from injection, is that a system prompt is an instruction, not an enforcement mechanism. Telling a model "only use this tool for X" is a strong hint the model will usually follow, but a determined or well-crafted input can talk a model out of following it. A tool-use boundary that actually holds needs to be checked in code, at the point the tool call is executed, independent of whatever the model has decided to do in that moment. That single distinction, instruction versus enforcement, is the one most teams building their first AI agent have not internalized yet.

What data exposure means, concretely

This category checks whether the agent can be induced to reveal something it should not: another user's data if the agent has broader database access than the current conversation needs, internal system details, or the agent's own system prompt and the schemas of the tools it has access to. System prompt exposure specifically is worth taking seriously beyond the immediate leak, because it hands an attacker a roadmap: once someone knows exactly how an agent is instructed and which tools it can call, crafting a more targeted injection or tool-misuse attempt gets considerably easier.

What a review concretely does, beyond the three categories above

A concrete example
Picture a small SaaS company launching an AI agent that helps customers manage their account, including issuing refunds under a certain dollar amount. A review of this agent would test, among other things, whether a customer can talk the agent into approving a refund above that threshold through a drawn-out, reasonable-sounding conversation, whether a crafted account nickname or support-ticket note can inject an instruction the agent then follows, and whether the agent's error state ever exposes a debug view that was only meant for internal testing. None of these are hypothetical categories. They are the exact places a review would look, precisely because normal functional testing of "does the refund flow work" would never think to try them.

How this fits into a build

A security review works best as an independent check, not a self-assessment, because a team evaluating its own system tends to test the paths it already trusts and skip the ones it has not considered. It can run as part of the AI governance and security engagement on its own, or be folded into a regular build engagement as a dedicated phase before launch. Either way, the output is a prioritized findings report and remediation support, and a fix that has not been re-tested afterward is unverified, since the injection surface changes every time a new tool or data source is added, so a pre-launch review is a snapshot of that system at that moment, not a permanent guarantee. For a fuller, step-by-step version of exactly what we test, see our AI agent security checklist, which walks through all ten categories in detail.

GreyScript AI runs these reviews and builds systems designed to hold up against prompt injection, tool misuse, and data exposure. We do not issue a security certification for an agent, since no such universal certification exists for AI systems in the way, say, a building inspection produces a pass or fail. What we produce is a findings report, ranked by severity, and the engineering work to close the gaps it finds.