How a scan reasons without a model

A scanner that reasons with a language model is convenient right up to the moment an auditor asks why. "The model flagged it" is not a control. The deterministic layer exists so that the load-bearing part of a review, the part a regulated buyer signs against, is something you can re-run to the byte and read line by line.

It does this in four moves: it builds a model of your system, runs typed matchers that fail closed, synthesizes the attack paths those findings sit on, and raises severity by reachability. The rest of this page walks each move against the same insecure agent the landing page scans.

Determinism is the feature. No eval, no network, no model in the path. The classifier that reviewed a design is a hash of a YAML file, and it says the same thing next year.

Move one

Four inputs become one graph

Terraform, Kubernetes manifests, MCP server configs, agent instructions, and system prompts are five different file formats describing one system. Attestral ingests all of them into a single system model: a graph of components (a bucket, a container, an MCP server, an agent), edges (who can reach whom), and trust boundaries (the cloud account, the cluster, the agent runtime). Every later check reasons over this one shared graph, which is why a finding can span a Terraform bucket and an MCP server in the same breath.

Move two

Typed matchers that fail closed

A rule is pure data. It names a component target, a match built from typed matchers, and the framework controls it maps to. There is no code to run and nothing to interpret, which is the whole point: the check cannot do anything except compare typed fields.

- id: ATL-103
  title: Shell-capable MCP server configured
  severity: critical
  target: mcp_server
  match: { attr_list_any_of: { capabilities: ["shell", "exec"] } }
  frameworks: ["OWASP-AgSec TOOL-1", "MITRE ATLAS AML.T0053"]

Each matcher, attr_equals, attr_missing, attr_list_any_of, model_has_both, and the rest, is a named function in the engine. The dispatch is the security property: if a rule names a matcher the engine does not recognize, the check returns no match. It never throws, never guesses, never fires by accident.

The pack is 232 rules today: agentic and cross-boundary checks in core_rules.yaml, and modular per-provider cloud packs for AWS, Azure, GCP, and Kubernetes. We do not chase a thousand-rule count. Every rule cites a real CIS, NIST, OWASP, or MITRE control and ships with a fixture that proves it fires, because a rule nobody would act on is worse than no rule at all.

Move three, the part linters cannot copy

Findings become attack paths

Most scanners hand you a flat list and let you guess which items combine into a real breach. Attestral walks the graph and reports the chain: an entry where untrusted input arrives, a pivot where it reaches code execution, and an impact where data can leave. The classic case is the lethal trifecta, private-data access, exposure to untrusted content, and an outbound path, sitting in one agent session.

Move four

Severity follows reachability

A shell tool that nothing untrusted can reach is a smaller problem than the same tool sitting one hop downstream of a web-fetching server. So after the paths are walked, Attestral raises the severity of any finding that sits on a reachable chain by one band, and says so in the output. Priority stops being a static label and starts reflecting the graph.

reachability: 10 findings sit on a walked attack chain; 3 raised one band
ATL-107  Outbound network reach  (mcp_server.web)  medium → high
           path: internal chain: jira, web -> deploy, shell -> web

Nothing here is hidden or lossy. A finding that gets raised carries the reason; a finding that gets waived later stays on the record. The deterministic layer produces the evidence, and the evidence is the product.

In the scan

Where it runs, and what it emits

The deterministic layer runs on every scan, first, with no flags. It reads declared configuration and agent wiring: what a Terraform file says a bucket is, what an MCP config says a server can do. It is a design review, not a SAST tool, so it does not trace arbitrary application logic. Every finding it emits is tagged origin=deterministic and lands in the same evidence chain and SARIF (the static-analysis result format GitHub's Security tab reads) as the ML and judge layers.

# attestral scan examples/vulnerable-agent
6 components · 16 findings · 4 critical · 11 high · 1 medium
ATL-202  critical  Tool fleet forms an exfiltration chain (lethal trifecta)
ATL-103  critical  Shell-capable MCP server configured  (mcp_server.shell)
ATL-108  critical  Tool calls auto-approved without a human checkpoint
           origin=deterministic  no eval  fails closed

Honest limits

What determinism does and does not buy

It also reads only what is declared. If a capability is configured somewhere Attestral does not ingest, it is not in the graph and not in the review. The honest framing is that this layer is the floor, comprehensive, cheap, and certain over what it models, and the two optional layers extend reach into language and design judgment that no fixed rule can capture.

Keep reading

The other two layers

The deterministic layer scores structure. The next one scores language: how DeBERTa reads a prompt injection. The third cross-examines the findings themselves: the LLM-as-judge layer. All three feed one evidence chain, each tagged by origin.

References