AI coding agents need security skills, not vague prompting

At a glance

What this is: This article argues that AI coding agents need structured security skills, not vague system prompts, to produce secure code reliably.

Why it matters: It matters because IAM, NHI, and AI governance teams now have to decide how agent behaviour is constrained, tested, and audited before code reaches production.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Semgrep's guide on writing security skills for AI coding agents

Context

AI coding agents are now participating in software delivery, which turns code-generation quality into a governance problem as well as a developer productivity issue. The core gap is that generic prompts cannot express the context, tradeoffs, and framework-specific decisions needed to keep generated code secure, especially when the agent is expected to make decisions without a human in the loop.

For identity and security programmes, the important intersection is not just code quality but the identity of the system producing the code, the permissions it can exercise, and the controls that bound its behaviour. That makes this a practical issue for NHI governance, agentic AI policy, and application security teams that need to prove how agent-generated changes are constrained, reviewed, and tested.

Key questions

Q: How should security teams implement security skills for AI coding agents?

A: Start with the vulnerability classes that appear most often in your own findings, then write one tightly scoped skill per class. Each skill should include plain-language intent, realistic bad and good examples, and the specific framework or library context the agent needs to make the right decision. That approach is far more reliable than generic secure-coding prompts.

Q: Why do AI coding agents need more than system prompts for secure development?

A: System prompts are too broad to capture the context-dependent choices that secure code requires. Agents need instruction that specifies what to do in a given framework, what tradeoff to choose when requirements conflict, and what secure pattern to prefer. Without that, they either ignore the guidance or overconstrain valid code.

Q: What breaks when security skills are too broad or too prescriptive?

A: Broad skills lose decision value because the agent cannot tell which rule applies in a specific code path. Overly prescriptive skills become checklists that fail in ambiguous cases, especially when a safe pattern depends on the library, language, or business requirement. The result is inconsistency, not control.

Q: How can teams tell whether AI-generated code needs extra review?

A: Track where code or changes were produced by AI agents, then apply deeper static analysis and human review to paths that touch authentication, secrets, input handling, or sensitive data. The goal is not to distrust every generated line, but to concentrate scrutiny where the likely failure modes are highest.

Technical breakdown

Why broad prompting fails for secure code generation

A system prompt that says “write secure code” is too abstract for an LLM to apply consistently. Secure coding decisions are contextual: the safe pattern for input handling, authentication, or file access changes by language, framework, and threat model. Agents also optimise for helpfulness, so vague instructions can produce either weak compliance or overcorrection, such as refusing legitimate code. Security skills work because they encode specific decision context, examples, and boundaries that the agent can follow at runtime.

Practical implication: replace generic policy prompts with scoped, scenario-specific instructions that map to your actual application stack.

What makes a security skill machine-usable

A useful skill is tightly scoped, includes positive and negative examples, and describes decision logic rather than a checklist. That means showing the agent what acceptable code looks like, what insecure code looks like, and what tradeoff to apply when requirements conflict. Framework awareness matters because the skill must reference the libraries and patterns the agent is actually using. Without those details, the skill reads like documentation instead of executable guidance.

Practical implication: build skills around concrete vulnerability classes and framework-specific patterns, then test them against real prompts.

Why detection and skills should work together

Skills reduce insecure output at generation time, but they do not eliminate residual risk. Detection still matters because some AI-generated code will reach production without adequate skill coverage, and those sections may deserve stricter review or static analysis. Tagging or identifying AI-generated code helps security teams prioritise where to spend limited review effort. The effective model is a feedback loop: detection reveals where skills fail, and skill refinement reduces the burden on detection.

Practical implication: pair generation-time controls with post-generation analysis so review depth matches actual risk.

NHI Mgmt Group analysis

Structured guidance is becoming the control plane for AI coding agents. Vague prompts do not give security teams a reliable way to shape agent decisions, which is why skills matter more than slogan-level instructions. For application security, this shifts the governance question from “did the model know better?” to “was the model given an enforceable decision rule?” The right comparison is not prompt versus no prompt, but machine-readable control versus human hope.

AI-generated code creates an identity and privilege problem, not just a code-quality problem. When an agent can write, alter, or propose code inside development workflows, the security question becomes what that agent is allowed to do and how its actions are bounded. That is where NHI governance and agentic AI security meet application delivery, because the agent behaves like a software identity with defined access and observable outputs. Practitioners should treat agent permissions, review paths, and runtime boundaries as first-class governance objects.

Security skills are useful because they translate policy into repeatable agent behaviour. Static analysis flags issues after code exists, but skills aim to influence the code before it is written. That makes them a control for preventative governance, not merely detection. The broader lesson is that agentic AI programmes need control structures that are testable, versioned, and mapped to real failure modes rather than aspirational policy language.

AI code review will become more selective as agent volume rises. As agents contribute more production code, teams will need better ways to decide where human review, automated testing, and static scanning should intensify. The practical consequence is a move toward risk-based review allocation, where security teams prioritise agent-generated code paths that touch authentication, secrets, input handling, and sensitive data flows.

What this signals

Skill design is becoming a governance discipline, not a developer convenience feature. Teams that treat AI coding guidance as a policy artifact will get more consistent outcomes than teams that rely on generic prompting. The useful pattern is to version skills, tie them to specific vulnerability classes, and review them the same way you review application security controls.

The operational signal is that agent-generated code should be treated as a distinct review population. Where organisations can identify those outputs, they can focus stronger static analysis and approval controls on authentication, secrets, and data-handling paths. That is the real payoff of combining code skills with provenance tracking.

For identity-led security programmes, the deeper lesson is that AI systems that write code must themselves be governed as privileged software identities. Once an agent can shape production code, it sits inside the change chain and should be constrained with the same seriousness applied to other high-trust non-human identities.

For practitioners

• Define scoped security skills for your highest-risk code patterns Start with your top recurring findings, such as input sanitisation, secrets handling, authentication flows, and path traversal. Keep each skill narrow enough that the agent can apply it consistently within one framework or language pattern.
• Embed positive and negative examples in every skill Include one vulnerable snippet and one corrected version drawn from real code patterns in your stack. Agents learn better from concrete contrast than from abstract rules alone, especially when the output needs to stay usable for developers.
• Test skills with adversarial prompts before rollout Ask the agent to produce insecure code on purpose, then verify whether the skill blocks or corrects it. Use those results to tune wording, scope, and exception handling before the skill is treated as production policy.
• Link agent-generated code to stronger review rules Tag code or changes produced by AI coding agents so security teams can apply stricter static analysis and review depth to the highest-risk areas. Prioritise anything touching authentication, secrets, or sensitive data access.

Key takeaways

• AI coding agents need security skills that encode context, examples, and decision logic, because generic prompts are too vague to govern secure output.
• The control problem extends beyond code quality, because agent-generated output creates review, privilege, and provenance questions that belong in security governance.
• Teams that combine skills with detection, testing, and selective review will have a better chance of keeping AI-generated code secure at scale.

Key terms

• Agent Skill: A reusable package of task-specific knowledge and procedures that an autonomous agent can load when needed. In practice, it separates general awareness from operational detail, which makes enterprise context easier to govern than a single oversized prompt.
• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• Security Skill: A security skill is a short instruction set that shapes how an AI model evaluates threats before acting. In agentic workflows, it can improve refusal behaviour and threat awareness, but it does not authorise access or replace identity controls. Its value is behavioural, not governance-grade assurance.
• Static Analysis Feedback Loop: A static analysis feedback loop uses code scanning results to improve the guidance given to AI agents and developers over time. Findings show where controls are failing, while updated skills and rules reduce repeat issues, creating a cycle that improves both prevention and detection.

What's in the full article

Semgrep's full post covers the operational detail this post intentionally leaves for the source:

• Concrete examples of security skills for specific vulnerability classes, including path traversal and input handling
• Practical patterns for turning static analysis findings into agent instructions that can be applied in real workflows
• Guidance on testing whether an AI coding agent follows a skill when prompted to produce insecure code
• A closer look at how Semgrep's rules and skill collections can be used together in a development pipeline

👉 Semgrep's full post covers examples, testing approaches, and the change-management loop for agent security skills

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It gives security practitioners a practical foundation for governing software identities and the controls around them.