Notifications
Clear all
Topic starter
09/07/2026 12:37 pm
TL;DR: AI coding assistants can speed delivery while increasing insecure code, secret leakage, and overconfident review failures, according to Knostic and cited research. Their value is real, but only when prompts, outputs, dependency checks, and file access are governed as untrusted pathways rather than productivity shortcuts.
NHIMG editorial — based on content published by Knostic: Key Findings on AI Coding Assistant Security
By the numbers:
- A 2025 paper found 6.93% of npm versions and 7.5% of RubyGems versions rely on at least one vulnerable dependency.
Questions worth separating out
Q: How should security teams govern AI coding assistants in software delivery pipelines?
A: Security teams should govern AI coding assistants like scoped non-human identities with limited repository access, explicit logging, and enforced policy gates.
Q: Why do AI coding assistants increase the risk of insecure code and secret leakage?
A: They increase risk because they can generate plausible but unsafe output, surface hidden dependencies, and expose sensitive context through prompts, logs, and file access.
Q: What breaks when AI-generated code is reviewed without security gates?
A: What breaks is the assumption that a clean-looking diff is a safe diff.
Practitioner guidance
- Restrict assistant scope to minimum necessary repositories and paths Grant only the repo, branch, and file access needed for the task.
- Block secrets from prompts and development logs Use redaction, masking, and prompt templates that remove credentials, customer data, and proprietary code before any assistant request leaves the environment.
- Enforce CI gates for dependencies and untrusted output Require SAST, DAST, secret scanning, unit tests, property-based tests, and dependency policies before merge.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Practical prompting patterns that avoid secret exposure while still supporting developer workflows.
- Detailed CI/CD guardrail examples for SAST, DAST, unit tests, and dependency enforcement.
- Workflow patterns for logging assistant file access and tying actions back to accountable identities.
- Examples of how to pair assistant use with sandboxing and least-privilege access boundaries.
👉 Read Knostic's analysis of AI coding assistant security and developer workflow risk →
AI coding assistants: are your code and access controls keeping up?
Explore further
09/07/2026 12:42 pm
AI coding assistants create an identity governance problem, not just a code quality problem. Once a tool can read repositories, infer context, and influence what gets merged, it behaves like a governed non-human identity inside the SDLC. That means scope, logging, and review are identity controls as much as engineering controls. Practitioners should treat assistant access as a lifecycle-managed entitlement, not a convenience feature.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Average secret remediation still takes 27 days, even though 75% of organisations say they are highly confident in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do teams stop AI assistants from exposing intellectual property and credentials?
A: Teams should prevent sensitive material from entering prompts, restrict the assistant to the smallest possible data set, and log file access for auditability. They should also use secret scanning, output filtering, and repository-scoped permissions so the assistant cannot read or reproduce more than its task requires.
👉 Read our full editorial: AI coding assistant security demands tighter code and access controls
