ExecWeave: Cross-Layer Execution Provenance for Observable Agentic Software

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia.

Elias: And I'm Elias, here with Priya.

Nadia: Today's paper: "ExecWeave: Cross-Layer Execution Provenance for Observable Agentic Software".

Elias: The gist The EXECWEAVE system presents a local-first approach to materializing provider semantics and independently observed runtime events into a typed execution graph,

Nadia: First, who's behind it and why it matters.

Title and authors: Nadia: The title itself, ExecWeave: Cross-Layer Execution Provenance for Observable Agentic Software, tells you that the core problem they're solving is making sure we can trace execution across different layers when you have these agents running. It’s about building a consistent view of how an agent interacts with its environment.

Elias: It really gets to the heart of the issue: agents use tools, they spawn processes, they talk to services, and the operating system logs all that machine activity without necessarily telling us which specific agent action caused it. ExecWeave aims to relate those two planes of evidence—the logical operations described by the agent and the raw machine activity from the OS—in a way that doesn't lead you astray.

Priya: From my side, I'm interested in how they handle that relationship because when we look at data, we have to trust where it came from. If you can’t distinguish between what the agent *said* and what the OS *did*, then any conclusion you draw about the agent’s behavior is shaky.

Nadia: Right, so they're not trying to create one single truth; they want to preserve that distinction between evidence sources, even when they put it all into one graph structure. They keep separate artifacts and record metadata like attribution and causal status for every piece of information.

Elias: That's the key design objective there: evidence separation. They want direct runtime observations, provider-supplied semantics, exact shared identities, and heuristic correlations to remain distinguishable even after everything gets materialized into the graph structure fifteen, sixteen, seventeen, eighteen <ref:2610.21146#pg2>.

Priya: And that means if you're looking at a result derived from this graph, you can see exactly which evidence plane contributed what, not just a final label. That seems like a necessary step before we can even start trusting the output.

Nadia: The paper also focuses on how they handle things that are ambiguous. They have an objective about conservative attribution, meaning if multiple runtime entities look like they could have caused a semantic action, the system should keep that ambiguity instead of picking one candidate just because it’s visually closest.

Elias: That’s a practical constraint for any system dealing with uncertainty; you don't want to make an assumption when the evidence isn't strong enough to back it up. It’s about preserving the full picture of what happened, even if it means not giving you a single definitive answer immediately.

Priya: So, they are prioritizing faithful derivation histories over getting a clean, simple answer right away. That aligns with how we have to approach measurement; we want the raw data showing us the noise and ambiguity before we try to smooth it out.

Nadia: Exactly. And they also set up explicit fidelity limits so they don't just turn every limitation into negative evidence in their graph construction process. They treat things like unsupported provider internals or non-causal filesystem observations as limitations rather than simply ignoring them by converting them into something you can’t use.

Elias: That bounding of the evidence is important because it defines the scope of what the system can reliably claim about an observation, which is a necessary guardrail when building these kinds of complex systems for agents.

Priya: It sounds like they are trying to build a measurement framework where uncertainty isn't just noise; it’s a feature you can query and understand in context. That feels like something we need when dealing with agentic workflows.

The paper's summary: Nadia: Moving on to the actual mechanism, ExecWeave takes observations, which they define as e = (id, s, t, tau, r, a, kappa), and materializes them into a graph G k = M(E one:k) = (V k, A k) <ref:2610.21146#pg1>. This means they are taking those raw observations and turning them into a typed graph where V k are the various entity classes like Vagent, Vtool call, or Vf ile.

Elias: What’s interesting here is that repeated observations of the same directed tuple—like an agent calling a tool with a specific relation—contribute to one single edge in the materialized graph. This handles redundancy in observation without creating spurious connections every single time you see it happen.

Priya: That sounds efficient, but I wonder if collapsing repeated events into one edge loses some fine-grained detail about the frequency or timing of those interactions, which can be important for understanding system dynamics over time.

Nadia: The paper addresses that by keeping separate source artifacts and recording metadata like attribution and inference status. This means you can look at the graph and see not just that a connection exists, but *why* it exists—was it direct evidence, or was it an inferred bridge?

Elias: And they have this optional correlator for command-to-process attribution. It's designed to handle those tricky cases where you want to link a specific command execution to the correct process, and they do this by formulating a partial mapping phi: S to R.

Priya: That mapping sounds like it has a very strict decision rule, which I’m curious about. If the observed candidate set is only one item, they emit a bridge that they explicitly mark as inferred and non-causal. That’s a big statement about how much they trust their attribution in those specific scenarios.

Nadia: So it says that uniqueness inside the observed set isn't proof of causality or even identity at the file or socket level; it’s just a heuristic link they are making under strict conditions, which is something I think needs careful scrutiny when we talk about security.

Elias: It also explicitly states that multiple compatible observed candidates produce no bridge rather than picking one based on a score, which reinforces the idea that they are avoiding selection based on visual proximity or some kind of weighting. They're sticking to what's truly observed.

Priya: So the system is designed to show you not just what happened, but the uncertainty around *how* we know it happened across different evidence sources. That level of explicit uncertainty handling is something we need in any complex measurement tool.

The paper's improvements: Nadia: The paper outlines five main design objectives that guide how they built this system, and those goals are pretty telling about their philosophy on observability. Objective one is evidence separation, which means making sure runtime observations, provider semantics, exact shared identities, and heuristic correlations stay distinct after everything gets normalized into the graph.

Elias: That objective directly supports the whole concept; you can’t mix those things up if you want to be accurate about where an effect originated. They also have conservative attribution—if several entities look like they could be the cause, keep that ambiguity instead of picking one candidate just because it looks closest.

Priya: I like the focus on neutrality too. Objective three demands provider and OS neutrality at the graph boundary, meaning integration-specific telemetry maps into a stable vocabulary so downstream analysis doesn't need a different visualization for every single provider or operating system they use.

Nadia: That makes sense for usability across different environments; you want to analyze the data once, not build five separate dashboards for five different ways an agent might be running on Windows versus Linux. Objective four is incremental consistency—completed-live and standalone inspections should both converge on the exact same final graph and projection policy.

Elias: And finally, objective five is about explicit fidelity limits—things like sampling blind windows or non-causal filesystem observations must be represented as limitations, not just converted into negative evidence in a way that hides the issue.

Priya: That last point is really important for me because it tells us where the system stops being reliable; it doesn't try to pretend that something it can't observe is actually there. It makes the boundaries of its own knowledge very clear.

Nadia: So, in short, they are building a system where you can query by causal status—you can filter nodes by what they are and whether their connection is direct evidence or an inferred claim—which gives users much more control over how much trust they place in the resulting data.

Elias: It’s a method for cross-layer observability that emphasizes faithful derivation histories, which is the lineage they follow from older provenance systems. They are using this structure to handle the complexity of agent runtimes where identities include agents, sub-agents, tool calls, model requests, and processes fifteen, sixteen, seventeen, eighteen <ref:2610.21146#pg2,identities include agents, sub-agents, tool calls, model requests>.

Priya: So what this changes for us is moving beyond just collecting logs to building a structured view that explicitly shows the derivation path and the inherent uncertainty at every step.

Conclusion: Nadia: To wrap up, ExecWeave makes its claim explicit by preserving semantic and runtime observations as distinguishable evidence, materializing them into one typed graph, and marking those heuristic command-to-process bridges as inferred and non-causal. It’s a structural way to handle the messy reality of agentic software execution.

Elias: The bounded conclusion here is that cross-layer observability is most useful when the graph preserves where each observation came from, clearly distinguishes identity from causality, retains support for derived relations, and permits uncertainty to remain visible in the query structure.

Priya: I think what this means practically is that instead of getting a single score on an agent's behavior, you get a detailed map showing exactly which pieces of evidence led to that conclusion and where the potential errors or assumptions are baked in.

Nadia: It’s about making the uncertainty visible so you can manage your trust in the system better. We’ve seen them validate this end-to-end with an AutoGen–Ollama integration, showing they can actually do it across real systems, even when dealing with a portable collector that has some sampling blind windows.

Elias: The empirical results show that for fixed-work trials, there’s a substantial cost to doing this portable observation, with median paired elapsed-time overhead ranging from sixty-two point three percent to four hundred eight point eight percent across the three tested workloads. That's a concrete performance metric you need to consider when implementing something like this in production environments.

Priya: So, while it’s a sound architectural design for capturing provenance, we still need to see how robust it is under real-world stress and whether that cost is acceptable compared to the level of clarity it brings to debugging.

Nadia: The next steps they are looking at involve repeating those portable sampling protocols on Windows and macOS, expanding those real provider end-to-end runs with independent ground truth, and doing controlled human studies on evidence-backed debugging tasks.

Elias: They also plan to compare this system against other representative observability systems under matched instrumentation conditions and scale up the unique graph entities as well as repeated events.

Priya: And I’m looking forward to those human studies because ultimately, if we’re trying to build tools that people actually use for debugging, we need to know if this level of explicit uncertainty really translates into better decision-making for a human operator.