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. 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, such as npm or PyPI, set its ecosystems list through the REST API. The policy form does not expose secure coding fields yet. 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 writes or reads for secrets, such as cloud access keys, provider tokens, and private keys. 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. The record has no field for it, so a match can’t leak the credential it found. By default the check scans every file the event covers. 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. To create a secrets policy, follow the malware policy example with a secrets_check activity in place of malware_check.

​
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).