Agentic development needs security that follows the work in real time

At a glance

What this is: This is a blog on securing agentic development, with the key finding that traditional SDLC security checkpoints break down when coding agents compress work into fast, continuous sessions.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly need governance over agent-driven workflows, telemetry, and auditability, not just human developer access and static review gates.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Seezo's analysis of security for agentic development workflows

Context

Agentic development changes the security problem because the software lifecycle is no longer neatly divided into design, coding, review, and test. When an AI coding agent carries context across those stages inside a single session, traditional checkpoint-based security loses timing, and the first priority becomes governance of the workflow itself, not just the code artifact.

That shift has an identity dimension as well. The agent, the developer, and the automation surfaces around pull requests and CI all need traceability, access boundaries, and auditable policy enforcement. For IAM and NHI programmes, the question is whether security controls can follow delegated action and preserve accountability when the work is happening continuously rather than in discrete handoffs.

Key questions

Q: How should security teams control AI-assisted coding without slowing developers down?

A: Put policy into the IDE so security guidance appears during code creation, not after commit. Teams should use safe defaults, prompt shaping, and low-friction remediation paths. The goal is to reduce insecure output while preserving developer flow, because delayed controls create rework and encourage bypasses.

Q: Why do traditional SDLC checkpoints struggle with agentic development?

A: They assume time between stages, but agentic workflows compress design, build, and test into short loops. By the time a point-in-time review closes, the context may already have changed. Security teams need controls that operate continuously, not just at the next formal gate.

Q: What do teams get wrong about securing AI coding assistants?

A: Teams often focus on code output and ignore the agent boundary, where file reads, tool outputs, and external content shape the next action. That misses the real control point. The right question is whether untrusted input can influence privileged behaviour before the code is even written or committed.

Q: Who is accountable when an AI agent makes the wrong change?

A: Accountability sits with the governance chain that approved the access model, not with the agent alone. Teams need a trace from requester to policy decision to identity issuance to action results. If that chain is missing, incident review becomes guesswork and access governance cannot be defended to auditors.

Technical breakdown

Why static SDLC security gates fail in agentic workflows

Traditional secure development assumes a linear lifecycle with clear pauses between design, implementation, review, and release. Agentic development compresses those pauses, which makes point-in-time approvals stale almost immediately. Static artifacts such as design documents or backlog tickets cannot fully represent the live context an AI coding agent is using as it moves between tasks. That creates a control gap: security knowledge exists, but it is no longer synchronised with the moment of execution. The result is not just faster development, but faster drift between intent and implementation.

Practical implication: move controls closer to runtime workflow events, not just pre-commit or pre-merge checkpoints.

Security context as live workflow input

The useful model is not a one-time gate, but continuous security context that can be injected where developers and agents are already working. In practice, that means policy, standards, and architectural constraints are available inside the coding environment so the agent can reference them while generating or changing code. This is closer to contextual governance than classic review. The security function becomes part of the working memory of the session, which matters because agent decisions are made over short cycles and can change as new information appears.

Practical implication: structure security requirements so they are machine-readable, task-scoped, and reusable inside developer tooling.

Telemetry and auditability inside coding agents

If coding agents are making or influencing changes, the organisation needs evidence of what was invoked, when it ran, on which branch, and whether resulting requirements were honoured. That is an identity and governance problem as much as a code quality problem, because auditors and security teams need traceability across delegated actions. In effect, the agent workflow becomes a governed execution surface. Without that telemetry, security loses the chain of custody between policy, assessment, implementation, and release.

Practical implication: require branch-level audit trails that connect agent activity, security review outcomes, and implementation validation.

NHI Mgmt Group analysis

Agentic development is creating a governance gap, not just a tooling gap. The issue is not that security teams lack controls, but that their controls were designed for a slower lifecycle with human handoffs. When design and implementation collapse into one session, review logic built around waiting for a later stage no longer matches the pace of change. Practitioners should treat agentic development as a workflow governance problem first and a code scanning problem second.

Developer-facing security must become context-aware to remain effective. Security guidance that sits outside the development environment is increasingly too late to influence the decision being made. The stronger pattern is to deliver policy, architectural constraints, and validation signals inside the same workflow as the coding agent. That aligns with the identity principle that control must travel with the subject of the action, which in this case is the developer-agent session.

Telemetry is becoming the minimum viable control for agent-driven software change. If teams cannot see what an agent did, who invoked it, and whether the resulting requirements were carried through to implementation, governance collapses into trust. This is where the identity bridge matters: agent sessions need accountability similar to privileged human actions, even if the actor is a software system. Practitioners should insist on branch-level traceability and audit-ready records.

Persistent security requirements are the right answer to short-lived development cycles. A requirement that dies at the end of a conversation is not a control, it is a note. Persisting reviewed requirements into implementation closes the loop between design intent and delivered code. That pattern helps security keep pace with AI-assisted development while preserving the governance expected in regulated environments.

Named concept: security-following development. This is the shift from placing controls at lifecycle seams to embedding them into the live execution path of agentic development. The concept matters because it reframes security from a checkpoint function into a continuously available governance layer. Teams that adopt this model will be better positioned to audit, validate, and constrain agent-driven change.

What this signals

Agentic development will push more security decisions into runtime workflows, which means teams need controls that are observable inside the development environment rather than bolted onto the edge of it. The practical shift is toward governed sessions, durable requirements, and traceable approvals that can survive the pace of AI-assisted change.

Session-bound governance: security teams should start treating AI coding sessions as a controlled execution surface. That means aligning developer tooling with auditability, branching discipline, and identity-aware oversight, so delegated action can still be reviewed and attributed after the fact.

For practitioners

• Embed security context inside the developer workflow Provide policy, standards, and architectural constraints directly in the coding environment so AI agents and developers can reference them during task execution. This reduces the gap between security intent and the moment of code generation.
• Persist reviewed requirements beyond the session Treat security review output as durable governance data that survives the conversation, branch switch, or tool handoff. Requirements should travel into implementation and remain testable later in pull request validation or CI.
• Instrument agent activity with branch-level telemetry Log what skills or tools were invoked, by whom, on which branch, and whether the implementation honoured the resulting requirements. Use that evidence for audit, exception handling, and incident investigation.
• Validate implementation against approved design decisions Run checks that compare the final code or configuration against the security requirements that were approved earlier. Focus on whether the implementation still matches the reviewed intent, not just whether a scanner found a known pattern.

Key takeaways

• Agentic development breaks the old assumption that security can wait for lifecycle handoffs.
• Governance now depends on whether teams can preserve context, trace actions, and validate requirements inside the coding workflow.
• Identity and audit controls become central when AI agents participate in software change at session speed.

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.
• Workflow telemetry: Structured evidence about what happened inside a development or automation workflow, including who invoked a tool, what branch was affected, and whether policy outcomes were met. It is the basis for auditability when humans and agents share the same change path.
• Persistent security requirements: Security requirements that survive beyond a single review session and remain attached to the code or change until implementation is complete. This matters because short-lived agent sessions can otherwise sever the link between approved intent and delivered behaviour.
• Context-aware security assistant: A context-aware security assistant is a system that answers operational questions by combining live telemetry, audit data, and configuration state. It is not a control by itself. Its value comes from preserving evidence provenance so practitioners can verify why a response was produced and whether the underlying data is current.

What's in the full article

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

• How the workflow maps security context into the coding environment as work is happening.
• How persistent requirements are carried from design review into implementation and CI validation.
• How branch-level telemetry records which skills were invoked, when they ran, and whether requirements were honoured.
• How regulated teams can use the system of record for audit visibility into agent-driven change.

👉 Seezo's full post covers workflow telemetry, persistent requirements, and implementation validation details.

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. It helps security and identity practitioners build the control foundations needed for delegated, automated, and agent-driven environments.