AI risk attribution

dpndncY estimates which regions of your codebase were likely AI-generated and co-locates that density with security findings — because AI-assisted code introduces vulnerabilities at a different rate and shape than hand-written code. Attribution is LOC-weighted and runs entirely on your infrastructure; no code leaves your network.

Why attribute AI code

AI coding assistants accelerate output but shift the risk profile: more boilerplate, more plausible-looking but subtly insecure patterns, and less author context. Knowing where AI density is high lets you weight review and amplify findings in those regions instead of treating every line equally.

The signals

Attribution blends complementary heuristics into a per-file, LOC-weighted score:

Signal	What it looks at
Explicit markers	Assistant attribution in commits/trailers, generated-file headers, tool fingerprints.
Structural deviation	Style/structure that deviates from the repository’s human baseline (naming, comment density, idiom).
Commit-burst pattern	Large, uniform additions landed in a single burst — the signature of generated blocks.
Per-language idiom	Language-specific rules (the engine collects every supported source language) plus generic heuristics.

It's an estimate, not a verdict

AI attribution is probabilistic — it reports density with confidence, not a binary “a human/AI wrote this line.” Use it to direct attention, not to assign blame.

How it amplifies findings

AI density feeds the attack-path score: a vulnerability that sits in, or whose exploit path passes through, a high-AI-density region is weighted up — so reachable bugs in the least-reviewed code surface first.

Using it

UI — AI density is shown per file and overlaid on the findings view.
API — query AI density by path to gate or report on it.

Private by design

Attribution uses git metadata and local structural analysis. Nothing is sent to an external model or service — it works air-gapped like the rest of the platform.

← Previous

Attack-path graph

Concepts