Session Relationships

How the proxy captures structural flow patterns within a session using fixed-size flow matrices

Status: shipped — Stage 1 in shadow mode. The flow matrix computes per-session; used by corroboration gates that are logged, not enforced.

Session Relationships

The fingerprint captures the statistical shape of an agent’s individual actions, but it doesn’t capture structural flow patterns — how capabilities transition from one to another within a session. The session buffer fills this gap with fixed-size flow matrices that capture the shape of behavior without hardcoding specific patterns.

Design: Flow Matrices, Not Pattern Matching

The proxy does not enumerate specific relationship types (e.g., “read then send = exfiltration”). Instead, it accumulates fixed-size matrices that capture the structural shape of capability transitions. Anomaly = divergence from the agent’s learned flow baseline.

This means new attack patterns are detected because they produce unusual flow shapes, not because we anticipated the specific capability pair.

Session Flow Accumulator

Every Push() to the session buffer increments counters in three fixed-size matrices:

1. Flow Matrix [12][12]uint16

Counts how many times each capability transitioned to each other capability in this session.

         read  write  delete  exec  send  ...
read     [ 47    3      0      0     1    ...]  ← 47 read→read, 3 read→write, 1 read→send
write    [  2    5      0      1     0    ...]
exec     [  0    0      0      0     0    ...]
send     [  0    0      0      0     0    ...]

Gate 3 normalizes this to a probability distribution and computes JSD against the agent’s baseline FlowMatrix from the fingerprint. High divergence = structural anomaly.

2. Resource Flow Matrix [12][12]uint16

Counts how many times the same resource crossed from one capability to another. Only incremented when action.ResourceHash == previousAction.ResourceHash AND the capabilities differ.

This captures data movement: a file read then sent, a credential accessed then exfiltrated. Without naming specific patterns — just counting boundary crossings.

3. Depth-Capability Profile [12][8]uint16

Counts which capabilities appeared at which sub-agent nesting depths. Privilege escalation shows up as high-risk capabilities (execute, send) at deep depths that the agent hasn’t exhibited before.

How Gate 3 Uses Flow Matrices

Gate 3 compares session flow against the agent’s baseline using three JSD checks:

Check	What It Compares	Threshold	Signal
Flow divergence	Session FlowMatrix vs fingerprint FlowMatrix	JSD > 0.3	flow:structural_divergence
Resource boundary	Session ResourceFlows vs fingerprint baseline	Novel crossings > 5%	flow:resource_boundary_crossing
Depth anomaly	Session DepthProfile vs fingerprint DepthProfile	JSD > 0.3	flow:depth_anomaly

Any structural signal (weight >= 0.6) combined with corroborating Gate 2 signals triggers ANOMALOUS classification.

Why Not Hardcoded Patterns?

The previous approach used enumerated relationship types (RelTemporalAdjacency, RelResourceSharing, RelCausality, RelDataFlow) with a capability pair switch statement mapping read+send=1.0, read+delete=0.9, etc.

Problems with that approach:

1. New attack patterns required code changes
2. Strengths were static — they didn’t learn
3. An attacker using query→send_message instead of read_file→curl was invisible because the specific pair wasn’t cataloged

The flow matrix approach:

1. No code changes for new patterns — divergence from baseline catches any unusual shape
2. Baselines learn via EWMA in the fingerprint’s FlowMatrix
3. Any unusual capability flow is detected because the shape is abnormal, not because we enumerated it

Memory Budget

Component	Size	What It Captures
Flow matrix	288B	Capability transition counts
Resource flow matrix	288B	Resource boundary crossing counts
Depth-capability profile	192B	Capability occurrences per depth
Total session overhead	~768B	Full structural shape, fixed memory

No maps, no slices, no allocations on Push. All fixed-size arrays with O(1) update.

Session Export

On session end or periodic flush (60s), the flow matrices are included in the SessionSnapshot JSON export to NATS:

{
  "flow_matrix": [[47, 3, 0, ...], [2, 5, 0, ...], ...],
  "resource_flows": [[0, 0, 0, ...], ...],
  "depth_profile": [[50, 0, 0, ...], ...],
  "action_count": 200,
  "actions": [...]
}

The Behavioral Intelligence Service materializes the action chain as a full graph in Memgraph. The flow matrices provide the compressed structural summary for immediate analysis.

What the Session CAN vs CANNOT Detect

Detects (Local)

• Unusual capability flow shapes (any combination, not enumerated)
• Resources crossing novel capability boundaries
• Capabilities appearing at unusual nesting depths
• Temporal compression on specific transition types (via fingerprint’s TemporalFlow)
• Any structural divergence from the agent’s learned baseline

Cannot Detect (Remote Engine)

• Multi-hop chains requiring graph traversal
• Cross-session patterns (session-scoped buffer)
• Cross-agent coordination (each agent has own buffer)
• Partial data flow (hash-based, substring extraction breaks match)
• Novel structural invariants not captured by capability-level flow