Output Filtering Gaps in Multi-Step Agent Tool Chains

Individually permitted outputs can combine into data leakage, privilege escalation, or policy violations that no single-tool filter sees. Closing that gap requires enforcement across the session, with policies that compose, sensitivity constraints that persist, and provenance checks on the arguments that exercise authority.

Why per-tool output filters cannot see the violations that emerge across a full agent tool chain

A per-tool output filter evaluates an invocation. The missing information is the relationship between what an earlier tool exposed and what a later tool is permitted to do with that exposure.

Schneider et al.’s 2026 Dynamic Security Control Compositor paper opens with a file-reading tool and an HTTP client that each pass their individual security checks. Composed together, they let an agent read an internal document and POST its contents to an external server. Neither tool is prohibited on its own. The violation arises when the document becomes the client’s payload, a relationship neither isolated evaluation establishes.

Autonomous agents make this limitation more consequential because they plan, select tools, and execute tasks without human intervention at each step. Earlier assistants gave a person a single output to review. An agent creates a sequence whose safety depends on what it did earlier and the data it came across. If a violation exists only as a property of that sequence, detection must operate at the chain level.

How individually benign outputs compose into data leakage, privilege escalation, and policy violations

Data exfiltration takes advantage of sensitivity constraints that are lost between calls. The DSCC paper formalizes this as a monotonic taint state problem. A high-sensitivity tool’s output must constrain subsequent invocations, even when a later call looks routine in isolation. Without that state, a low-sensitivity-looking operation can transmit protected data because its filter does not know what the session previously encountered.

The same loss of context can break policy even when nothing is sent outside the organization. The paper’s second example combines a database-query tool handling Confidential data with a planning tool classified as Internal. Both tools follow their own rules. Their composition nevertheless places Confidential data under weaker access controls, creating a classification-level violation that a filter looking only for external disclosure would miss.

Sequential attacks exploit a related mismatch between local scores and cumulative effects. Li et al.’s Sequential Tool Attack Chaining constructs multi-turn sequences in which each prompt falls below a harmfulness threshold, while the sequence achieves a high attack success rate across multiple LLM families. Wu et al.’s 2026 ChainFuzzer reinforces that distinction, finding that the strong majority of confirmed vulnerabilities in its tested open-source agent applications required multi-tool execution.

Causality laundering goes further by avoiding direct data transfer from the protected source. An attacker uses a denied access outcome as an oracle, infers protected information from the denial, and sends that inference through a later, apparently benign call. The denial itself becomes an information source. Flat output filtering misses this because the leaked information comes from causal influence.

Why audit trails and existing enterprise controls compound the gap rather than compensate for it

Conventional enterprise controls do not automatically recover the context that output filters discard. SIEM, data loss prevention systems, and behavioral analytics were built around human users and deterministic workflows. They can capture terminal API calls without capturing the autonomous decision chain that produced them. A violation may therefore leave records of its actions but no conventional audit trace explaining how those actions composed into a breach.

A single task can involve many tools, subordinate agents, a vector database, and a production API. Intermediate reasoning states remain inside the model and are inaccessible to conventional logging. Identity gaps make attribution harder still. The Cloud Security Alliance’s 2026 AI Agent Governance Gap analysis reports that a large majority of surveyed enterprise CISOs and CIOs lack full visibility into agent identities, while an even higher proportion doubt their ability to detect or contain a compromised agent [1][2][3][4][5][6].

Delegation and memory also stretch the causal chain beyond one transaction. Aembit’s 2026 agentic risk guide lists cascading multi-agent compromise and persistent memory poisoning among the risks that traditional application security was not built to handle. Trusted delegation can make a breach appear as individually authorized calls. Poisoned memory can shape decisions over days or weeks, with no single log entry to explain how the later violation happened.

What real incidents show about how compositional gaps are exploited in deployed systems

EchoLeak, CVE-2025-32711, exposed the read-to-send boundary in Microsoft 365 Copilot. A crafted email delivered a zero-click prompt injection that induced access to internal files and transmission of their contents to an attacker-controlled server without user interaction. The email access, file read, and HTTP send each passed their own checks. The failure was in their composition, as content encountered through email redirected later file access and outbound transmission.

GitHub Copilot’s CVE-2025-53773 crossed from repository context into configuration authority and then code execution. An indirect prompt injection in a repository file directed Copilot to modify .vscode/settings.json to enable auto-approval, or “YOLO mode.” That change allowed arbitrary shell commands with the developer’s full system permissions without user confirmation. A file-read filter alone could not establish whether retrieved context would later disable approval, while an execution-side check without provenance would lack the connection to the original injected instruction.

Adnan Khan and Snyk disclosed Clinejection in February 2026. A malicious GitHub issue title used an AI coding agent’s tool chain to break into developer machines. The boundary ran from content ingestion to code execution or installation. Neither tool’s filter evaluated the trust relationship between the ingested title and the later operation.

Research shows that the entry point need not even be a tool result. Li et al.’s 2026 MCP-ITP framework poisons Model Context Protocol tool descriptions to get agents to misuse legitimate high-privilege tools without instructions that look clearly malicious. The poisoned tool need not be invoked directly. Output filtering on tool results misses this manipulation because it has already happened through the metadata used to choose another tool.

Why prompt injection is the primary mechanism that drives inputs across tool boundaries and into chain-level violations

Prompt injection lets an attacker direct a sequence of tools that are available to the agent. Untrusted content returned by one tool becomes a directing instruction for the next invocation. The key transition is from data to authority. A retrieved document, issue title, or tool description does not need permission to execute an action itself if it can persuade the agent to exercise that permission elsewhere.

The architectural weakness is that LLMs process text within a shared context without a built-in mechanism that reliably separates privileged instructions from untrusted data. This creates two related but distinct attack surfaces. An attack on the agent changes its behavior, while an attack through the agent uses it to reach downstream databases, APIs, or infrastructure. Per-tool output filters focus on local behavior and largely miss that downstream use of authority.

Invocation-level trust decisions make the defense brittle as well. Allowing external content to influence a call can permit it to hijack a destination or another authority-bearing argument. Quarantining the entire call can instead break legitimate retrieval-then-act workflows. The required distinction is finer than a tool call, because some arguments may legitimately depend on retrieved content while others must remain bound to trusted intent.

How current security standards and governance frameworks fail to specify chain-level output filtering requirements

No current enforceable governance framework in the supplied analysis specifies agent-specific chain-level output filtering controls. Frameworks built around behavior that can be characterized at deployment do not directly specify enforcement for agents that choose multi-step actions across changing environments. Compliance therefore does not establish that a composed tool chain is safe.

NIST AI RMF 1.0, published in January 2023, gives teams terms for risk management but assumes that people can review agents under conditions that autonomous tool-calling agents routinely go beyond. ISO/IEC 42001:2023 offers an AI management system that can be certified, but it does not enforce rules in real time for multi-step agent tasks. NIST IR 8596’s December 2025 initial public draft also leaves out the specific needs of autonomous agents that work across distributed tool ecosystems.

The EU AI Act began enforcing general-purpose AI obligations in August 2025 but contains no definition of “agentic systems.” Its conformity assessment, risk management, and oversight provisions assume behavior that is known, documentable, and stable at deployment. Agent-specific standards work is still developing. NIST’s CAISI issued its autonomous-agent cybersecurity RFI on January 8, 2026, and the AI Agent Standards Initiative announced February 17, 2026 is a multi-year effort, with first substantive deliverables not expected before late 2026 at the earliest.

Near-term resources include the OWASP Agentic Top 10, OWASP Agentic Skills Top 10, NCCoE’s AI agent identity concept paper, and CSA’s AI Controls Matrix. These offer guidance. Teams must set their own output filtering requirements while they wait for external standards to catch up.

What chain-level enforcement actually requires at checkout, runtime, and the argument boundary

The DSCC architecture provides the organizing frame for enforcement before and during execution. At session checkout, its Most Restrictive Set algorithm composes per-tool policies into one effective policy for the chain. Extending the chain can only tighten that policy. This monotonicity invariant blocks incompatible tool combinations before execution rather than waiting for an isolated output to look unsafe.

Tool outputs propagate classification constraints into a session-level taint state, and subsequent invocations must satisfy the most restrictive constraints seen so far. Sensitivity cannot disappear between otherwise legitimate calls. DSCC revokes the session when the data it has seen would make a later invocation break policy, covering risks that checks on tool compatibility alone cannot predict.

The paper evaluated its approach on 32 tools governed by 16 NIST SP 800-53 aligned policies. In clearance mode, static composition blocked a large majority of policy-violating pairs and an even higher proportion of violating triples. The two phases address different sources of risk, namely incompatible capabilities and constraints introduced by encountered data.

Argument-level provenance supplies the finer-grained boundary that invocation-level decisions lack. Provenance-Aware Capability Contracts assigns semantic roles to tool arguments, tracks their origins across replanning, and checks those origins against role-specific trust contracts. Its question is which input determined an authority-bearing argument. Under oracle provenance conditions, PACT achieves full utility and full security on mixed-trust diagnostic suites where flat invocation-level monitors produce false positives or false negatives.

ToolFence’s September 2026 arXiv v1 extends this approach by compiling the user’s request into a typed capability blueprint before reading untrusted data. It tracks argument provenance and enforces the blueprint through a deterministic, non-LLM mechanism. Authorization can preserve restrictions across delegation too. The March 2026 Attenuating Authorization Tokens IETF draft specifies signed, token-encoded credentials with tool-level argument constraints that holders can tighten but never broaden, providing a protocol mechanism for chain-level policy.

What practitioners must verify before shipping a multi-step agent to production

Teams that ship multi-step agents need their own release gate because practices for testing and deployment are still less established than those for other lifecycle stages. The first verification target is the trajectory. A correct-looking response can follow an unauthorized chain. Release evidence should show whether the tool calls and the path between them followed the session’s policy.

Prompt injection red teaming must test whether content in one tool’s output can redirect a subsequent invocation. Testing tools separately cannot answer that question. The composed chain is the test subject, including the trust boundary between retrieved data and authority-bearing arguments. MCP Security Bench, accepted at ICLR 2026, benchmarks attacks against the Model Context Protocol and is relevant to deployments using MCP-style tool routing.

Every safeguard also needs verified workflow replay. Approved workflows must be rerun after a security change to establish that they still pass, because stopping an attack by breaking a legitimate chain is not an acceptable control. Findings need signed evidence that has been reproduced in an isolated environment. Each approved change should leave a reproducible record that a release approver can inspect, replacing unresolved opinion-based risk debates with evidence.

Human approval remains the gate for every production change. The reviewer must be able to inspect the minimal safeguard, confirm that it stops the proven attack, and confirm that approved workflows still pass.