AI coding agents need security controls at generation time

At a glance

What this is: This is an analysis of why AI coding agents create a new application security layer, with the key finding that security has to start at generation time, not after code is committed.

Why it matters: It matters because agentic development widens the identity and access perimeter around developer tools, making prompt injection, MCP trust, and secret exposure part of IAM, NHI, and AppSec governance.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read LEGIT Security's analysis of AI coding agent security and generation-time controls

Context

AI coding agents blur the line between code assistant and privileged runtime actor. Once an agent can read files, browse the web, execute commands, call APIs, and install packages, it becomes part of the application security trust boundary rather than a passive productivity tool. The real problem is not code generation alone, but the combination of broad access, weak oversight, and content that can be manipulated through prompt injection or untrusted context.

For identity and access teams, the issue is that agentic development creates a new class of software-mediated access that behaves like a non-human identity in practice. MCP connections, developer credentials, repository permissions, and terminal access all need the same lifecycle discipline that organisations apply to service accounts and other NHI. In this article's framing, the starting position is typical of the market: controls lag behind usage, and security is still bolted on after the code exists.

Key questions

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: Why do AI coding agents change AppSec and IAM governance at the same time?

A: Because the agent is both producing code and exercising access. That means code security, secret management, and delegated tool use are no longer separate concerns. Once the agent can act inside development workflows, its permissions, context, and audit trail need the same lifecycle discipline used for other non-human identities.

Q: What do organisations get wrong about scanning AI-generated code?

A: The common mistake is treating more scanning as a complete answer. In reality, high-volume findings create noise unless teams can prioritise exploitability, exposure, and business impact. Organisations also miss the governance layer, where AI tools and agents need ownership, permission boundaries, and auditable actions.

Q: How should teams govern AI-assisted development workflows that use coding agents?

A: Treat them as identity-governed execution paths, not just productivity tools. Define who can start the workflow, which tools and data sources it can reach, what evidence is required for review, and how access is revoked if the workflow expands beyond its intended scope. The key is to govern the chain of delegated action, not only the final code output.

Technical breakdown

Prompt injection in coding agents

Prompt injection works by embedding malicious instructions in content the agent consumes, such as README files, web pages, API responses, or issue text. Because coding agents are built to follow context rather than to reason about trust, they may treat attacker-controlled content as valid instruction. That can lead to secret extraction, code changes, or destructive actions. The security problem is not only model weakness, but the absence of a trusted context layer that separates intent from untrusted data.

Practical implication: teams need controls that inspect and constrain agent context before instructions are executed.

MCP server trust and tool abuse

Model Context Protocol extends an agent's reach into external tools and data sources, but every connected server becomes part of the agent's trust chain. If a server is malicious, compromised, or simply unvetted, it can influence outputs, exfiltrate data, or push the agent toward unsafe actions. In identity terms, MCP is a delegation problem: the agent inherits capability from external systems without a mature equivalent of tool-level privilege governance.

Practical implication: organisations should inventory and govern MCP connections as if they were privileged integrations.

Generation-time scanning versus post-commit scanning

Traditional AppSec assumes the risky code appears first and is reviewed later. AI-assisted development breaks that sequence because insecure dependencies, hardcoded secrets, and vulnerable patterns can appear at machine speed across many files before a review queue ever sees them. Generation-time scanning inserts policy and detection into the moment code is created, which changes the control point from retrospective inspection to inline prevention and fast feedback.

Practical implication: shift AppSec control left again, but this time into the agent workflow itself.

Threat narrative

Attacker objective: The attacker wants to turn a trusted coding assistant into a conduit for code tampering, secret exposure, or destructive execution.

1. Entry occurs when a developer lets an AI coding agent consume files, web content, or external tool output inside a trusted development session.
2. Credential access follows when malicious context or an unsafe MCP server steers the agent toward secrets, tokens, or exposed environment variables.
3. Escalation happens as the agent uses its granted terminal, repository, or API access to make changes, install packages, or trigger unintended actions at machine speed.
4. Impact is insecure code, leaked secrets, or destructive changes reaching the development pipeline before conventional review controls can contain them.

NHI Mgmt Group analysis

AI coding agents are becoming software-mediated non-human identities, not just developer tools. Once an agent can browse, execute, and call external services, its access footprint needs lifecycle governance, bounded delegation, and auditability. That makes the IAM and NHI boundary relevant even in an AppSec article. Teams that treat agent sessions as ordinary developer activity will miss the control point where machine access is actually being exercised.

Prompt injection exposes a context trust gap, not just a model safety problem. The agent is often doing exactly what it was designed to do, but with attacker-controlled context. That means the failure is upstream of code review and downstream scanning. Security programmes need to distinguish trusted instructions from hostile content across files, web responses, and tool output, or the agent inherits the attacker’s intent.

Tool connections now need privilege governance. MCP servers and similar integrations are effectively delegated capabilities, which makes unvetted connections a control failure comparable to over-permissioned service accounts. The named concept here is agent context sprawl: too many untrusted inputs and tool paths feeding the same runtime decision loop. Practitioners should treat each integration as an access decision, not a convenience feature.

Generation-time AppSec is becoming the new control plane for AI-assisted development. If insecure patterns are allowed to propagate while code is being written, later scanning only confirms the damage. That changes the governance model from find-and-fix to prevent-and-constrain. Organisations that align AppSec, IAM, and developer workflow controls will be better positioned than teams relying on retrospective review alone.

The market is converging on policy enforcement inside the agent workflow. That reflects a broader shift in security architecture toward continuous control at the moment of action. For practitioners, the implication is straightforward: code security, secret handling, and agent access governance can no longer live in separate operating models. They need a shared policy layer and a shared audit trail.

What this signals

AI coding agents are starting to behave like governed identities embedded in developer tooling, which means the reader's programme will need shared ownership between AppSec, IAM, and platform engineering. The practical shift is toward policy at the point of action, not just after code lands in the repository.

Agent context sprawl: the more untrusted files, tools, and responses an agent can consume, the harder it becomes to reason about intent. That creates a governance problem similar to privilege creep, except the creep now happens in the agent's runtime context as well as its access rights.

Readers should expect tighter scrutiny of MCP trust, developer approvals, and inline scanning controls as agentic development matures. Programmes that cannot show who approved a tool, what the agent accessed, and what it changed will struggle to defend the control model.

For practitioners

• Inventory agent access paths Map every place coding agents can read files, execute commands, call APIs, and install packages. Treat each path as a delegated access point with an owner, an approval state, and a review cadence.
• Vet and restrict MCP connections Approve only known MCP servers, log every tool connection, and block unvetted endpoints before they can influence agent behaviour. Apply the same discipline you use for privileged integrations and service-account sprawl.
• Move secret and dependency checks into generation time Scan code as the agent writes it for hardcoded credentials, vulnerable dependencies, and unsafe patterns. Do not rely on post-commit review alone when machine-speed generation can spread the issue across many files.

Key takeaways

• AI coding agents expand the AppSec attack surface because they can execute actions, not just suggest code.
• The control gap is real, with most organisations still lacking complete visibility and policy coverage for agent behaviour.
• Security teams need generation-time enforcement, tool governance, and auditable agent access if they want AI-assisted development to remain shippable.

Key terms

• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Generation-Time Security: A control approach that inspects and constrains code while an AI agent is writing it, rather than waiting for post-commit review or CI scanning. It matters because AI-assisted development can create insecure patterns and secret exposure at machine speed, before traditional controls can respond.

What's in the full article

LEGIT Security's full research covers the operational detail this post intentionally leaves for the source:

• Concrete controls for MCP server analysis and blocking decisions inside AI coding workflows
• Real-time policy examples for Yolo mode, forbidden tools, and destructive action prevention
• Generation-time scanning coverage for secrets, SAST issues, and vulnerable dependencies
• Developer workflow visibility details across Claude Code, Cursor, and GitHub Copilot environments

👉 The full LEGIT Security post covers agent workflow visibility, MCP risk handling, and inline code scanning details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that supports modern identity and security programmes. It helps practitioners build the governance foundations needed for delegated access, auditability, and lifecycle control.