Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you detect security issues introduced by AI coding agents?
Updated
Catch AI-introduced defects with the same SDLC scanners you already run — secret, SAST, DAST, dependency, and config checks — plus prioritisation using KEV, EPSS, and CVSS on findings from agent-authored merges. This page is not legal advice.
AI agent security detection, last verified 10 September 2026 against OWASP Top 10 and OWASP LLM / GenAI guidance, NIST SP 800-218 and SP 800-218A (SSDF), CWE, CISA secure-by-design principles, CISA KEV catalog, FIRST EPSS specification, and CVSS v3.1 / v4.0 specifications from FIRST. Not legal advice.
Audience and scope
Audience: a CISO or engineering leader responsible for code shipped after AI coding agents or assistants draft diffs. This page is technical control guidance, not legal advice and not a penetration-test report.
AI agents amplify familiar failure modes: they paste secrets, reproduce vulnerable patterns, add typosquatted dependencies, and emit insecure defaults faster than manual typing. Detection is pipeline coverage plus triage discipline — not a one-time model audit.
AI failure modes mapped to detection controls
Each row ties a failure mode to a primary control. Labels distinguish baseline SDLC security (what regulated mature shops already run), industry best practice (what high-assurance AI-assisted teams add), and SRM recommendation (how this product ingests and prioritises). Last verified 10 September 2026. Not legal advice.
- CWE names weakness types; scanners emit CWE IDs where configured. Use CWE to train reviewers on recurring AI patterns.
- NIST SP 800-218A extends SSDF practices for AI-assisted development — align YOUR secure SDLC narrative to PO.Develop and PO.Test activities.
- CISA secure-by-design encourages evidence that security is default, not bolt-on — document gates on agent PRs.
| Failure mode | Example | Detection control | Kind |
|---|---|---|---|
| Hard-coded secrets and credentials | API keys, tokens, private URLs in generated commits | Secret scanning on every push; pre-commit hooks; block merge on findings | Standard SDLC security |
| Injection and unsafe deserialization | SQL/command injection sinks, unsafe eval, missing parameterisation | SAST rules tuned to YOUR stack; code review on data-flow paths | Standard SDLC security |
| Vulnerable or unmaintained dependencies | Outdated libraries with known CVEs | Dependency / software composition analysis; lockfile policy | Standard SDLC security |
| Typosquatted or malicious packages | Package names one edit away from a popular module | Dependency allow-lists, provenance checks, manual review on new deps | Industry best practice |
| Insecure configuration defaults | Public buckets, debug flags, weak TLS, overly broad IAM | Infrastructure-as-code scanners; DAST on staging; policy-as-code | Standard SDLC security |
| LLM-specific prompt injection in app features | User text steers tool use inside YOUR product | OWASP LLM guidance controls; output validation; privilege boundaries | Industry best practice — OWASP GenAI / LLM |
| Missing authZ on agent-generated endpoints | New routes without role checks | SAST auth patterns; integration tests; DAST authenticated scans | Standard SDLC security |
| Prioritisation noise on large finding backlogs | Hundreds of low issues after agent sprint | KEV presence, EPSS score, CVSS severity — triage in combination | Industry best practice — FIRST / CISA |
| Cross-source duplicate alerts | Same CVE from SAST and dependabot | Deduped findings view with blast-radius context | SRM recommendation — vendor ingest |
KEV, EPSS, and CVSS — how to triage without theatre
CISA Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with confirmed exploitation in the wild — a prioritisation input, not the only input.
FIRST Exploit Prediction Scoring System (EPSS) estimates exploitation probability for CVEs — probabilistic, updated daily; pair with context.
CVSS base scores from FIRST specifications (v3.1 and v4.0) describe severity vectors — not business risk alone.
A finding on an agent-authored path in a non-production repo with no exploit path may still merit fix, but rank below KEV-listed issues on internet-facing services.
Standard SDLC security vs best practice vs SRM recommendation
SRM ingests SAST, DAST, dependabot, code-scanning, and secret-scanning signals where connected. It does not replace YOUR scanners, does not certify secure code, and does not determine legal breach notification duties.
| Control | Kind | Agent-specific note |
|---|---|---|
| Branch protection + required status checks | Standard SDLC security | Apply to bot and agent accounts too. |
| Secret scanning + push protection | Standard SDLC security | Agents paste keys from prompts — scan before merge. |
| SAST on PR | Standard SDLC security | Tune false positives so reviewers do not mute the tool. |
| DAST on staging | Standard SDLC security | Catch config and runtime issues SAST misses. |
| Risk-tiered human review for agent PRs | Industry best practice | See review-agent-generated-pull-requests guide on this site. |
| KEV + EPSS + CVSS combined prioritisation | Industry best practice | Document weighting — not CVSS alone. |
| First-party findings ingest with dedup | SRM recommendation | Signed-in Security findings surface; no certification implied. |
| Transitive npm blast-radius context | SRM recommendation | Vendor methodology on dependency reachability. |
Detection-coverage checklist
Walk this before expanding autonomous agent write access. Not legal advice.
- Secret scanning runs on every repo that agents touch; merge blocked on verified secrets.
- SAST policy matches YOUR languages; rules updated within the last quarter.
- Dependency analysis covers lockfiles agents modify; new packages need allow-list or reviewer approval.
- DAST or equivalent dynamic test runs on staging for internet-facing services.
- Infrastructure-as-code scanners cover cloud config agents edit.
- Agent/bot accounts use least-privilege tokens; no long-lived prod credentials in agent environments.
- Findings triage uses KEV, EPSS, and CVSS together — methodology documented on what-we-measure.
- High-risk paths (auth, crypto, PII) require human review regardless of green CI.
- Incident runbook names how to revoke credentials if an agent leaks a secret.
What you need to do now
Close detection gaps on agent workflows before widening autonomy. Last verified 10 September 2026.
- Inventory which repos agents can commit to; map current scanner coverage per repo.
- Enable push protection for secrets on those repos if not already on.
- Tag PRs from agent accounts for risk-tiered review per the review-agent-generated-pull-requests guide on this site.
- Connect findings ingest so KEV, EPSS, and CVSS prioritisation is visible in one place.
- Read the is-ai-generated-code-secure guide on this site for secure-use framing and the ai-coding-governance-checklist guide on this site for governance controls.
- The vulnerability-management glossary on this site defines programme terms — not a link to unpublished HC11 docs paths.
Checklist
Detection coverage checklist for CISOs and engineering leaders. Not legal advice.
- Are secrets scanned on every agent-touched repo with merge blocking?
- Does SAST run on every agent PR with tuned noise levels?
- Are new dependencies reviewed or allow-listed?
- Does DAST cover staging for external attack surface?
- Is KEV + EPSS + CVSS triage documented?
- Are agent accounts least-privilege with rotation?
- Is there a human review rule for auth, crypto, and PII paths?
- Can we trace a finding back to an agent-authored merge for remediation metrics?
Where this shows up in ShipReady Metrics
Signed-in Security findings ingest SAST, DAST, dependabot, code-scanning, and secret-scanning sources where connected, with cross-source deduplication.
Prioritisation can reflect KEV presence, EPSS scores, and CVSS severity per methodology on what-we-measure — not a sole risk score.
Transitive dependency blast-radius context helps rank npm reachability for dependency findings.
AI-authored-code floor in AI Code Readiness counts attributed-AI commits — provenance for review sampling, not malware detection.
The product does not run YOUR scanners, does not certify SSDF conformance, does not replace pen tests, and does not determine regulatory notification obligations.
Primary sources (last verified 10 September 2026)
Security standards and catalogues cited on this page. Re-check for revisions. Not legal advice.
OWASP Top 10 and OWASP GenAI / LLM project materials. NIST SP 800-218 (SSDF) and NIST SP 800-218A. MITRE CWE. CISA secure-by-design principles. CISA Known Exploited Vulnerabilities catalog. FIRST EPSS specification and CVSS v3.1 / v4.0 specifications.
The is-ai-generated-code-secure guide on this site is live. The review-agent-generated-pull-requests guide on this site is live. The ai-coding-governance-checklist guide on this site is live. The vulnerability-management glossary on this site is live. The kev, epss, cvss, sast, and dast glossary entries on this site are live.
Frequently asked questions
Do we need new scanners just for AI agents?
Usually no. You need the same secret, SAST, DAST, and dependency controls applied consistently to agent-authored merges, plus stricter review on high-risk paths. Gaps are often coverage and policy, not missing AI-specific SKUs.
Should we fix only CVSS critical findings?
No. Use KEV, EPSS, and CVSS together with asset context. CVSS alone misses exploitation likelihood; KEV alone misses issues not yet catalogued.
Does ShipReady Metrics scan our code?
No. It ingests findings from tools you already run when connected. It prioritises and deduplicates; it does not replace scanners or certify clean code.
Is this legal or breach-notification advice?
No. Notification duties depend on jurisdiction, contract, and facts — counsel decides.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.