Agentic coding is software development in which AI agents generate, modify, and test code with limited human direction. In security terms, it creates a new NHI control surface because the agent may hold tool access, secrets, and repository permissions, requiring tight IAM, logging, approval gates, and policy enforcement.
What Agentic Coding Means in Practice
Agentic coding is not just “AI-assisted development” with a stronger autocomplete. The defining feature is delegated execution, where an AI agent can move from suggestion to action by creating files, editing code, running tests, and sometimes opening pull requests or invoking build tools with limited human supervision.
That shift matters because the development workflow becomes an access-bearing control surface. Once the agent can touch repositories, package managers, CI jobs, issue trackers, or terminals, its behaviour is no longer a pure productivity aid, it is an operational actor whose authority must be scoped and reviewed like any other privileged automation.
Why Agentic Coding Changes the Security Model
The security difference is not the code the model writes, but the permissions it holds while writing it. An agent with repository write access, cloud tokens, or CI credentials can introduce accidental or malicious changes at machine speed, and a mistaken prompt, poisoned context, or over-broad tool grant can expand that blast radius quickly.
This is why agentic coding must be treated as a governed identity pattern, not only a software engineering pattern. A secure setup separates task intent from execution authority, constrains what the agent can read or modify, and makes each meaningful action attributable to a human owner or a policy decision.
For a deeper treatment of delegated authority and least privilege for agents, see AI Agent Authorisation Guide.
Common Failure Modes in Agentic Development Workflows
Agentic coding often fails through overreach, not sophistication. The most common weaknesses are excessive repository and cloud permissions, secrets exposed in prompts or local context, unreviewed dependency changes, and tool chaining that lets one unsafe action cascade into many.
Another recurring issue is false confidence in generated output. Code that compiles is not necessarily code that is safe, and an agent can produce plausible tests, migrations, or fixes that quietly weaken authentication, logging, or access controls if the review process is too shallow.
Good observability is therefore part of the architecture, not an afterthought. If you cannot reconstruct what the agent saw, what it changed, and which approvals it relied on, then you cannot reliably distinguish productivity from unsanctioned automation.
For logging, attribution, and incident review patterns, use AI Agent Observability, Audit and Incident Response Guide.
How Teams Should Govern Agentic Coding
Agentic coding works best when teams define explicit boundaries around tools, data, and approval. That usually means short-lived credentials, scoped access to only the repos and environments the task needs, protected secrets handling, and a clear rule for when human review must block or override the agent.
Governance also needs ownership. Someone must be accountable for the agent’s permitted actions, the quality of its prompts and instructions, and the review standard for code it produces. Without that ownership, the agent becomes a convenient way to diffuse responsibility rather than a controllable engineering aid.
For the identity and control choices behind this operating model, the most relevant companion resource is Agentic AI Identity Guide.
Risk and Threat Considerations
Agentic coding increases the chance that a development tool becomes an execution path into source code, build systems, or secrets. If the agent is tricked, over-permitted, or poorly monitored, an attacker can use it to exfiltrate credentials, insert malicious changes, or persist through trusted automation.
Failure mechanism: The agent inherits enough access to make high-impact changes, then executes unsafe instructions, consumes poisoned context, or passes through a compromised dependency or tool integration.
Impact: The result can be code tampering, secret exposure, compromised CI/CD pipelines, or unauthorized changes that look like normal developer activity unless logs and approvals are strong enough to expose the abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agentic coding creates a non-human actor that can be over-scoped |
| NHI-02 — Secret Leakage | Coding agents can expose credentials in prompts, context, or generated code | |
| NHI-04 — Insecure Authentication | Agentic coding depends on how the agent authenticates to tools and services | |
| Recommendation — Limit the agent to the minimum repository, tool, and secret access needed for the task. Keep secrets out of agent context and prevent code-generation paths from handling live credentials. Use strong, scoped authentication for agent tool access and avoid shared long-lived credentials. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic coding centralises delegated authority and privilege decisions |
| ASI02 — Tool Misuse | Coding agents operate through connected tools that can be misused or chained unsafely | |
| Recommendation — Constrain agent privileges and require policy checks before high-impact actions run. Restrict available tools and validate each tool invocation against task intent. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agentic coding needs minimal permissions across repositories, CI, and related systems |
| AU-2 — Event Logging | Auditability is essential when an agent can change code or access secrets | |
| IA-5 — Authenticator Management | Agentic coding often relies on API keys, tokens, and other credentials | |
| Recommendation — Assign the agent only the permissions required for the specific coding task. Log agent actions, approvals, and tool calls so changes can be attributed and reviewed. Manage and rotate agent credentials carefully and avoid embedding them in prompts or code. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Core Zero Trust Principles | Agentic coding benefits from continuous verification and explicit authorization per action |
| Recommendation — Verify each agent action rather than trusting the development environment by default. | ||
| OWASP ASVS | V13 — Configuration | Agentic coding often changes build and runtime configuration as well as source code |
| Recommendation — Review configuration changes with the same rigor as code changes. | ||
Practitioner Guidance
Why practitioners should care: Agentic coding should be evaluated as a privileged workflow, not a generic productivity feature. The key design question is whether the agent can act only within a narrowly defined task envelope and whether every meaningful action can be traced back to an accountable human or policy decision.
Common misunderstanding: Teams often assume that prompt quality alone is enough to make agentic coding safe. In practice, safety depends more on access scope, approval gates, logging, and secret handling than on prompt wording.
Practitioner takeaway: If the agent can write code, it can also create security change, so govern it with the same discipline you would apply to any other automation that can modify production-adjacent assets.