ADLC Security Best Practices for Teams Shipping with Coding Agents | Endor Labs

What it is

A vendor guide from Endor Labs on securing development done with AI coding agents (the "agentic development lifecycle", not building agents as products). Its central claim is that most AppSec tooling first sees agent work at the pull request, after the agent has already read files, run shell commands and installed packages. It then places controls at each earlier stage. The last section describes Endor Labs products (Coding Agent Governance, Package Firewall, AURI, Artifact Signing), but the controls themselves are vendor-neutral.

How it works

• Hooks versus prompt rules. An AGENTS.md or system-prompt rule depends on the model choosing to comply, and an injected instruction in an issue can outweigh it. Claude Code and Cursor expose hooks that run before a tool call or shell command. A policy returns allow, block or audit regardless of what the model wants. The page's illustrative policy blocks rm -rf on /, ~ or ., blocks reads of **/.env, ~/.aws/credentials and ~/.ssh/*, blocks MCP servers not on an allowlist, and audits git push with --force.
• Install-time package checks. An agent picks a package name, sometimes from memory, and runs npm install or pip install with no human review. The install script runs immediately, so a later CI or SCA scan of the lockfile is too late. The page cites the 2025 USENIX Security paper "We Have a Package for You!": models regularly suggest nonexistent packages, and the invented names recur across repeated prompts, so attackers can register them (slopsquatting).
• Logic flaws. The page shows an agent-written Flask password reset handler with @login_required but no ownership check on user_id. It has no dangerous sink or hardcoded secret, so pattern-based scanners have nothing to match. It is an IDOR that needs reasoning about caller and resource.
• Triage. Prioritize findings in agent PRs by reachability and exploitability, with the call path and data flow attached so a reviewer can decide in minutes.

Preconditions / Affected

Applies to teams where agents run with developer permissions, can install packages, and can write to repos. The hook approach needs an agent that supports pre-execution hooks. The page names Claude Code and Cursor.

What to do

The page recommends this adoption order: inventory, action policy, install-time checks, then code and PR review.

• Inventory agents (IDE, terminal, CI), models including local ones, MCP servers with their tool definitions, and skills, rules files and hooks. Keep allow and deny lists. Pin MCP servers and skills like dependencies, record hashes, and review updates, since tool descriptions can change after approval.
• Run agents in disposable containers or VMs with short-lived, task-scoped tokens. Keep production secrets out of the environment and limit network egress to needed registries and APIs.
• Treat repo files, issues, PR comments, fetched web pages, tool responses and MCP tool descriptions as untrusted input.
• At install time, block known malware, reject versions published in the last few days (a cooldown), apply license policy, and log package, version, agent and developer.
• Baseline hygiene: commit lockfiles, install from a trusted registry or proxy, and disable install scripts where the build allows:

npm install --ignore-scripts

• Protect the pipeline: protected branches with required reviews and checks, read-only default GITHUB_TOKEN with write scopes per job, third-party actions pinned to full commit SHAs, and CODEOWNERS on .github/workflows/, security tests and auth code. Sign artifacts in CI with keys the agent cannot reach and verify at deployment.
• Require human sign-off for changes to authentication, permissions, CI/CD config, security tests, releases and deployments. Never let an agent approve its own work.
• Log agent identity, model, starting human, prompt, tool calls, installs, policy decisions with the rule that fired, and approvals. Practice revoking credentials and killing a session. The page says that if either takes more than a few minutes, fix that first.

Metrics

The page proposes three groups. Coverage: share of agents, MCP servers and skills inventoried and approved, and share of sessions with policy enforced. Control activity: actions blocked or audited by rule, and packages blocked by reason (malware, cooldown, license). Outcomes: false positive rate on agent PR findings, share of agent PRs blocked, and mean time to remediate. A rising block count is not a win if most blocks are false positives.

Caveats

The policy YAML is labelled illustrative, not a shipped config. The page gives no cooldown length beyond "a few days". The Veracode 2025 figure it cites (45% of samples from over 100 models across 80 tasks introduced a flaw) is secondhand. The worked five-step example is a constructed scenario, not an incident.