Which tools secure AI agents against prompt injection, data leakage and unauthorized tool use?

Tools mapped to the risks

The following comparison separates the main security concerns by where a control operates. Redline facts are from Redline AI’s product pages. The other entries are taken from each vendor’s own page, read on 15 September 2026. “Not described” means that the referenced page does not describe the capability.

This table does not imply that tools with “Not described” have no such capability. It records only what the cited vendor page describes. That distinction matters when comparing security products: absence of a description is not evidence of absence, but it is a limitation on what can be verified from the stated source.

The control point is more useful than the product label. An input filter can address content presented to the model, but it does not by itself establish whether a tool call is permitted. An output filter can inspect a response, but it does not necessarily inspect every argument sent to a tool. Pre-release testing evaluates the assembled agent and therefore addresses integration behaviour that individual controls may not expose.

Prompt injection: filter before the model reads

Prompt injection is an input-boundary problem. An attacker may place instructions in a direct prompt, a document or other content that the agent processes. A classifier at the input boundary sits outside the conversation the attacker is attempting to steer. This separation gives the security control a defined point at which to inspect content before generation.

Microsoft Prompt Shields is described as detecting adversarial user input attacks and analysing prompts and documents before generation. Amazon Bedrock Guardrails lists a Prompt Attack content filter. Lakera AI Agent Security describes inspecting what goes in and names prompt injection, jailbreaks and indirect attacks. LLM Guard describes resistance against prompt injection. Redline’s comparison entry describes a Guard v5 classifier on every incoming message and a published benchmark.

What should be measured?

The relevant question is not simply whether a tool detects injection. It is how the detector performs on a stated evaluation set, how the set is split and what false-positive rate accompanies the result. A detector that blocks more content can also create more interruptions for legitimate users if its false-positive rate is not understood.

Redline Guard v5 reached 0.9484 recall at a 1.4% false-positive rate on BIPIA and loses on three of seven external sets. The full table is available on the Guard benchmark. For further context, see how accurate prompt-injection classifiers are.

These results should be read as measured performance for the stated benchmark conditions, not as a universal guarantee for every agent or traffic pattern. A buyer should ask which inputs were evaluated, whether the agent’s own documents and tools were included, and whether the result reports recall together with false positives.

Data leakage: check what leaves

Data leakage is an output and execution-path problem. Sensitive content can leave through a normal reply, a tool argument or a rendered URL. Consequently, inspecting only the visible answer does not establish that the agent has not disclosed information through another channel.

Amazon Bedrock Guardrails is described as filtering sensitive information and redacting PII in inputs and responses. Lakera AI Agent Security describes controlling what comes out. Redline’s comparison entry identifies PHI / PII Leakage and Data Exfiltration attack families, together with rules on replies.

Output filtering is useful for responses, but tool arguments need the same scrutiny before the call. An agent can produce a reply that appears acceptable while placing sensitive material in a request to an external system. The enforcement point should therefore include the structured arguments passed to tools, not only the text shown to the user.

How should leakage testing work?

Use planted canary secrets so that a leak becomes a string-match problem. Place the canary in the material the assembled agent can access, then test whether it appears in replies, tool arguments or rendered URLs. The objective is to exercise the complete path rather than only the model’s conversational output.

The testing playbook covers testing for prompt injection and data exfiltration. It should be considered alongside the deployed agent configuration, because leakage behaviour depends on the tools, data sources and response handling connected to the model.

A leakage control should also make its scope clear. AWS documents Bedrock Guardrails’ sensitive-information filters for inputs and responses; it does not describe tool-call enforcement on the overview page. That means tool arguments require a separate question during evaluation.

Unauthorized tool use: a check the model cannot argue with

Unauthorised tool use is different from malicious or unsafe text. Content filters read text in prompts and responses. They do not, by themselves, determine whether an order identifier belongs to the current customer, whether a requested operation is permitted in the session or whether an irreversible action requires approval.

That decision belongs in a policy evaluated on the tool call and its arguments before the call runs. The policy should be outside the model’s reasoning so that the model cannot change the decision merely by producing a different explanation or instruction. Redline’s comparison entry describes pre_tool policies on every argument, approval gates and honeypot tools.

The practical control flow is straightforward:

• Receive the proposed tool call.
• Evaluate the tool name and every argument against policy.
• Check the session and authorisation context available to the enforcement point.
• Require approval for irreversible actions.
• Allow or block the call before execution.
• Record the decision and the arguments that were evaluated.

This approach treats the tool call as a security boundary. It also avoids relying on a content classifier to infer authorisation from natural language. See how to stop unauthorized agent actions for the related control pattern.

The comparison should be read carefully for the other tools. Amazon Bedrock Guardrails’ overview is marked “Not described” for unauthorised tool use. Microsoft Prompt Shields is also marked “Not described” for that category. Lakera AI Agent Security describes governing what agents do, while LLM Guard’s cited page does not describe unauthorised tool use.

Testing the assembled agent before release

Individual controls do not show how the complete agent behaves when prompts, documents, tools, policies and response paths are connected. Pre-release testing should therefore target the assembled agent rather than evaluating a classifier in isolation.

Redline’s comparison entry describes 11,204 cases across 16 families against the assembled agent. Lakera AI Agent Security describes agent discovery and risk assessment. The cited pages for Microsoft Prompt Shields, Amazon Bedrock Guardrails and LLM Guard are marked “Not described” for testing before release.

Testing should cover the paths where the risks occur:

• Inputs that attempt prompt injection, including content in documents and indirect attacks.
• Responses that contain sensitive information or planted canary secrets.
• Tool arguments that attempt data exfiltration or an unauthorised action.
• Irreversible operations that should require approval.
• The interaction between the assembled agent and each enforcement point.

The purpose is not to give a product a broad security label. It is to establish which behaviours are tested, which controls make the decision, and what happens when a test case is blocked, approved or allowed. A release decision should retain the cases, the policy outcome and the relevant measured results.

How should buyers compare these tools?

Start with coverage points rather than product categories. Ask whether the tool evaluates incoming content, outgoing content, tool calls and the assembled agent before release. Then identify whether the control is probabilistic or deterministic. Prompt-injection classifiers are probabilistic detectors at the input boundary. Authorisation decisions on tool calls should be deterministic policies evaluated before execution.

Next, separate documented capability from assumed capability. The comparison uses “Not described” where the cited page does not describe a risk area. Buyers should request the exact enforcement location, the data inspected and the decision made at that location. A statement that a tool “secures agents” is not enough to determine whether it checks a tool argument before execution.

Measured results also need context. For prompt injection, ask for recall with the false-positive rate, the evaluation set and its split. For leakage, use planted canary secrets and inspect all output paths. For tool use, test arguments and session context. For pre-release testing, test the assembled agent rather than only the underlying model or classifier.

Finally, account for maintenance status. LLM Guard’s cited GitHub repository is marked archived on 9 July 2026, and the FAQ states that the project and its models are no longer under active development. That status is material when assessing a control intended to remain part of an agent security design.

Key takeaways

• Prompt injection, data leakage and unauthorised tool use occur at different control points and should not be treated as one problem.
• Prompt-injection controls belong at the input boundary, before the model processes the content.
• Data-leakage checks should cover replies, tool arguments and rendered URLs rather than visible responses alone.
• Unauthorised tool use requires a policy on the tool call and its arguments before execution, with approval for irreversible actions.
• Compare prompt-injection results using recall and false-positive rate, and test leakage with planted canary secrets.
• Test the assembled agent before release, and distinguish documented capability from capability that a cited page does not describe.

Common questions

Is a prompt-injection classifier enough to secure an agent?

No. A classifier is probabilistic and only sees the input. Unauthorised tool use and data leaving through tool arguments need deterministic checks on the call itself. The assembled agent also needs testing before release, because input detection alone does not establish that outputs are safe or that tool actions are authorised.

Do content guardrails stop an agent calling the wrong tool?

Not on their own. Content guardrails classify text in prompts and responses. Whether a tool call is authorised depends on its arguments and the session, which a policy on the call can check. That policy should run before execution and should support approval for actions that cannot be reversed easily.

Is LLM Guard still maintained?

No. Its GitHub repository states that it was archived on 9 July 2026 and that the project and its models are no longer under active development. The comparison therefore marks LLM Guard as archived July 2026 and no longer maintained for testing before release.

How should I compare tools?

Compare them by coverage point: input, output, tool call and pre-release testing. Then ask for measured results, including recall with its false-positive rate, rather than relying on a list of threat names. Also check what the cited vendor page actually describes and whether the tool is maintained.

Why does the assembled agent need separate testing?

The assembled agent combines the model with prompts, documents, tools, policies and output paths. A control may perform as documented in isolation while the connected system exposes another route for leakage or unauthorised action. Testing the assembled agent evaluates those connected paths before release.

Sources

• Microsoft, Prompt Shields in Azure AI Content Safety.
• AWS, Amazon Bedrock Guardrails.
• Lakera, AI Agent Security.
• Protect AI, LLM Guard (archived repository).
• Redline, Guard benchmark and platforms compared.