Skip to main content
Secure coding checks are Coding Agent Governance policies that inspect what an AI coding agent produces, not just the shape of its actions. Two checks are available: a malware check for the packages an agent installs, and a secrets check for the content it writes and reads. Both run in the agent loop, so they catch problems at the moment they happen instead of in a later scan. Other Coding Agent Governance policies match patterns you author, such as regex patterns for commands and file paths. Secure coding checks carry no patterns to maintain. The policy decides when the check runs and which action follows a match. The verdict comes from Endor Labs data: the malware feed for packages, and the secret detection rules library for content.

​
Malware check

The malware check fires when a governed agent installs a package. The check looks up the package in the Endor Labs malware feed, the same intelligence that powers malicious package detection and Package Firewall. Only confirmed malware triggers the policy. Contested records and records under review do not. The check parses the packages out of the install command the agent runs. It recognizes the following package managers:
  • npm: npm, pnpm, yarn, bun, npx, and bunx.
  • PyPI: pip, python -m pip, poetry, pipenv, uv, and uvx.
  • Go: go install.
  • NuGet: dotnet add package, nuget, and paket.
  • Packagist: composer.
  • Crates: cargo.
  • RubyGems: gem and bundle.
  • OS package managers: apk, apt, yum, dnf, and zypper.
A command hidden behind a wrapper still counts. The parser unwraps prefixes such as sudo and env, and inline shells such as bash -c "npm install …". A malware violation carries the evidence your team needs to respond:
  • The package name, version, and ecosystem from the install. An unpinned install shows an empty version.
  • A summary of the malware report and the reasons the feed flagged the package.
  • The feed source that flagged the package.
A malware check applies to all ecosystems by default. To limit a policy to specific ecosystems, set its ecosystems list through the REST API. The valid tokens are npm, pypi, go, nuget, packagist, cargo, gem, apk, debian, and rpm, and Endor Labs rejects a policy that carries any other value. The policy form does not expose secure coding fields yet. The out-of-the-box policy Malware: block installs of known-malicious packages is disabled by default. Enable it, or create your own malware policy, to turn the check on. The following example creates a malware policy scoped to npm and PyPI installs with endorctl. Replace <namespace> with the namespace that owns your Coding Agent Governance policies. Leave ecosystems empty to check every ecosystem.
The policy appears under Policies & Rules > Agent Governance, and hooks pick it up at the next session start.

​
Secrets check

The secrets check scans content the agent touches for secrets, such as cloud access keys, provider tokens, and private keys. By default a policy scans the content of file writes and edits. Add FILE_OPERATION_READ to the policy’s file_operations list to also scan the files the agent reads. Read scanning is opt-in because it reads each file from disk. Detection uses the Endor Labs secret rules library, the same rules as secrets scanning. See Secret detection rules for the full library. The scan runs on the developer’s machine, and the scanned content never leaves it. A secrets violation carries:
  • The rule that fired, such as aws-access-token or github-pat, with its human-readable name.
  • The line and column where the secret starts.
  • A fingerprint that groups repeat findings of the same secret.
The violation never includes the secret value, so a match can’t leak the credential it found. Endor Labs also scrubs the detected string from the event evidence it stores. It replaces every occurrence in the captured tool input and output with REDACTED. When a permitted operation runs, the follow-up event records that the operation happened without carrying the file content. Two more policy fields shape the check through the REST API:
  • include_file_patterns limits scanning to matching paths, and exclude_file_patterns skips paths such as test fixtures or vendored directories. Exclusions apply after inclusions. An empty configuration scans every file the event covers.
  • include_rule_ids limits the policy to specific detection rules, and exclude_rule_ids mutes rules whose matches are false positives in your codebase. Both match rule IDs such as aws-access-token exactly. Exclusions apply after inclusions.
To create a secrets policy, follow the malware policy example with a secrets_check activity in place of malware_check. Two out-of-the-box secrets policies are disabled by default: Secrets: block writes that introduce a credential and Secrets: ask before reading a file that holds a credential. Enable them, or create your own secrets policy, to turn the check on.

​
Actions

Secure coding checks use the same actions as every other Coding Agent Governance policy: Block stops the action, Alert records it, and Ask Permission pauses for the developer. Violations appear under Policy Violations next to the rest of your governance activity. See Actions for what the developer and your security team see for each action.

​
How the checks fit with other Endor Labs protection

Endor Labs catches malicious packages and secrets at more than one layer, and each layer covers a different point in the workflow:
  • Secure coding checks act in the agent loop, at the moment an agent installs a package or touches a secret.
  • Package Firewall protects the registry path for every install in your organization, whether an agent or a person runs it.
  • Secrets scanning finds secrets already committed to your repositories and pull requests.
The layers share the same intelligence, so a package blocked in the agent loop is the same one Package Firewall blocks at the registry.

​
Limitations

Be aware of the following limitations:
  • Checks run for supported agents on machines with hooks deployed.
  • The secrets check inspects content the agent touches in a session. It is not a repository-wide scan. Use secrets scanning for full-repository coverage.
  • Like all Coding Agent Governance controls, these checks are guardrails for agent behavior, not a security boundary. See What Coding Agent Governance is (and isn’t).