The Tool Response Is Not Your Boss

TL;DR for operators

The paper’s useful message is not “LLM agents are unsafe,” which is too vague to help anyone do anything before lunch. The useful message is narrower and more operational: agents become vulnerable when untrusted content from SaaS integrations is read into the agent context and then treated as authority for a later action.

AgentRedBench tests this failure mode with 215 subtle underspecified-authorization scenarios across 24 enterprise integrations, including Gmail, Slack, Salesforce, Jira, calendars, HRIS, ATS, CRM, storage, and productivity tools.¹ In the no-guard setting, attack success rates across the eight tested frontier models range from 32.1% to 81.4%. That range matters: the best-aligned model is meaningfully better, but alignment alone does not remove the enterprise control problem.

The paper’s proposed guard, AgentRedGuard, is not a giant reasoning model wearing a security badge. It is a 23M-parameter classifier trained on adversarial tool-response content. In the paper’s recorded-trace evaluation, it reduces panel ASR from 69.9% to 2.4% at 0.37% false-positive rate and 9.5 ms median CPU latency. That is the right shape of result for enterprise deployment: small, inline, boring, and therefore possibly useful.

For business teams, the translation is straightforward: do not secure agents only at the chat boundary. Build controls at the integration boundary. Treat tool responses as untrusted input, inspect them before they enter the agent loop, bind write destinations to original trusted metadata, prevent untrusted content from becoming write-body authority, and red-team the read-to-write chains your agents actually execute.

The boundary is also important. The benchmark is an upper-bound stress test because the canonical scenarios are filtered for achievability. The integrations are mocked. The guard’s ASR reduction is computed over recorded traces rather than full live re-execution under blocking. Multi-connector chains are included as a scenario set, but their full evaluation is deferred. So the result is not a final security guarantee. It is a map of where the control plane should move.

The dangerous sentence is not in the chat box

Picture the normal enterprise-agent demo. A user asks an assistant to triage email, summarize a customer account, update a ticket, and notify the right person. The agent reads from Gmail, Salesforce, Jira, Slack, and perhaps a calendar. Then it writes back into one or more of them.

The demo feels safe because the user’s instruction is benign. The system prompt may be clean. The agent code may be well intentioned. The model may even have a respectable alignment pedigree, polished to a nice executive sheen.

The problem is that the user is not the only writer in the room.

An email body can be written by an external sender. A calendar description can be written by an invite organizer. A Salesforce note can be edited by a partner. A Jira ticket can contain text from a customer, contractor, employee, or attacker. Once agents read those fields, the fields are no longer passive records. They become live instructions unless the system prevents that conversion.

That is the central mechanism in AgentRedBench. The attack does not need to seize the chat interface. It rides in tool-response content. The agent reads it while doing a legitimate task. Then the agent writes somewhere else, subtly changing the recipient, body, link, argument, or destination. The poison travels through normal workflow.

A less precise reader will call this “prompt injection.” That is true but not sufficient. Prompt injection is the genre. The paper’s real object is the read-write authority gap in enterprise integrations.

The mechanism: untrusted reads become unauthorized writes

The paper evaluates tool-use agents that operate through a loop:

1. A benign user gives a legitimate request.
2. The agent calls tools against enterprise integrations.
3. The integrations return content.
4. The agent reads that content into its context.
5. The agent decides whether to call another tool.
6. A write action occurs.

The adversary controls only integration content. They do not control the user prompt, system prompt, agent code, tool schema, or model weights. This constraint is what makes the benchmark useful. The attacker is not granted magical access. They are granted the kind of access real attackers often have: the ability to place content in systems the agent later reads.

The paper’s attack family is called underspecified authorization. This is a more interesting class than the cartoon version of prompt injection where a payload says, in effect, “ignore all previous instructions and do crimes.” Frontier models have seen that movie. They may not always behave, but the plot is familiar.

Underspecified authorization works because business requests often leave gaps. “Email the summary to the account owner.” Which account owner? From which field? “Reply if urgent.” Who is the reply addressed to? “Use the template from the ticket.” Which parts of the ticket are formatting guidance, and which parts are attacker-controlled content? The attack lives in those gaps.

The paper formalizes five attack types, three of which are the main active surfaces:

The other two categories, tool_argument_hijack and tool_family_creep, are included largely to document a boundary. In the paper’s panel, explicit user bounds such as “update only the description” or “do not post comments” keep these patterns near 0–2% ASR. That is an important result, though less theatrical. Sometimes the boring instruction works. Security people should cherish such moments; they are rare and deserve a chair.

The key distinction is that the active attacks exploit ambiguity in authorized actions. They do not ask the agent to do something obviously forbidden. They persuade the agent that the malicious detail is part of the authorized task.

Why a generic chat guard misses the point

A common misconception is that prompt-injection defense is mostly a chat-safety problem. Add a jailbreak detector. Add a content-safety classifier. Add a stern system prompt with the moral seriousness of a laminated office policy. Surely that helps.

AgentRedBench suggests the distribution is wrong.

Tool responses do not look like chat. They look like records, metadata, errors, calendar descriptions, CRM notes, HRIS fields, issue bodies, pagination envelopes, permissions messages, and short structured payloads. The text may contain business jargon, template fragments, audit language, routing instructions, or operational metadata. A generic chat guard is trained to police conversations. The dangerous object here is not a conversation. It is a data field trying to become an instruction.

The paper’s baseline comparison is therefore more than a leaderboard exercise. It tests whether existing open-source guards transfer to tool-response content. The answer is mostly no.

At threshold 0.5, on the cross-integration held-out detection task, Llama Guard 3 achieves 0.15% TPR with 2.39% FPR. PromptGuard 2 achieves 0.00% TPR with 1.93% FPR. WildGuard reaches 0.25% TPR with 0.12% FPR, which is a polite way of saying it mostly stays asleep. ProtectAI detects more attacks at 15.03% TPR, but with 25.05% FPR, which is not a guard so much as a productivity tax with opinions.

AgentRedGuard-MiniLM, by contrast, reports 99.75% TPR and 0.37% FPR on the same held-out detection framing. The larger DeBERTa variant reports 99.90% TPR and 0.29% FPR. The larger model does not materially change the operational story. The smaller classifier is already in the right distribution.

That is the paper’s quiet architectural point. The defense works not because it reasons like a senior security analyst, but because it sits at the correct layer and sees the correct kind of data.

The benchmark matters because the attacker is not a fixed string

AgentRedBench is not just a set of copied injection prompts replayed until models look foolish. The benchmark uses a dynamic attacker that generates injection content per run, conditioned on the integration schema, attack type, target user request, and judge feedback from prior failed attempts.

This matters because static prompt libraries age badly. Once the payload is known, it can leak into training data, be memorized, or become a pattern that guards can overfit. A static benchmark can become a spelling test. The model learns the bad sentence; the enterprise learns very little.

The canonical benchmark contains 215 subtle scenarios across 24 integrations in nine functional families. It covers productivity, communications, calendar, CRM, storage, applicant tracking, HRIS/payroll, observability, and marketing/other systems. The listed connectors include familiar enterprise surfaces: Gmail, Slack, Microsoft Teams, Jira, Linear, Notion, Salesforce, HubSpot, Google Drive, Greenhouse, BambooHR, PagerDuty, and others.

The release model is also part of the contribution. The authors release code, integration schemas, and AgentRedGuard, but keep the canonical scenario set under maintainer-mediated evaluation. This is annoying for immediate reproducibility in the casual sense, but it is defensible for benchmark integrity. If every scenario and payload becomes public, future ASR numbers risk measuring contamination rather than resistance. Benchmark governance is not glamorous. Neither is flossing. Both prevent decay.

The paper also includes a scenario schema with explicit attack_type, allowed connectors, target user prompt, success criteria, and utility criteria. This matters because the judge is not merely grading vibes. Each scenario carries observable success signals such as a destination string, URL, or token. That reduces—but does not eliminate—the fuzziness of LLM-as-judge evaluation.

The no-guard result is bad, but not uniformly bad

Across the eight tested frontier models, no-guard ASR ranges from 32.1% to 81.4%. The broad conclusion is obvious: unguarded agents remain vulnerable to subtle integration-layer attacks.

The more useful interpretation is in the spread.

Claude Sonnet 4.6 is the most resistant model in the paper’s panel at 32.1% ASR. The next-best model, GPT-5.4-nano, is at 63.7%. Claude Haiku 4.5 is at 79.5%, creating a 47.4-point spread within the same provider family. Gemini variants cluster high, from 78.6% to 81.4%. GPT-5.4 variants cluster between 63.7% and 72.6%, with the smallest variant more resistant than its larger siblings in this panel.

That pattern complicates the usual “bigger model equals safer model” story. The paper reads the discontinuity as alignment-driven rather than scale-driven. That interpretation is plausible because tool-response injection is not solved by raw capability. The model has to respect authority boundaries between user intent, system instruction, and untrusted external content.

But even the strongest model in the panel leaves nearly one-third of attacks succeeding in this stress setting. That is not a deployment strategy. It is a warning label with a confidence interval.

AgentRedGuard works because it blocks before context contamination

The proposed defense, AgentRedGuard, sits inline between tool responses and the agent’s context. When a tool response arrives, the guard classifies whether it contains attack content. If flagged, the response is intercepted before the agent reads it.

This placement is the article’s central business lesson. Once malicious content enters the model context, the agent has to reason its way out of contamination. That is possible sometimes. It is not a control system. Intercepting at the tool-response layer is cleaner: do not allow untrusted content to become part of the instruction substrate in the first place.

The model itself is deliberately small. AgentRedGuard-MiniLM has 23M parameters. It is trained on 14,846 attack-containing tool-response rows and 4,807 production-shape benign rows, including real HRIS, ATS, and CRM hard negatives, synthetic structural benigns, and clean tool outputs across the benchmark’s integrations. Four integrations—Slack, Linear, Salesforce, and Calendar—are held out entirely for cross-integration testing.

The main reported operational result is strong: AgentRedGuard-MiniLM reduces overall panel ASR from 69.9% to 2.4%, a 67.5-point reduction, in the paper’s per-trace prevention estimate. It does so at 0.37% FPR and 9.5 ms median CPU latency per tool response.

That latency number is not decorative. Enterprise controls fail when they are correct but too slow, too expensive, or too operationally awkward. A 23M-parameter CPU classifier is a different deployment proposition from a 7B or 8B LLM guard requiring GPU serving. It can plausibly sit inside an agent gateway or integration proxy without turning every task into a small distributed-systems apology.

What the experiments actually support

The paper contains several result types. They should not be mentally thrown into one bucket labeled “evidence.” Some results are main evidence. Some are ablations. Some are robustness tests. Some are implementation details. Mixing them together is how technical readers become confident and wrong, a popular combination.

This table is the difference between “the paper shows X” and “I enjoyed the abstract and have decided X.” The paper is strong on single-connector subtle attacks and inline tool-response detection. It is more tentative on live guarded execution dynamics and multi-connector chains.

The guard comparison is really a distribution-shift result

The strongest lesson in the guard comparison is not merely that AgentRedGuard wins. Of course it wins; it is trained for the benchmark’s data distribution. The more important result is that standard guard families are nearly inert when moved from chat-style data to tool-response data.

This is the same enterprise mistake seen in other security domains: teams deploy a control trained for one surface and assume the label generalizes. A web filter is not an endpoint detector. A DLP regex is not an access-control model. A chat jailbreak guard is not automatically a SaaS tool-response guard. The acronym is similar. The threat surface is not.

The ProtectAI baseline illustrates the opposite failure. It detects some attacks, but its false-positive rate is too high. The per-source FPR table is especially revealing: ProtectAI severely over-flags structural benign responses such as permission errors and pagination metadata. In a real workflow, this means the guard would disrupt normal tool use, particularly in the dull corners where enterprise software spends most of its life returning short metadata, empty lists, and authentication complaints. As usual, the boring edge cases are where the deployment bill arrives.

AgentRedGuard’s 0% FPR on 2,500 production connector hard negatives is therefore more relevant than it first appears. It suggests the classifier is not merely learning that “structured enterprise-looking text is suspicious.” It can separate malicious-looking tool content from normal integration payloads, at least within the tested corpus.

Business implication: secure the integration layer, not only the model

The practical pathway from this paper to enterprise deployment is not “use AgentRedGuard and declare victory.” That would be convenient, and therefore suspicious.

The practical pathway is a control architecture for agents operating over SaaS systems:

The business relevance is especially direct for companies building agents over Gmail, Slack, Salesforce, Jira, Zendesk, Workday-like HR systems, ATS platforms, shared drives, calendars, support systems, and CRM records. The risk is not theoretical “AI weirdness.” It is ordinary workflow automation taking instructions from text fields that were never supposed to be command channels.

This shifts the procurement question. Do not only ask whether a model is safe. Ask how the agent runtime treats external content. Ask whether tool responses are classified, sandboxed, quoted, stripped, provenance-tracked, or privilege-separated. Ask whether write actions bind destinations to trusted fields. Ask whether the system can explain which untrusted source influenced a write. Ask whether the vendor tests dynamic cross-integration attacks rather than replaying a small injection phrasebook from 2024 and calling it governance.

The model matters. The integration runtime matters more than many teams currently admit.

The benchmark also says alignment helps, but does not finish the job

Claude Sonnet 4.6’s lower ASR is not noise. The paper treats it as evidence of an alignment-time floor: model-side training can make a large difference. That is good news. It means not all defenses must be bolted on at inference time.

But the same result also argues against relying on alignment alone. First, the best model still has 32.1% ASR in the no-guard stress set. Second, model families behave differently, and smaller or cheaper tiers may be deployed in agent workflows where cost pressure is stronger than security discipline. Third, enterprise systems rarely standardize on one model forever. A security architecture that depends on the current top model staying top is less a strategy than a subscription with anxiety.

The paper’s guarded results suggest alignment-time and inference-time defenses can be additive. The most resistant model benefits from the guard, and the more vulnerable models benefit dramatically. That is the correct enterprise posture: improve the base model, then assume the integration layer still needs controls.

The limitations are not footnotes; they define where to use the result

The paper is useful because its boundaries are fairly legible.

First, the 215 canonical scenarios are Haiku-filtered. They were selected from a larger candidate pool because Claude Haiku 4.5 achieved at least one success or partial verdict during authoring. That makes the scenario set an upper-bound stress test, not an unbiased sample of all possible enterprise tasks. For model comparison, this is acceptable: every model faces the same fixed stress set. For absolute risk estimation, it is not enough.

Second, the integrations are mocked. The mocks expose the relevant tool schemas and controlled state, which isolates the experimental variable. But real enterprise systems contain messier permission models, historical context, API quirks, rate limits, user-specific configurations, and administrative controls. Some of those may reduce risk; others may create delightful new ways to suffer.

Third, the guarded ASR reduction is computed over recorded traces. The paper asks whether AgentRedGuard would have flagged any tool-response step in each recorded attack trace. If yes, the scenario is counted as prevented. That is reasonable for deterministic trace analysis, but it is not the same as re-running the live agent with blocking enabled and observing whether it retries, routes around the block, abandons the task, or completes through another path. The paper explicitly notes this boundary.

Fourth, utility is only partially resolved. The guard reports low FPR, including 0% on production connector hard negatives, and the latency is operationally plausible. But full end-to-end task-completion under inline guarding is deferred. In enterprise use, false positives are not abstract. They become missed replies, blocked support workflows, and employees discovering yet another reason to use the system less.

Fifth, multi-connector chains remain the next frontier. The paper includes 49 scenarios covering chained patterns such as privilege escalation, evidence fabrication, context contamination, reply-thread injection, misinformation propagation, and cross-connector composition. But experiments on that set are deferred. This matters because real agents often read from one system and act in another. The single-connector results are already uncomfortable. The multi-connector version is where the office furniture may start moving by itself.

What an enterprise should do with this tomorrow

The lowest-effort interpretation is to add a prompt-injection detector somewhere in the stack. That is better than nothing, which is the traditional benchmark for many AI security programs. But the paper points to a more disciplined implementation.

Start by mapping every agent workflow as a read-to-write graph. Which integrations can the agent read? Which integrations can it write? Which read fields can influence destinations, bodies, arguments, permissions, or follow-up tool calls? The risk is not evenly distributed across the graph. A read-only summarizer is not the same as an assistant that reads external email and sends internal approvals.

Then classify tool responses before they reach the model context. This can be a learned classifier, a rules layer, a sanitizer, or a combination. The point is placement. Waiting until the final model output is too late, because the malicious content may already have shaped the plan.

Next, bind destinations to trusted metadata. If a user asks the agent to reply to an email, the recipient should come from the email envelope or trusted message metadata, not from the body text saying “please reply to this other address.” If the agent updates a ticket, field-level permissions should be explicit. If the task says “only update description,” the runtime should enforce that constraint structurally rather than hoping the model remembers.

Finally, test against your actual connector schemas. The paper’s dynamic attacker is not a decorative research flourish. It reflects a practical reality: attackers adapt to field names, workflow conventions, templates, and business language. If your benchmark does not know what your tools look like, it is mostly testing your optimism.

The conclusion: agents need a customs checkpoint

AgentRedBench is valuable because it moves the conversation from “Can the model resist prompt injection?” to “Where does untrusted content cross into authority?” That is the right question.

The paper’s mechanism is simple enough to be uncomfortable. Enterprise agents read from systems other people can write into. The agent then acts with permissions the user granted. Unless the runtime enforces boundaries, attacker-controlled records can become operational instructions. This is not science fiction. It is office automation with insufficient customs control.

The paper’s proposed answer is correspondingly practical: build a guard at the tool-response layer, train it on the data shape it will actually see, and evaluate it against dynamic attacks over real integration surfaces. AgentRedGuard is not the final word. It is a strong argument about where the next layer of defense belongs.

The business lesson is not to stop building agents. That ship has sailed, hit three APIs, and opened a Jira ticket. The lesson is to stop treating SaaS content as if it arrives wearing a badge. A tool response is evidence. It is not authority. Until agents learn that distinction structurally, not just conversationally, every helpful workflow is also a possible routing channel for someone else’s instructions.

Cognaptus: Automate the Present, Incubate the Future.