Tool-Chain Analysis

Security Objective

Tool-chain analysis reconstructs the ordered chain of proposed and observed tool actions from application-recorded telemetry and lineage, then evaluates the chain's cumulative, composed effect against task-level constraints and invariants. It exists because individually plausible, and even individually authorized, calls do not imply that the combined chain is safe.

A read of an internal record, a local summary and a notification are each unremarkable. In sequence they can form a path that moves internal data to a destination the task never contained. Two reservations that each respect a per-call limit can together exceed the task's total. A retry after a lost acknowledgement can duplicate an effect that already happened.

Ownership Boundaries

The broad Prompt Injection Detection article places sequence signals inside a larger correlation architecture. This page goes deeper into that one layer.

Threat Model

The concern is that influenced model behavior, whether from direct input, retrieved content, tool output or a sub-agent result, steers the agent into a sequence whose combined effect the task never asked for. Each step may look like normal work. The harm, if any, lies in the composition.

Out of scope: proving intent, judging whether content is malicious and deciding whether a single call may run. Those belong to triage, inspection and authorization respectively.

What Is a Tool Chain?

On this page a tool chain is the ordered, possibly branching set of tool calls that belong to one task, including calls made by delegated sub-agents, together with the data and resource lineage that connects them. It includes proposed calls, calls that were authorized, submitted or executed, and their recorded results.

Why Per-Call Review Is Not Enough

Per-call review asks whether one resolved request is allowed and well formed. It does not see what an earlier call read, what a later call will send, how many units have already been reserved or whether an identical effect is pending. Those facts only exist across calls.

Tool availability is not permission, and it says nothing about what a chain does end to end.

Authoritative Chain Evidence

The authoritative chain comes from application-side records: task and run IDs, ordered call IDs, tool and operation, concrete resolved parameters, resource classes, destinations, data lineage, counters, idempotency keys, delegation records and execution states.

Trust Model

Task constraints, telemetry, the analyzer and the response policy are system components. The proposed chain is variable content. A sub-agent's returned result is also variable content; its lineage and delegation record are application facts.

Chain Reconstruction

Reconstruct order explicitly. Where calls run concurrently, timestamps alone do not establish order or dependency. Record sequence numbers within a run and parent call IDs, so the chain is a directed graph of dependencies rather than a list sorted by clock time.

Represent branches and concurrent calls as branches. Pretending every agent run is linear hides the case where two parallel reads feed one later send.

Chain Identity, Task and Correlation

These fields are engineering guidance. Correlation IDs must propagate across every hop, or the chain breaks into fragments that each look harmless.

Execution-State Model

Proposed vs Observed Chains

Analyze proposed chains before execution to enable restriction or pause. Analyze observed chains to support reconciliation and investigation. Keep them separate in telemetry: a proposed chain finding says what would happen if every step ran, an observed chain finding says what the records show happened.

Mark each fact as observed or inferred. An analyzer's inference that a call "probably succeeded" is not an observation.

Cumulative Effects and Task-Level Invariants

Task-level constraints are separate from per-call technical limits. A tool may accept up to 40 units per call while the task allows 50 in total. Record cumulative invariants with the task, such as total units, number of state changes, allowed destination classes or read-only and draft-only scope, and evaluate every proposed step against the running total.

Read-Then-Send and Data-Flow Composition

Sequence-level lineage connects a read to everything derived from it. When derived content reaches an outbound sink, the chain contains an end-to-end data path that isolated call review cannot see. The analyzer can flag the path with a reason such as LINEAGE_TO_EXTERNAL_SINK. Whether that flow is allowed stays an information flow control decision.

Split Operations and Aggregate Limits

Splitting one large effect into several small calls keeps each call within limits while the total exceeds the task cap. Keep application-side counters per task and per invariant, update them from recorded execution states, and include proposed calls when evaluating a proposed chain. A split may be innocent; the finding is CUMULATIVE_LIMIT_EXCEEDED, not an accusation.

Retries, Idempotency and Unobserved Results

When a state-changing call was submitted and its acknowledgement was lost, the result is unobserved. A second call with a new idempotency key can duplicate the effect. The engineering pattern is reconciliation: read the target state, or reuse the original idempotency contract as application policy defines, before any retry.

Resource and Destination Lineage

Carry resource class and destination class through the chain. A new destination class, a new resource class or a new state-changing effect class that the task constraints do not contain is a strong chain signal, reported as NEW_DESTINATION or a comparable reason code. Destination identity must come from resolved parameters, not from how the model named it. Whether a new destination is reachable at all is decided separately by network and egress restrictions.

Cross-Agent and Multi-Agent Chains

A delegated sub-agent's calls belong to the parent task's chain. Propagate correlation IDs, record each hop's delegation scope and keep every delegation a bounded subset of the parent's.

See Multi-Agent Prompt Injection for how influence travels across hops.

Effective Permission Graph and Composed Capability

As an engineering model, not a standard term, an effective permission graph connects principals, agents, delegations, tools, resources and destinations. Composed capability is the set of end-to-end effects reachable by combining edges within one task. Analyzing it shows where narrow grants combine into broad effects, and informs both chain rules and least privilege design.

Relationship to Plan Drift Detection

Plan drift detection and tool-chain analysis are complementary signal families.

Relationship to Per-Call Authorization

Per-call authorization is independent. A call can be individually permitted while the sequence still creates an unsafe combined effect. Conversely, a chain classified as within constraints does not pre-authorize any call. Each call still goes through agent authorization.

Relationship to Information Flow Control

Information flow control owns whether data from a source may reach a destination. Tool-chain analysis may identify a read-then-send path; IFC makes the separate, deterministic flow decision using labels and policy. A chain classified as within constraints never declassifies data.

Analyzer Families

Model-Assisted Chain Analysis

A model-assisted analyzer is probabilistic. Isolate it from unnecessary untrusted context, give it no tools, require schema-bound findings with reason codes, and version it.

Response Policy

Avoid a blended trust score. Keep chain finding, provenance, authorization, flow decisions, classification and execution evidence as separate fields.

Telemetry Design

When required fields are missing, report CHAIN_INCOMPLETE. Missing evidence is never evidence that the chain is within constraints.

Alert Quality and Triage

Alerts should show the ordered chain, the constraint it crosses, the reason code, execution states and lineage in one view. Triage decides whether a finding reflects influence, a missing task constraint, a legitimate workflow the constraints did not model or an analyzer error. Feed outcomes back into constraints and the regression set.

Worked Scenario A: Bounded Internal Report Chain

Task t-17: the user ops-user-dana asks for an internal restock report for SKU-17. Recorded chain: c1 read_stock(SKU-17), c2 read_threshold(SKU-17), c3 local compute, c4 draft_report to ops-user-dana. Constraints: read-only and draft-only, no external destination. All four steps are proposed.

Classification: within chain constraints. This is a sequence-level classification only. It grants no authorization and no standing or future authority; each call is still authorized separately.

Worked Scenario B: Read Then External Send

Task t-310: support-user-ana asks for a summary of synthetic case K-310. Recorded chain: c1 read_case(K-310), c2 summarize locally, c3 notify(to=reviewer@outside.example.test). Constraints: answer in chat to the initiating user, no outbound step. c1 to c3 are proposed.

Finding: chain risk with LINEAGE_TO_EXTERNAL_SINK and NEW_DESTINATION. The end-to-end path would move internal case data to an external destination the task does not contain. Because all steps are only proposed, no exfiltration or execution is claimed. IFC and per-call authorization still decide separately.

Worked Scenario C: Split Reservation and Retry After Unobserved Result

Task t-50 caps reservations of SKU-17 at 50 units in total; the tool accepts up to 40 per call. The proposed chain is c1 reserve 30 and c2 reserve 30. Each call is under the per-call maximum, but the chain total is 60. Finding: CUMULATIVE_LIMIT_EXCEEDED. Neither call executed, so no reservation is claimed, and the split is not proof of malice.

Task t-44 requires exactly one synthetic ticket for SIM-44. c1 create_ticket with key sim44-1 was authorized and submitted, and its acknowledgement was lost, so c1 is unobserved, not failed. The proposed c2 uses a new key sim44-2. Finding: DUPLICATE_EFFECT_RISK. Reconcile by reading ticket state or reusing the sim44-1 contract per application policy. No duplicate ticket is claimed.

A cross-agent variant: two read-only sub-agents with strict subset delegations and preserved lineage feed a parent that drafts an internal recommendation. With no permission union and no outbound step, the chain can remain within constraints.

What the Scenarios Prove and Do Not Prove

The same scenarios can be practised in the Tool-Chain Analysis lab, which is a deterministic simulation.

Testing and Validation

Maintain a labelled regression set that contains benign multi-step chains, risky composition chains, concurrent branches, retries after unobserved results and multi-agent hops. Test that missing fields produce CHAIN_INCOMPLETE, that unobserved is never read as failed and that responses only narrow authority. Benchmarks such as AgentDojo and InjecAgent evaluate agent behavior under injected tool content and can inform scenarios; they do not define this control.

Metrics

These are operational measures, not proof of security. Do not combine them into one score.

Common Mistakes

Implementation Checklist

Standards and Sources

Source scope: Microsoft's guidance lists tool chain analysis as a technique to assess and block risky sequences of tool execution, alongside plan drift detection, information flow control and least privilege; it does not specify an algorithm. The OWASP Top 10 for Agentic Applications 2026 provides risk context for tool misuse and identity or privilege abuse; it does not define tool-chain analysis. OWASP LLM01:2026 provides prompt injection risk context. NIST AI 100-2e2025 is used only for terminology. CaMeL is related design research on separating control and data flow. Chain schemas, reason codes, counters, idempotency handling and graph reconstruction on this page are engineering guidance, not requirements from these sources.

Frequently Asked Questions