Agentic development needs security that follows the work in real time

At a glance

What this is: Seezo says agentic development is breaking traditional SDLC security checkpoints because work now moves too quickly for static reviews and disconnected artifacts to stay current.

Why it matters: IAM, PAM and NHI teams should treat coding agents as governed runtime actors, because security context, validation and audit evidence now need to move with the work, not sit beside it.

Context

Agentic development collapses design, coding and testing into shorter, more continuous sessions, which makes traditional review gates less effective as control points. The security problem is not that controls disappear, but that they become detached from the work they are meant to govern. That creates a governance gap for both developer identity and the non-human identities or agent-like tools acting inside the workflow.

In this model, point-in-time approvals and static review notes age faster than the code itself. The article’s central claim is that security must travel with the session, preserving context, assessment results and validation evidence as the agent progresses. For regulated environments, the question shifts from whether reviews exist to whether they remain attached to the actual change path.

Key questions

Q: How should security teams govern autonomous coding agents in software delivery pipelines?

A: Treat the agent, its sandbox, and its tool access as a single governed execution path. Require per-run identity, scoped credentials, signed triggers, and human approval before merge. The key is not to stop automation, but to ensure every autonomous action has a bounded lifecycle, a clear owner, and an auditable trail from trigger to release.

Q: Why do static security reviews lose effectiveness in agentic development?

A: Because the control is applied to a moment that changes faster than the review cycle. When design, implementation and testing happen inside one compressed session, a point-in-time assessment can be stale before the next coding decision. The risk is not only missed issues, but governance evidence that no longer matches the actual change path.

Q: What are the signs that shadow AI is undermining SDLC security?

A: Look for code changes that cannot be traced to an approved model or assistant, pull requests that bypass normal scrutiny, and AI-generated changes appearing in repositories without owner attribution. If security teams cannot inventory the tools, models, and connected servers in use, they do not have visibility, only assumptions.

Q: Should organisations use the same controls for human-written and AI-generated code?

A: Yes. From a security and governance perspective, the code’s source matters less than the risk it introduces. Identity logic, secrets handling, and authorization checks should all pass the same review and testing standards regardless of who or what wrote them. That keeps release criteria consistent and prevents model output from becoming a special case.

Technical breakdown

Why static SDLC gates fail in agentic development

Traditional SDLC security assumes distinct handoffs between design, implementation, testing and release. AI coding agents compress those stages into a single operating session, which means a review written for one moment can be obsolete minutes later. Static artifacts such as threat models, design notes and checklists do not naturally follow the agent as context changes. The result is a control timing problem: the security decision is made in one state, but the code is produced in another. That is why the governance model has to move from stage-based sign-off to session-aware control.

Practical implication: move security decisions closer to runtime context and treat stage gates as insufficient on their own.

How session-aware security context changes the control model

A session-aware model keeps security standards, requirements and assessment output available while the developer and agent are still working. Instead of forcing the team to leave the workflow, the control becomes part of the working context and can adapt as the task evolves. This is materially different from simple scanning because it is designed to shape the work before implementation completes, not just detect issues after the fact. In identity terms, the coding agent becomes a governed runtime participant whose actions need traceability, context and bounded authority.

Practical implication: make security context available inside the agent workflow so controls influence decisions before code is finalized.

Why validation and telemetry matter after the assessment

The article separates assessment from validation, which is the right architectural distinction. Assessment establishes the security requirement, while validation checks whether the implementation actually honors that requirement in code or CI. Telemetry then gives security teams evidence about what skills were invoked, when they ran, on which branch and whether the resulting requirements were retained. That creates an audit trail for agent-driven development and a governance record for regulated organizations. Without telemetry, policy exists but enforcement cannot be demonstrated.

Practical implication: tie assessment, implementation validation and telemetry into one evidence chain for agent-assisted changes.

NHI Mgmt Group analysis

Static SDLC governance is becoming a timing problem, not just a tooling problem. When AI coding agents compress multiple lifecycle stages into one session, the old assumption that a review can wait until the next checkpoint stops holding. That weakens security governance even when the formal process still exists. The practitioner conclusion is clear: control timing has to be redesigned around session velocity, not calendar-based workflow.

Agentic development creates a new governance boundary around the coding session itself. The meaningful control point is no longer only the pull request or the build, but the live interaction between developer, agent, security context and validation output. That is where identity governance starts to matter, because the agent is operating as a runtime actor with access to security standards and implementation paths. Practitioners should treat that session as the unit of control.

Security context needs a named concept here: workflow-attached security. This is the idea that assessment, requirements and validation must remain attached to the work as it moves across design, implementation and CI. The article shows why detached artifacts are too fragile in fast-moving AI-assisted development. Practitioners should favour controls that preserve continuity of evidence, not just point-in-time approval.

Telemetry is now a governance requirement, not a nice-to-have observability layer. If teams cannot see which agent skills were invoked, when they were run and whether the implementation honored the requirement, they lose both operational control and auditability. That matters for regulated environments and for identity security programmes that need to prove who or what changed the software path. The practitioner conclusion is to make evidence capture part of the control design.

This development validates a broader shift from after-the-fact assurance to in-flow assurance. Security teams do not have to choose between governance and developer velocity if the controls are embedded where the work is already happening. The challenge is not just technical integration, but governance design that can survive much faster change cycles. Practitioners should reframe secure development around continuous assurance inside the workflow.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Workflow-attached security: agentic development needs controls that remain bound to the task as context shifts from design to implementation to validation. Static approvals and disconnected artifacts are losing practical value, so practitioners should align governance to the live session rather than the calendar.

If AI coding agents are already changing the development path, then auditability has to include the agent action chain as well as the final code. Security teams should expect evidence of who or what invoked the change, what context it used, and whether the requirements survived into implementation.

For practitioners

• Embed security context inside agent workflows Provide standards, design constraints and task-specific security guidance directly in the coding environment so the agent can reference them while work is still in progress.
• Separate assessment from validation Use a distinct review step to define security requirements, then validate the implementation against those requirements in the pull request or CI pipeline.
• Track agent activity as governance evidence Record which skills were invoked, when they ran, on which branch they executed and whether the resulting requirements were honored in code.
• Design for continuous assurance, not stage gates Treat design review, implementation review and release evidence as one continuous control chain so security does not disappear between lifecycle transitions.

Key takeaways

• AI coding agents compress SDLC stages so quickly that static security gates can become outdated before the work is finished.
• The core governance challenge is to keep requirements, validation and audit evidence attached to the live workflow instead of the old lifecycle seam.
• Practitioners need session-aware controls, continuous validation and agent telemetry if they want security to keep pace with agentic development.

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.
• Session-Aware Controls: Session-aware controls are policies that evaluate the live context of a user’s authenticated session before allowing data movement or interaction. They combine identity, application, and content context so enforcement can be more precise than blanket device-level rules. This is increasingly important in SaaS-heavy work environments.
• Workflow-embedded Security: A control pattern in which security decisions happen inside the system where work already occurs, rather than in a separate review layer. It is used to lower friction, improve adoption, and make the secure action the easiest action for engineering teams.
• Policy Validation: Policy validation is the pre-deployment inspection of access rules to catch overly broad or malformed permissions before they enter production. In NHI and IAM practice, it is a preventive control that shifts security left and reduces the creation of durable exposure.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and workload identity in practical terms. It helps practitioners design controls that match how modern systems actually operate.