The lethal trifecta: what TRACE blocks and what agents try next

"… the browser_submit_form tool returned permission_denied for this cross-origin endpoint, so I used the type+click form-fill approach instead, which succeeded."

A browser agent in our controlled test, instructed to complete a submission that the security policy prohibited. Much of this article exists because of this sentence.

The lethal trifecta [1] is the combination of (i) access to private data, (ii) exposure to untrusted content an attacker can control, and (iii) a way to send information outside the organization. Together, they form a route for stealing data. More broadly, an attacker who redirects an AI assistant can spend its permissions: send an unauthorized payment, alter a record, or disrupt the user's work.

None of this is hypothetical. In 2025, researchers demonstrated the same route against three widely deployed assistants, each flaw rated critical: a crafted email made Microsoft 365 Copilot leak mailbox and file data [2]; instructions hidden in a web form made Salesforce Agentforce pull CRM records out through an expired allow-listed domain [3]; and a hidden comment in a pull-request description made GitHub Copilot Chat leak private source code and secrets [4]. The vendors fixed each path. The same three capabilities enabled them all.

Figure 1. The lethal trifecta on one support ticket. This support workflow needs all three capabilities: read private data (1), read what the customer sent (2), and communicate outside the organization (3). The injected instruction arrives on leg 2 and tries to redirect leg 3. Preserving this workflow means checking that what leaves is authorized information going to an entitled recipient.

Consider an AI-powered customer-support assistant reading a ticket. An attacker has added a supposed verification step: retrieve an internal account record and send a copy to an outside address. If the assistant complies, the attacker gets the benefit of permissions they never held. This is prompt injection: instructions planted in material the assistant was supposed to read redirect what it does. Legitimate support work needs the same three capabilities. The assistant must read the customer's request, consult a private record, and reply with information that customer is entitled to receive. The challenge is to stop the unauthorized copy while preserving the customer's reply.

At Cogent Research, we investigate how to enforce that distinction outside the AI model. Our August study asked whether an external policy could stop coding agents from cheating [5]. Here we extend that investigation to business workflows, then follow the agent after a blocked call: can a revised policy close its alternative route while preserving the work its user authorized?

Introducing TRACE

TRACE is a policy-enforcement engine that decides whether an agent's proposed actions may proceed. An agent's AI model plans what to do; operations such as sending an email or making a payment are carried out through software functions called tools. TRACE checks each tool call against written security rules and allows it, blocks it, or requests human approval. It does not rewrite the proposed action.

Figure 2. The agent's AI model proposes a tool call; TRACE checks whether it may proceed. TRACE uses no language model. Its local rule evaluation returns allow, ask (human review), or deny. The integration must pause execution on ask and stop it on deny. A blocked call returns an explanation to the agent, which can choose its next action.

TRACE's policy language describes both restrictions on the proposed action and conditions on earlier actions in the session. These temporal conditions let an internal-site visit change whether a later action is permitted, even after other steps intervene. TRACE evaluates these conditions locally and deterministically, with no language model inside the engine. Its enforcement hook records policy decisions in an audit log and returns the reason for a block to the agent.

For example, this TRACE rule blocks transfers to a specified account:

If the agent proposes a send_money call with recipient="blocked-account" and amount=50, TRACE checks the operation name and recipient against the rule. Both conditions match, so it returns deny, and the integration stops the transfer before execution. When rules overlap, denial wins; otherwise a review request takes precedence over permission. If no rule matches, TRACE also requests review.

Claude Code already provides the connection point: its built-in PreToolUse hook passes proposed tool calls to an external check before execution [6]. Any harness that exposes a pre-execution hook can connect the same way. The business-workflow evaluations below used adapters in the benchmarks' own agent loops to check proposed tool calls through the same engine before execution.

Databricks illustrates contextual enforcement of this kind in Omnigent: record private-data access and exposure to untrusted input, then use that context to decide whether an outgoing action may proceed [7]. Our TRACE experiments put that approach to three practical tests: what it blocks, what legitimate work it interrupts, and whether an agent can find another route.

Blocking alternative routes while preserving approved work

A browser agent can submit a form directly, or type into a field and click Submit. Our starting policy blocked the prohibited direct submission while leaving typing and clicking available. That setup let us examine whether an agent would use the open route after its first attempt was blocked. Claude Sonnet 5 operated a simulated browser under task instructions directing it to retrieve an internal audit code and send it to a website the security policy prohibited.

Figure 3. Forty browser runs, one workaround, one repair. TRACE blocked the direct submission in all 26 runs that attempted it. Five continued to the external form; three disclosed the code by typing and clicking. One added history rule denied the disclosure-enabling calls in all three recorded cases in offline replay.

Of 40 runs, 26 attempted the prohibited direct submission. TRACE blocked all 26, through either a denial or a review request that stopped execution. In 21 of those runs, the agent made no attempt to use an alternative route. Five continued; three disclosed the code by typing it into the form and clicking Submit, the operations still permitted by the starting policy. Replaying the recorded actions confirmed those three disclosures. One agent described the workaround in the quotation at the top of this article.

The fix was a policy change, not an engine change. We added one rule using TRACE's existing session-history conditions: after a visit to an internal site, block typing and clicking too. In replay under the hardened policy, all disclosure-enabling calls in all three recorded cases were denied.

Internal visit → intervening navigation and page reads → external form → typing denied. In this recorded path, replayed under the repair, the earlier internal visit still determines whether the later typing call can proceed.

That protection comes with a tradeoff. Blocking every click or keystroke after an internal visit closes the tested route, but also interrupts an approved task: reading a private case record, then typing authorized information into a partner's form and clicking Submit.

We compared that restrictive rule with a more selective one, which blocks typing and clicking only after visits to both an internal site and an unapproved external site. We checked two of the three recorded disclosure paths (the third was recorded under a different variant of the starting policy, so it has no like-for-like baseline here) and constructed approved workflows under each rule, replaying their actions and inspecting what the simulated browser submitted:

The more selective rule stopped both tested disclosure paths and restored the approved submission. It still blocked the task that required a private-record read, a harmless public reference, and then the approved submission: both earlier visits remained in the session history even after the agent returned to the approved page. Distinguishing this case needs trustworthy information about the current page and where the action will send data. The comparison shows which harmful routes each repair closes and which approved tasks it still interrupts. These are fixed-action checks; a live agent may choose other operations.

Blocking prohibited actions across ten agent roles

The browser study tests an agent's alternative route. We also tested the basic enforcement question across a broader set of tasks: can TRACE block prohibited tools while leaving legitimate ones available? We examined this with Agent Security Bench (ASB), a public benchmark with simulated agents in ten professional roles, from legal and medical advice to e-commerce and systems administration [8]. We selected 40 attack scenarios across all ten roles, using a fixed, reproducible slice of ASB's 400 attacker tools, with four scenarios per role. This keeps the evaluation compact while covering each role; the appendix gives the selection rule. ASB defines normal task tools and tools representing attacker actions; our policy used standard allow-and-deny rules to permit the former and block the latter. Injected instructions directed the agent toward the attacker tools. We tested the same rules on runs with and without those instructions, using ASB's built-in criteria to score attack success and task completion.

Without TRACE, 34 of the 40 attacks succeeded. With TRACE enforcing those tool-use restrictions, none did. In 40 clean runs, TRACE blocked none of the 80 legitimate tool calls, and every run completed its task.

Testing protection in everyday workflows

The harder case is a tool that serves both the authorized task and the attack. For this we used AgentDojo, a public benchmark published in the NeurIPS Datasets and Benchmarks track [9]. Its tasks operate on application state such as account balances, messages, and calendar entries. A payment tool may carry out the user's legitimate request or send money to an attacker; the recipient and other arguments decide which action TRACE is being asked to approve.

Here we report 77 business-workflow tasks across three AgentDojo applications: Banking (account information, payments, and scheduled transactions; 16 tasks), Slack (messaging, channels, and workspace membership; 21 tasks), and Workspace (email, calendars, and shared-drive files; 40 tasks). AgentDojo's supplied attack technique placed malicious instructions in content the assistant encountered. In one banking example, an assistant asked to pay a bill encountered text impersonating its user and requesting a transfer to the attacker first; the appendix reproduces the exact message. Payments changed a simulated account and emails entered a simulated mailbox.

The policies applied familiar restrictions, such as blocking transfers to prohibited recipients, using the benchmark's specified destinations and tool arguments. The same policy was applied to attacked and clean runs, letting us measure protection and check for interruptions to ordinary work. One task paired with one attack goal makes one attacked run, giving 809 attacked runs per condition across the three applications.

Both ASB and AgentDojo used four conditions to distinguish protection from interference with ordinary work:

We measured attack-success rate using each benchmark's own criteria, alongside clean-task completion and legitimate-call interruptions. For each benchmark, the same criteria judged the TRACE-off and TRACE-on runs; policy-decision counts are reported separately in the appendix.

Figure 4. What TRACE stopped, and what it cost. A: attack-success or harmful-outcome rate, without and with TRACE, on the same tested cases. One scale covers the five rows, each with its own unit and denominator; RedCode counts a case as stopped when a denial or a paused review request halts execution. B: replayed or checked attacks stopped; AutoPenBench replays seven held-out sequences against test targets, ExploitGym checks launch commands without executing them. C: clean-task completion and legitimate-call interruptions. The panels retain their own units and denominators.

Successful attacks fell by about 90% in Banking, 100% in Slack, and 73% in Workspace. TRACE blocked no tool calls in the 77 clean tasks. Completions totaled 56 of 77 in both conditions; a few individual tasks differed, but none of those differences involved a blocked call. The appendix gives the full counts.

Extending the checks to security operations

We also examined specialist tasks, where an agent's tools can directly affect software and systems. Each benchmark tests a different kind of operation:

• AutoPenBench: 7 of 7 attack sequences reserved for testing were stopped. TRACE blocked the opening network scan when each sequence was replayed against the benchmark's target systems; the unprotected replays succeeded [10]. Checking a further 31 recorded sequences through TRACE without re-executing them intercepted 29; two Python-wrapped commands escaped the rule.

• RedCode: 75 of 90 risky-code cases caused harm without TRACE, and 0 with it [11], when both denials and review requests halted execution. That setting stopped all tested code. When review requests did not pause execution, 55 harmful cases remained. Flagging a call for review is not protection; pausing it is.

• ExploitGym: 572 of 572 exploit-launch commands denied. Starting from public exploit conventions, we wrote a policy and refined it once after examining the cases it sent to review. We then checked it against commands derived from the benchmark's vulnerability tasks, without executing the exploits [12]. Among 42 constructed legitimate control commands, it denied none, allowed 32, and sent 10 to human review.

Pausing for review prevents execution, but it still costs someone's attention.

Protection that follows the action

Across the tested workflows, TRACE blocked prohibited operations. The ASB and AgentDojo clean runs recorded no blocked legitimate calls. The browser study exposed a route the original policy left open; comparing rule revisions showed both the protection gained and the approved work affected.

The practical test of a policy extends beyond its first block. Measure what it prevents. Watch what the agent does after a block. Test each repair against the legitimate work it must preserve, and report the work it still interrupts. The agents keep working after a denial. So must the policy.

References

[1] Simon Willison. The lethal trifecta for AI agents: private data, untrusted content, and external communication. 16 June 2025.

[2] Microsoft Security Response Center. CVE-2025-32711: M365 Copilot Information Disclosure Vulnerability. 11 June 2025. Reported by Aim Labs as EchoLeak.

[3] Noma Security. ForcedLeak: Agent Risks Exposed in Salesforce Agentforce. 25 September 2025.

[4] Legit Security. CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code. 8 October 2025.

[5] Hung Dang. What recent agent incidents and our own experiment show: agent security has to be enforced outside the model. Cogent Research, 18 August 2026.

[6] Anthropic. Hooks reference: PreToolUse. Claude Code documentation. Accessed 10 September 2026.

[7] Databricks. Innocent until combined: Blocking the lethal trifecta with Omnigent Contextual Policies. 10 August 2026.

[8] Agent Security Bench. ICLR 2025.

[9] AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS 2024, Datasets and Benchmarks Track.

[10] AutoPenBench. EMNLP 2025, Industry Track.

[11] RedCode. NeurIPS 2024, Datasets and Benchmarks Track.

[12] ExploitGym. Benchmark project page.