Skip to content

Back to the catalog

Engineering a security harness for AI coding agents | Blog | Endor Labs
endorlabs.comarticle

Engineering a security harness for AI coding agents | Blog | Endor Labs

Endor Labs engineering post arguing that prompts are not security controls and lays out a seven-question framework for building a "security harness" around AI coding/remediation agents: defining the job, minimizing evidence to authoritative facts, tiering authority (Read→Recommend→Prepare→Publish→Enforce), gating consequential actions on proven conditions, evaluating process/result/outcome with contestability, failing closed on interruption or attack, and versioning/owning the agent over time. It illustrates the approach with a controlled dependency-remediation workflow (upgrading Jinja2 with explicit stop-for-approval gates) and cites an internal benchmark where evidence-equipped agents used 91.7% fewer tokens (6.6M vs 79.5M) than agents that had to reconstruct security posture via tool-loop reconnaissance.

TL;DR Endor Labs' seven-question framework for constraining AI coding/security agents with evidence gates, tiered authority (read→recommend→prepare→publish→enforce), and fail-closed operational controls instead of relying on prompt instructions.
Open original ↗
Also seen from another angle🧠 AI →
Document

What it is

An Endor Labs framework post on the implementation layer of an AI-agent "security harness." The summary already carries the seven-question framework, the Read→Recommend→Prepare→Publish→Enforce tiers, the Jinja2 3.1.1→3.1.6 walkthrough, and the token benchmark. What it does not carry is the concrete control-enforcement model the post uses to make gating actually hold — that is the part an engineer building this would act on.

How it works

The post distinguishes three stacked control layers, and the distinction is the whole point (prompts alone fail):

  • Instruction guides — the prompt tells the model what evidence to use and when to ask for approval. Advisory only.
  • Validation rejects — a check fails the run when required evidence, provenance, risk decisions, or approval state are missing.
  • Enforcement withholds — the runtime does not expose or execute the consequential capability until conditions are met. The agent "could not proceed," not merely "was told not to."

The operational guidance is equally concrete: model consequential workflows as state machines, not prompt chains. Loops (targeted retry on missing evidence, bounded repair on failed validation) are allowed but must carry budgets, retry ceilings, and explicit stop conditions — "a loop can recover; it cannot skip a gate." Interruptions must checkpoint state and retries must be idempotent so repeats don't duplicate or compound effects. Untrusted repo/tool text is treated as data, never authority.

What to do

If you are building or reviewing an AI remediation agent, don't encode gates as prompt instructions. Implement each Publish/Enforce transition as a runtime capability that is withheld until a validation check confirms evidence + approval state, and make retries idempotent.

Caveats

The cited benchmark (91.7% fewer tokens) measured execution economics across 34 prompts / 13 scopes / 884 responses, not correctness, and excluded upstream deterministic computation. The post itself notes gains vary by task, model, and environment.

Technologies named here

Techniques named here

  • Three-layer control design
  • Controlled agentic workflow as state machine
  • Bounded repair/retry loops

Related in AI Security