Agentic development lifecycle security is now an IAM problem

At a glance

What this is: Cycode argues that the agentic development lifecycle shifts software delivery to autonomous AI agents and exposes new risks around access, dependencies, and review.

Why it matters: This matters to IAM practitioners because agentic development turns code pipelines into identity-governed execution environments where agent permissions, secret exposure, and approval boundaries directly affect risk.

By the numbers:

• 100% of surveyed organisations confirmed they have AI-generated code in their codebases, while 81% have no visibility into how AI is used across the development lifecycle.
• Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024.
• A 2025 USENIX Security Symposium finding reported that roughly 20% of package references in AI-generated code pointed to packages that do not exist.

👉 Read Cycode's analysis of the agentic development lifecycle and its security risks

Context

Agentic development lifecycle security is about controlling what autonomous AI agents can do inside software delivery pipelines. The article’s core claim is that once agents can plan, code, test, and open pull requests, traditional review cadences and access assumptions no longer match the speed or scope of execution. This is a software delivery problem with a real identity layer, because the agents act through credentials, tool connections, and scoped permissions.

Cycode’s framing is useful because it separates agentic development from basic AI assistance. The distinction matters for IAM and PAM teams: an agent is not just a helper, it is an executing entity that can hold privileges, call tools, and touch code, secrets, and infrastructure. That makes lifecycle control, authorisation, and monitoring more important than simple prompt hygiene.

The starting position described in the article is increasingly typical rather than exceptional. Many enterprises already have AI-generated code in production paths, but far fewer can explain which agents, models, and connectors were involved in getting it there.

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 agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: How do organisations know if agentic identity controls are actually working?

A: They should look for auditable consent histories, fast revocation, accurate scope logging, and blocked-request telemetry that matches policy. If an agent can connect new tools without a review trail, or if revocation does not remove effective access quickly, the control model is failing even if authentication succeeds.

Q: What frameworks should teams use to assess agentic identity risk?

A: Teams should map agentic identity risk to OWASP-NHI for non-human identity controls, ZT-NIST-207 for zero-trust access boundaries, and NIST-CSF for governance and monitoring. Those frameworks help teams translate agent behaviour into ownership, access, detection, and response requirements without reducing the problem to a single tool decision.

Technical breakdown

How autonomous agents change the software delivery control plane

The ADLC keeps the same lifecycle stages as the SDLC, but it shifts execution from humans to agents. That matters because agents do not wait between steps, they chain planning, code generation, testing, and pull request creation in one session. The result is a control plane where access, tooling, and review all occur at machine speed. In practice, the security boundary is no longer the repository alone, but the agent, its credentials, and the external systems it can call. Practical implication: treat the agent runtime as a governed identity surface, not just a productivity feature.

Practical implication: define the agent’s execution boundary and authorise its tool access before it can touch repositories or deployment paths.

Secrets, dependencies, and prompt injection in agentic pipelines

Agentic pipelines create three common failure modes. First, secrets can leak through prompts, file reads, or generated code. Second, agents can select hallucinated or malicious dependencies because they act before a human validates package provenance. Third, prompt injection can be hidden in files, tickets, or tool descriptions that the agent reads as instructions. These are identity and supply chain problems combined, because the agent often acts with legitimate access while processing untrusted content. The control challenge is therefore not only detection, but also preventing untrusted inputs from influencing privileged actions. Practical implication: place policy enforcement at the point where the agent reads, reasons, and executes.

Practical implication: block secret exposure and untrusted tool inputs at the agent boundary, not after code or prompts have already propagated.

Why human review fails at machine speed

The article shows why review alone cannot protect agentic development. Agents can open pull requests faster than reviewers can read them, and they can keep iterating until tests pass even when the underlying logic remains insecure. That creates review fatigue and false confidence, especially when human approvers assume a passing test suite implies acceptable risk. Independent scanning is therefore essential, but it is not sufficient unless the agent’s permissions and outputs are also constrained. Practical implication: separate functional validation from security approval and reserve human review for privilege changes, architecture, and business logic.

Practical implication: gate merges on automated security checks and use human reviewers for high-impact access and design decisions only.

Threat narrative

Attacker objective: The attacker’s objective is to turn an agent’s legitimate development access into code injection, secret exposure, or supply chain compromise at scale.

1. Entry occurs when an attacker or malicious instruction reaches the agent through prompts, files, tickets, or tool metadata that the agent trusts.
2. Credential or dependency abuse follows when the agent uses real access to read secrets, fetch packages, or call tools on the attacker’s behalf.
3. Impact occurs when insecure code, exposed credentials, or malicious dependencies are merged into pipelines and replicated across repositories at machine speed.

NHI Mgmt Group analysis

Agentic development is becoming an identity governance problem, not just a DevSecOps problem. Once AI agents can execute across planning, coding, testing, and deployment, the meaningful control question becomes who or what is allowed to act inside the pipeline. That pushes IAM, PAM, and secret governance into the software factory itself. Practitioners should treat every agent as a governed non-human identity with explicit boundaries.

Machine-speed code creation creates a governance debt that most review models cannot absorb. The article’s core point is not simply that AI writes code faster, but that it changes the pace at which risk enters production. Traditional approval flows assume a human can inspect what changed before the next change arrives. In agentic development, that assumption fails, so the governance model must shift from batch review to continuous authorisation and telemetry.

Hallucinated dependencies are a supply chain risk amplified by agent autonomy. When an agent chooses packages on its own, it can introduce non-existent or malicious dependencies before any human checks provenance. This is where OWASP-NHI and software supply chain thinking intersect: the agent’s tool use and package selection are identity-governed actions, not just coding choices. Practitioners should assume dependency selection is an access decision as much as a build decision.

Prompt injection in development workflows is really privilege redirection. If an agent can be steered by text embedded in a repository, ticket, or tool description, the issue is not only content safety but delegated authority abuse. The agent is using legitimate credentials to carry out an attacker’s instruction. This makes OWASP Agentic AI Top 10 and MITRE ATLAS relevant, but the operational response sits with identity controls over tools, scope, and trust boundaries.

AI-generated code visibility will become a board-level assurance issue. Cycode’s numbers show a gap between usage and visibility that most security programmes cannot ignore. Without inventory of agents, models, connectors, and secrets, organisations cannot prove who touched code or whether the output was governed. Practitioners should expect ADLC governance to become part of audit evidence, not just engineering hygiene.

What this signals

Agentic development will force security teams to collapse the gap between identity governance and software delivery. The practical shift is from reviewing code after it exists to governing which agents can create it in the first place. That means live inventory, scoped authorisation, and auditability will matter as much as scanning. For practitioners, the next control gap is not code quality alone, but whether the pipeline can prove who or what acted at each step.

Non-human identity governance will become the deciding control for AI-driven build systems. Once agents can read prompts, select dependencies, and push changes, their privileges need the same lifecycle discipline applied to human access. This is where identity controls, secrets governance, and tool authorisation converge. Teams that can trace agent actions through the delivery chain will be able to manage risk; teams that cannot will be left with an unreviewable execution layer.

AI governance is moving from policy statements to operational evidence. Boards and auditors will increasingly ask not whether agentic development exists, but whether the organisation can show boundaries, approvals, and telemetry around it. That makes inventories, logs, and revocation paths part of governance maturity. The organisations that prepare now will find agentic development easier to control when adoption accelerates.

For practitioners

• Define each agent as a governed non-human identity Assign every coding or workflow agent a distinct identity, scoped permissions, and approved tool list. Tie those permissions to the repositories, models, and MCP connections the agent may use, then revoke anything not explicitly required.
• Enforce pre-commit controls at the point of generation Run secrets detection, dependency validation, and policy checks where the agent writes code, not only after pull request creation. Block commits that contain unknown packages, hardcoded credentials, or unapproved network calls.
• Separate functional success from security acceptance Do not treat passing agent-written tests as evidence of safety. Require independent SAST, SCA, and secrets scanning before merge, and route privilege changes or architecture changes to human approval.
• Inventory agent activity as part of IAM and audit Maintain a live record of which agents, models, and tool connections are active, what credentials they can access, and what actions they execute. Preserve that telemetry for investigation and compliance evidence.
• Constrain untrusted inputs before they reach privileged agents Treat repository text, tickets, and tool descriptions as untrusted input and filter them before the agent can act. That reduces prompt injection risk and limits the chance that an attacker can redirect legitimate authority.

Key takeaways

• Agentic development changes software delivery into a governed identity problem because autonomous agents act through real tools, credentials, and permissions.
• Cycode’s research points to a visibility gap that most enterprises are not yet equipped to close, which makes machine-speed review and access control a priority.
• Practitioners should focus on agent identity, pre-commit enforcement, and traceable approvals before allowing autonomous code generation into production pipelines.

Key terms

• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
• 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.

What's in the full article

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

• Stage-by-stage guidance for requirements, planning, coding, testing, deployment, and monitoring in the agentic development lifecycle
• Examples of AI guardrails, allowlists, and AIBOM workflows for agent governance
• Specific detection and response patterns for prompt injection, unsafe dependencies, and leaked secrets
• Cycode's platform mapping for visibility, governance, guardrails, and orchestration

👉 Cycode's full article covers the stage-by-stage controls, risk examples, and implementation guidance for securing agentic development.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to govern non-human actors. It helps security and identity teams apply lifecycle controls to the systems now operating inside software delivery.