Summary
Anchor currently escalates process execution findings (e.g. subprocess.Popen) to high-severity governance violations based solely on the presence of process execution within an AI codebase.
However, process execution alone does not demonstrate that an AI model can influence the executed command.
Severity should be determined by demonstrated data provenance rather than repository context alone.
Problem
Launching a subprocess is a common and legitimate programming practice.
For example:
subprocess.Popen(["python", "script.py"])
does not imply AI-controlled execution.
In contrast:
command = llm_response
subprocess.Popen(command)
represents a fundamentally different security property because the executed command originates from an AI model.
The current evaluation engine does not distinguish between these scenarios.
As a result, identical findings may receive the same severity despite representing very different risk profiles.
Proposed Solution
Introduce provenance-aware severity evaluation for process execution findings.
The evaluation should distinguish between:
Static command
↓
Normal process execution
and
LLM Output
↓
Command construction
↓
Process execution
Only the latter should qualify for governance findings specifically related to AI-controlled execution.
This does not require suppressing process execution findings entirely.
Instead, the engine should evaluate whether AI-generated data can influence the executed command before assigning AI-specific severity.
Benefits
- Improves severity accuracy.
- Reduces false-positive BLOCKER findings.
- Distinguishes ordinary software engineering from AI governance risks.
- Aligns findings with demonstrated evidence rather than assumptions.
- Establishes provenance-aware severity evaluation for future rules.
Acceptance Criteria
Design Notes
This issue focuses on severity evaluation, not detection.
Process execution remains an important security signal.
However, AI governance findings should be based on demonstrated AI influence rather than the presence of process execution alone.
Long-term, this capability can be generalized into provenance-aware evaluation across other security-sensitive sinks (filesystem operations, SQL execution, network requests, tool invocation, etc.), providing a consistent evidence-based foundation for governance severity.
Summary
Anchor currently escalates process execution findings (e.g.
subprocess.Popen) to high-severity governance violations based solely on the presence of process execution within an AI codebase.However, process execution alone does not demonstrate that an AI model can influence the executed command.
Severity should be determined by demonstrated data provenance rather than repository context alone.
Problem
Launching a subprocess is a common and legitimate programming practice.
For example:
does not imply AI-controlled execution.
In contrast:
represents a fundamentally different security property because the executed command originates from an AI model.
The current evaluation engine does not distinguish between these scenarios.
As a result, identical findings may receive the same severity despite representing very different risk profiles.
Proposed Solution
Introduce provenance-aware severity evaluation for process execution findings.
The evaluation should distinguish between:
and
Only the latter should qualify for governance findings specifically related to AI-controlled execution.
This does not require suppressing process execution findings entirely.
Instead, the engine should evaluate whether AI-generated data can influence the executed command before assigning AI-specific severity.
Benefits
Acceptance Criteria
Design Notes
This issue focuses on severity evaluation, not detection.
Process execution remains an important security signal.
However, AI governance findings should be based on demonstrated AI influence rather than the presence of process execution alone.
Long-term, this capability can be generalized into provenance-aware evaluation across other security-sensitive sinks (filesystem operations, SQL execution, network requests, tool invocation, etc.), providing a consistent evidence-based foundation for governance severity.