Tool Call Provenance Drift: Definition and Detection

Four Components of Tool Call Provenance

Each tool call carries four attributes that, together, define whether it matches its authorized baseline.

Originating Identity

The authenticated agent, user, or service that initiated the call.

Permission Scope

The authorized set of actions granted at the time of invocation.

Tool Source

The verified origin of the tool, plugin, or MCP server being invoked.

Invocation Chain

The ordered sequence of calls that led to the current tool execution.

Defining Tool Call Provenance Drift

In an agentic AI workflow, a tool call is more than an API request. It carries metadata describing who or what initiated it, what permissions were in effect at that moment, where the tool itself originated, and the chain of prior calls that led to it. Tool call provenance drift is the condition where one or more of these attributes silently diverges from the baseline established when the tool integration was authorized. This is distinct from a failed call or an access-denied event: drift is subtle. The call succeeds, the output looks normal, but the identity, scope, source, or chain behind it no longer matches what was expected. Because standard application logs typically record that a call happened rather than the full provenance context around it, drift can persist across many executions before it surfaces in an audit or incident review. No primary standards body currently defines this term formally; the concept is a synthesis of established ideas: provenance modeling from the W3C PROV Data Model, continuous verification from NIST Zero Trust guidance, and audit traceability requirements from NIST SP 800-53. Enterprises adopting agentic AI need an internal, working definition of drift that maps to these components so detection criteria are consistent.

How Provenance Is Established in Agent Tool Calls

The Model Context Protocol defines a client-server architecture in which an AI application, acting as host, mediates connections between a model and the servers that expose tools, resources, and prompts. This mediation model is intended to make each tool call traceable to a defined source, since the host is responsible for authorizing access rather than allowing the model to invoke tools directly. This design reduces drift risk but does not eliminate it: approval in MCP-style architectures typically occurs at connection or session setup, not at every downstream call within a multi-step chain. A tool call three steps into a chain may inherit context from an earlier authorization event rather than being independently verified. The W3C PROV Data Model offers a useful conceptual structure here: it separates attribution (linking an action to a responsible agent), derivation (how one entity was produced from another), and generation. Applied to tool calls, this separation clarifies that verifying who authorized a call, what it was derived from, and how it was generated are three distinct checks, not one. A provenance baseline should capture all three at the time of each call, not only at the start of a session.

Detecting Drift at Runtime Rather Than After the Fact

NIST SP 800-207 Zero Trust guidance calls for continuous verification of identity, device, and authorization for each access request, rather than a single upstream trust decision applied to an entire session. Applied to agent tool calls, this means identity and permission scope should be re-checked at each step of a chain, not assumed to carry forward from initial approval. Standard audit logging, as described in the NIST SP 800-53 Audit and Accountability control family, is designed to trace actions back to a system entity, but general application logs often lack the specific fields needed to detect provenance drift: source identity at time of call, permission scope at time of call, and position within the invocation chain. Detecting drift as it happens requires structured, queryable metadata for each of these fields, correlated across the full chain, rather than unstructured text logs reviewed only after an incident. Existing SIEM and logging pipelines should be evaluated for whether they can ingest and correlate this tool-call-specific metadata separately from general application events.

Governance and Operational Considerations

The NIST AI Risk Management Framework treats traceability and accountability as core trustworthiness characteristics, which places provenance controls within formal AI risk management rather than treating them as a purely technical logging exercise. OWASP's Excessive Agency category is directly relevant here: agents granted more autonomy or permission than a task requires create more opportunity for drift to result in meaningful privilege escalation. Governance review of what permissions and autonomy each agent role actually needs is a preventive control, applied before runtime detection is ever needed. Where audit-and-accountability requirements apply, retention and review processes for tool-call provenance data should be defined explicitly, since collection alone does not satisfy typical regulatory expectations. Trussed AI's runtime governance approach addresses this operational layer directly, applying agent identity binding, tool approval workflows, and structured audit logging to agent tool calls so that permission scope and source verification can be checked continuously rather than only at deployment or during post-incident review.

Signals That Indicate Provenance Drift

The following conditions typically indicate that a tool call's recorded provenance no longer matches its authorized baseline.

Identity mismatch: the credential or identity attached to a call no longer matches the originating agent or user.
Permission escalation: a call executes with broader scope than was granted for that step in the chain.
Unverified tool source: a tool or plugin is invoked without confirmation that it matches its registered, expected origin.
Altered invocation chain: the sequence of calls leading to execution differs from the documented or expected path.
Stale authorization reuse: later calls in a chain rely on an approval issued for an earlier, narrower context.

Controls That Prevent or Contain Drift

These controls address provenance drift at the point of invocation, rather than relying solely on session-level trust or post-incident review.

Per-Call Identity Binding

Bind each tool call to a verified agent or service identity rather than relying on session-level trust for the entire chain.

Least Privilege at Call Level

Enforce least privilege at the individual tool-call level, distinct from the agent's overall assigned permission set, to limit the impact of a drifted call.

Tool Source Verification

Verify tool source integrity before invocation where cryptographic signing or attestation of the tool origin is available.

Structured Audit Fields

Capture identity, permission scope, and chain position as structured audit fields at every step, not only at session initiation.

Explicit Alerting Thresholds

Define explicit alerting thresholds for permission-scope mismatches or unexpected chain changes, consistent with Zero Trust and audit-control guidance.

Internal Baseline Documentation

Document an internal baseline for each tool integration point, since no standardized external definition of provenance drift currently exists.

Frequently Asked Questions

Common questions about how tool call provenance drift relates to adjacent security concepts and how it should be reviewed over time.

Is tool call provenance drift the same as a supply chain attack?

No. A supply chain attack introduces malicious code or a compromised dependency. Provenance drift is a divergence in recorded identity, scope, source, or chain metadata for a tool call, which may or may not involve a malicious component, but which traditional logging and access controls typically fail to surface.

Does using MCP alone prevent provenance drift?

MCP's host-mediated approval model reduces drift risk by requiring explicit authorization for tool and resource access, but approval typically occurs at session setup rather than being re-verified at every downstream call in a multi-step chain, so drift risk is reduced, not eliminated.

How often should a provenance baseline be reviewed?

There is no standardized interval defined in current guidance. Enterprises should align review frequency with existing audit-and-accountability schedules and re-verify baselines whenever a tool integration, permission model, or agent role changes.

Tool Call Provenance Drift