AI-generated code is forcing AppSec to become runtime governance

At a glance

What this is: This is a panel-based analysis of how AI-generated code and disposable agents are changing AppSec, with the key finding that security controls must move from review gates to runtime governance.

Why it matters: It matters because IAM, PAM, and security architects now have to govern machine-created software paths, agent identities, and ephemeral permissions in the same control plane as human access.

By the numbers:

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

👉 Read LEGIT Security's RSAC 2026 panel analysis on AI-generated code and AppSec governance

Context

AI-generated code is changing the AppSec control point because the old assumption of a bounded developer population no longer holds. When anyone can assemble usable software or agents in minutes, security cannot rely on training, review queues, or approval gates that were designed for slower release cycles. The primary governance problem is now how to secure code, agents, and permissions at the moment they are created, not after deployment.

This is also an identity problem, not just a development problem. Agents need scoped permissions, traceable identities, and lifecycle controls in the same way that service accounts and workloads do, otherwise they become hard-to-inventory non-human identities with unclear ownership. That makes the article especially relevant to IAM, PAM, and NHI programmes that are already dealing with sprawl and weak runtime visibility.

Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: Who is accountable when an AI agent causes a security incident?

A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.

Technical breakdown

Why developer-centric AppSec breaks down with AI-generated code

Traditional AppSec assumes a human developer writes code, submits it, and waits for review, scanning, and approval. AI-generated code shortens that loop dramatically and can create something production-adjacent before normal controls engage. The failure is not only speed. It is the collapse of the review window that made static controls effective. Once software becomes disposable and agent-created, the system needs policy embedded in the workflow, not a checkpoint after the fact.

Practical implication: move security controls upstream into the creation workflow and stop relying on post-hoc review to catch AI-produced code.

Agent identity and permissions management at creation time

An AI agent that can take actions independently is not just software, it is a governed runtime entity with an identity and a permissions boundary. If that identity is assigned after creation, the organisation has already lost the chance to constrain what the agent can touch. Structural controls mean defining allowed tools, data scopes, and permission ceilings at provisioning time, then binding those constraints to the agent throughout its life cycle. This is where NHI governance and IAM converge.

Practical implication: treat every agent as a non-human identity with explicit birth, scope, and offboarding controls.

Telemetry and traceability for disposable agents

Incident response breaks when the actor disappears before investigators can reconstruct its actions. Disposable agents require logs, traces, and identity correlation that preserve who or what did what, when, and under which policy decision. Without that, security teams cannot separate legitimate automation from rogue behaviour or determine whether an action was authorised. This is a governance gap, not just a logging gap, because traceability must be designed into the control plane from the start.

Practical implication: instrument agent activity with identity-linked telemetry before production use, not after the first investigation.

Threat narrative

Attacker objective: The objective is to use trusted automation or mis-scoped agent behaviour to reach data, systems, or actions that should have remained out of scope.

1. Entry occurs when a user or team creates AI-generated software or an agent inside normal development workflows, bypassing the slower human review model.
2. Escalation happens when the agent receives broader tools or permissions than its immediate task requires, allowing actions beyond the original intent.
3. Impact follows when a rogue or mis-scoped agent accesses data, takes unauthorised actions, or leaves no reliable trace for incident reconstruction.

NHI Mgmt Group analysis

AI-generated software is turning AppSec into a runtime identity problem: once code and agents can be created in minutes, the old assumption that security can review work before it matters stops being reliable. That means the real control point shifts to identity, permission scope, and policy enforcement at creation time. In practical terms, this is where NHI governance becomes part of AppSec rather than a separate discipline.

Disposable agents create control debt faster than traditional review models can repay it: security teams built scan-and-approve workflows for assets that would exist long enough to inspect. Agentic systems can be created, used, and discarded inside a single business cycle, which means lifecycle controls matter more than manual gates. Practitioners should treat short-lived agent identity as a first-class governance object.

Telemetry is now a prerequisite for trust, not an afterthought: if an agent can act and then disappear, the organisation needs identity-linked traces that survive the workload. Without that, incident response becomes speculative and accountability weakens across both AppSec and IAM. The named concept here is traceability debt, and it will become a defining failure mode for agentic environments.

Security that cannot operate at production speed will be bypassed: the warehouse analogy from the panel is accurate because modern AI workflows do not tolerate manual checkpointing. That does not eliminate governance, but it changes the design requirement from stopping flow to constraining flow. Teams should expect policy-as-code, agent-scoped privilege, and continuous verification to become baseline expectations.

Human skill shifts do not remove the need for control, they raise the bar for orchestration: as execution becomes cheaper, the differentiator becomes structured decision-making, context-setting, and control design. For identity programmes, that means stronger ownership models, clearer agent accountability, and tighter integration between AppSec, IAM, and SOC functions. The organisations that adapt will make security part of the operating model, not a separate review lane.

What this signals

AppSec teams should expect the control plane to move closer to IAM and PAM as AI-generated software becomes normal. The practical question is no longer whether people can write code faster, but whether the organisation can govern the identities, permissions, and traces created by that speed. Traceability debt: the gap between agent action and investigator visibility will become a major operational risk unless logging is designed around identity from the start.

Security leaders should also revisit whether their current approval culture is fit for disposable workloads. When an agent can create, act, and vanish quickly, the organisation needs controls that operate in real time rather than process queues that assume delayed execution. That change aligns naturally with policy-as-code and with standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Define agent identity at creation time Assign every AI agent a unique identity, explicit owner, and scoped permission set before it can access tools or data. Link that identity to lifecycle controls so access can be revoked, reviewed, and investigated like any other non-human identity.
• Replace manual gates with policy embedded in workflows Move approval logic, data access boundaries, and tool restrictions into the development and runtime workflow so they execute automatically at the point of action. Review queues alone will not keep up with disposable code or short-lived agents.
• Instrument agent telemetry for incident reconstruction Capture identity-linked logs, traces, and policy decisions for every agent action, including tool calls and data access. Retain enough context to reconstruct what happened after the agent is gone.
• Set explicit guardrails for agent-class capabilities Define what an agent may not do as clearly as what it may do, especially for privileged actions, external calls, and data movement. Use the smallest viable permission envelope for each agent class.
• Align AppSec, IAM, and SOC on rogue-agent response Build a shared response path for cases where an agent behaves outside policy, including containment, trace review, and identity revocation. The team should know how to respond before the first suspicious action completes.

Key takeaways

• AI-generated code is forcing AppSec away from delayed review and toward runtime governance of identities, permissions, and traces.
• Disposable agents create a traceability gap that traditional control gates were never designed to close.
• The practical response is to make security a built-in workflow control, with agent identity and lifecycle rules defined before production use.

Key terms

• 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.
• Traceability Debt: Traceability debt is the accumulated inability to reconstruct where data went, who accessed it, and how it was used across a fragmented environment. It becomes a governance problem when teams cannot answer privacy, audit, or incident questions quickly enough to meet regulatory obligations.
• Disposable Code: Software or agent-created artefacts that exist only briefly and may never be reviewed by a human before use. The risk is not just speed, but the loss of time-based assumptions that traditional scanning, approval, and remediation processes depend on.
• Agent-Class Guardrails: Policy rules that define what a category of AI agents may and may not do, based on task risk, data sensitivity, and privilege requirements. These guardrails are more effective when enforced automatically in the runtime environment rather than by manual review.

What's in the full article

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

• Panel context from RSAC 2026, including how the speakers framed agentic AppSec and organisational readiness
• Specific examples of teams shipping agents in days and the governance lessons those leaders drew from that experience
• The incident response questions raised by rogue-agent investigations, including telemetry and traceability concerns
• The panel's closing disagreements on workforce impact and which skills will matter most as execution becomes cheaper

👉 The full LEGIT Security post expands on agent telemetry, incident response gaps, and the shift from review gates to runtime control.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners who need to connect identity controls to modern application and agent workflows.