Execution Lineage: Tracing How Every AI Agent Action Happened

Your AI agents are making thousands of decisions per hour. When your CISO asks "how did that agent get access to our CRM?", can you answer in under 60 seconds?

Most platforms tell you what happened. Execution Lineage tells you how: the full chain from the human who authorized it, through every delegation hop, every policy decision, to the downstream resource that was accessed.

Today we are announcing Execution Lineage as a new capability in Watchlight AI Beacon, our Agent Runtime Governance control plane.

The Problem: The Missing Middle

Modern multi-agent frameworks orchestrate complex workflows across agents, tools, and APIs. An orchestrating agent delegates to worker agents, which invoke tools, which call external services. The workflows are powerful. The visibility is not.

You can see the first request: a user asked an agent to do something. You can see the final API call: the agent accessed a system. Everything in between is invisible.

For compliance teams, the questions are specific. Who authorized this action? What delegation chain was used? Which policy permitted it? For incident response teams, the questions are urgent. Reconstruct the three seconds between "agent started" and "data accessed." Explain every hop.

The gap is not authorization. The policy engine already evaluates every action. The gap is reconstructability across service boundaries. When an orchestrator delegates to a worker that calls a tool that invokes an API, the governance decisions at each hop exist in isolation. They are not connected into a coherent chain that can be queried, visualized, and presented as evidence.

Execution Lineage closes that gap.

What Execution Lineage Is

Execution Lineage is a tree-structured audit model where every AI agent action is a node in a directed graph.

Parent-child edges represent delegation: a planner delegates to a worker, which invokes a tool. Each node carries its execution identity, agent identity, declared intent, policy decision, and timestamp. The lineage is propagated across service boundaries via lightweight HTTP headers and persisted for forensic queries.

Here is what a lineage tree looks like:

Each box in this chain is a node. Each arrow is an edge. Each policy check is a decision link. The entire tree is reconstructable from a single execution ID.

Three Layers of Lineage

Execution Lineage operates across three layers, each building on the one below.

Layer 1: Propagation

A canonical execution ID is minted at the entry point, either at the governance proxy or through the agent SDK. When an agent delegates to a sub-agent, the child execution references its parent, forming a tree. HTTP headers carry lineage context across service boundaries.

The design is intentionally tolerant. Services that do not understand lineage headers ignore them. The system degrades gracefully. No service needs to be modified to participate; lineage flows through the infrastructure without requiring changes to existing agent code.

Security is built into the propagation layer. Response-only fields are never trusted from inbound requests. Anti-spoofing controls prevent agents from forging their position in the lineage chain. The proxy is authoritative.

Layer 2: Policy-Aware Context

Lineage attributes are available to the policy engine during evaluation. This means policies can reference the delegation chain itself, not just the immediate agent making the request.

This unlocks a class of governance rules that are impossible without lineage:

• "Block database access unless the delegation chain includes an administrator"
• "Require human approval for chains deeper than three levels"
• "Deny if the declared intent does not match the goal's allowed categories"

These are not hypothetical examples. They represent real governance requirements from organizations deploying multi-agent workflows where delegation depth, chain validity, and intent consistency are critical controls.

Layer 3: Persistent Graph

Executions are stored as a tree with parent-child self-references. Audit decisions are enriched with the execution ID, policy IDs, and the full delegation chain at the time of the decision. Recursive queries reconstruct the complete tree from any node.

Ask for any execution ID and the system returns the full lineage: who initiated it, every agent that participated, every policy decision that was made, every resource that was accessed. One query. Complete reconstructability.

How It Works: Sequence Flows

Single Agent Accessing a Protected API

Every step is captured. The execution ID correlates the proxy audit event, the policy decision, and the credential use into a single reconstructable record.

Delegation Chain with Downstream Access

When an orchestrator delegates to a worker, the lineage extends:

Each node in this tree is a separate execution with its own identity, authority grant, and policy evaluation. The lineage connects them into a coherent chain.

Suspicious Chain with Denial and Anomaly Detection

This is Principle 3 in action: authority narrows at each delegation hop. The parent's authority does not automatically transfer to the child. The lineage makes this visible and auditable.

Anomaly Detection

The lineage graph automatically flags suspicious patterns in real time:

Pattern	What It Means	Severity
Broken chain	Parent execution referenced but not found	Warning: data gap or race condition
Denied after allowed parent	Sub-agent denied when parent was allowed	Info: defense-in-depth working, or misconfigured delegation
Deep delegation	Chain depth exceeds threshold	Warning: review whether deep nesting is intentional
Multiple sibling delegations	Unusual fan-out from single parent	Warning: possible runaway orchestrator
Orphan execution	Execution with no associated decisions	Info: execution created but never evaluated

These anomalies surface in dashboards and API responses, giving security teams real-time visibility into governance patterns across the agent fleet.

Three Questions It Answers

For CISOs: "Who authorized that AI agent to access our CRM?"

The lineage chain shows the full path: Sarah Chen (analyst, authenticated via Okta SSO) delegated to the orchestrator, which sub-delegated a CRM query to the senior-researcher agent. The policy engine permitted the action under a DataAnalysis intent within the Q4 Research goal, evaluated against the research-access policy. Every hop is audited. The full chain is reconstructable from a single execution ID.

For Compliance: "Can we prove this action was authorized?"

Yes. The execution record links to the delegation grant (who delegated, what scope, when it expires), the Cedar policy evaluation (which policies were checked, which one decided, the full evaluation context), the intent declaration (why the agent claimed it needed access), and the goal (under what business objective the action was taken). All persisted. All queryable. All immutable.

For Auditors: "Can we trust the record has not been altered?"

Yes. Every lineage record is cryptographically signed. Once written, a record cannot be altered or backdated without breaking its signature, and the signed chain is verifiable across trust boundaries. Append-only persistence guarantees the record exists; the signature guarantees it is the original. That is the difference between an audit log you have to trust and audit evidence a third party can verify, including a regulator, an incident responder, or a downstream system that did not generate the record.

For Platform Teams: "How do I add lineage to my agents?"

Start with zero changes. The governance proxy auto-generates execution IDs for every request that passes through it. For delegation tracking, add one header (X-Wl-Parent-Execution-Id) to sub-agent calls. For intent tracking, add one more (X-Wl-Intent). All headers are optional. All are additive. All are backward compatible. Existing agents work without modification from day one.

Design Principles

Five principles guide the design of Execution Lineage:

1. Append-only. Lineage records are immutable once written. No updates, only appends. This guarantees audit integrity.

2. Correlation over coupling. Each service writes its own events with shared execution IDs. There is no centralized bottleneck. Services remain independently deployable.

3. Backward compatible. All lineage headers are optional. Existing agents and tools work without modification. Lineage is additive.

4. Security-first. Strict validation on all inputs. Control characters are rejected. Server-authoritative fields are never trusted from client requests. Response-only headers are stripped from inbound traffic.

5. Framework agnostic. Execution Lineage works with any agent framework. It tracks executions across service boundaries, not framework internals. LangChain, CrewAI, AutoGen, custom orchestrators: lineage flows through all of them.

What Is Next

Execution Lineage is available now to Founding Design Partners. Upcoming capabilities on the roadmap include:

• Credential provenance: Track which secret was used, from which backend, under whose authority
• Graph visualization: Interactive execution trees in the governance dashboard
• MCP server instrumentation: Track downstream calls from MCP tool servers through the lineage graph
• OpenTelemetry bridge: Connect execution lineage to existing distributed tracing infrastructure

Every Action Should Be Explainable

Every AI agent action should be explainable. Not just "what happened" but "how it happened": the full chain from the human who authorized it to the downstream resource that was accessed.

That is the difference between "the AI accessed your CRM" and "Sarah delegated to the orchestrator, which delegated to the researcher under a DataAnalysis intent, authorized by the research-access policy within the Q4 Research goal, and the query completed in 45ms."

The first answer raises more questions. The second answer closes the investigation.

That is what Execution Lineage delivers.

---

Execution Lineage is part of Watchlight AI Beacon, the enterprise control plane for Agent Runtime Governance. Interested in early access? Join the Founding Design Partner Program.