Toward a Unified Application Data Model for Agentic AppSec

The Case for a Unified Context Model

Imagine trying to secure a system based only on its source code, with no knowledge of how it behaves under load, what data flows through it, or what third-party dependencies it dynamically pulls in. Or conversely, trying to triage a production vulnerability with no access to the underlying function or logic responsible.

Both of these are the norm today.

What we lack is a data model that binds:

• Lifecycle stage — insights from development, testing, staging, and production
• System layers — observability and traceability across code, container, and OS layers
• Execution semantics — real-world runtime context that distinguishes theoretical vulnerabilities from exploit paths
  

Without a model that ties these dimensions together, any security insight is necessarily partial. But if we build one, we unlock the ability to ask and answer a fundamentally richer set of questions:

• Is this vulnerability reachable from an external input path in production?
• Does this exploit path require environment-specific conditions to succeed?
• What memory behavior accompanies this API usage pattern under real-world load?
  

These are the questions that matter for both security triage and autonomous decision-making.

Design Goals of the Model

To be useful, a unified application data model must satisfy three key properties:

1. Precision
   The model must capture fine-grained detail at each layer—code-level ASTs, container metadata, syscall behavior, heap and memory access patterns—without losing fidelity across stages.
   
2. Correlation
   It must correlate behaviors across layers and lifecycle stages. For example, it should relate a log line in staging to a function in a specific microservice that allocates memory in a container with known capabilities.
   
3. Temporal Binding
   It should support time-based joins, making it possible to track how behaviors emerge or change over time, and how those shifts map to code changes or deployment events.
   

The Architecture

Here's how we at Kodem are thinking about architecting such a model to power intelligent security agents:

1. Sensor Fabric

We begin by deploying sensors at multiple points:

• Static analyzers during CI for ASTs, dependency graphs, and taint flows
• eBPF-based runtime sensors in Kubernetes for syscall and memory introspection
• Sidecar proxies and tracing hooks for API paths and data flows
• Container introspectors for file system and process behavior
  

Each sensor emits structured telemetry that is tagged with:

• Code identity (repo, commit hash, function name)
• Deployment identity (container ID, pod UID, node info)
• Event context (timestamp, origin, trace ID)
  

2. Telemetry Ingestion + Normalization

Sensor outputs are ingested into a stream processing system that applies:

• Type normalization (AST nodes, memory ops, syscall categories)
• Entity linking (functions ↔ containers ↔ runtime events)
• Privacy filtering (PII tagging and scrubbing)
  

3. Application Graph Construction

The normalized events are used to build a graph model of the application:

• Nodes represent functions, files, containers, processes, endpoints
• Edges represent observed execution paths, data flows, control flow transitions
• Weights encode runtime frequency, timing, or risk
  

This graph is versioned and updated incrementally across lifecycle stages.

4. Agent Interface

Security agents (autonomous or human-in-the-loop) query this graph to:

• Trace attack paths
• Simulate reachability
• Confirm exploitability
• Recommend remediations
• Run counterfactuals (e.g., “What if this component were removed?”)
  

The model allows reasoning about “what’s happening” in the app—at every layer, in every stage—at once.

Why This Matters for Agents

The most powerful AI agents in security won’t be the ones trained on generic code snippets or curated CVE datasets. They’ll be the ones trained on representations of how real applications behave under real workloads, in real environments.

These agents will learn that a buffer overflow in a library that’s never loaded into memory isn’t a priority. That an unpatched CVE that’s dynamically blocked by configuration is low risk. And that a low-severity bug, when chained with a permission escalation vector and an exposed endpoint, is actually a critical exploit path.

That kind of judgment only comes from context. And context only comes from a model that sees the whole picture.

‍

‍