TL;DR: Security leaders at RSAC 2026 argued that AI is collapsing the old developer-centric AppSec model, because employees can now create production-like software and disposable agents at speed, according to LEGIT Security. The practical shift is from training and gates to structural control of agent identity, permissions, telemetry, and policy enforcement inside the workflow.
At a glance
What this is: AI-generated code and disposable agents are pushing AppSec away from developer training and static review gates toward runtime control of identity, permissions, telemetry, and policy.
Why it matters: This matters because identity and access decisions now have to be enforced at creation and execution time, not after software or agents have already moved on.
Context
AI-generated code changes the security problem from governing a known set of developers and applications to governing fast-moving creation workflows that may only exist briefly. Traditional AppSec models assume code can be reviewed, scanned, approved, and revisited over time, but that assumption weakens when employees can create near-production software in minutes and agents can appear and disappear within a single week.
The governance gap is especially relevant to identity security because the control point is moving into the workflow itself. When software is produced by agents and assistants rather than only by human developers, security has to treat identity, permissions, and traceability as runtime properties, not as after-the-fact review artefacts.
Key questions
Q: What breaks when AI-generated code is treated like normal developer output?
A: Teams can miss insecure patterns, risky dependencies, and hidden assumptions because the review process assumes human authorship. That creates a governance gap where plausible-looking code moves forward with too little scrutiny. The fix is to treat generated code as untrusted until it passes automated testing, dependency review, and explicit human approval.
Q: Why do disposable agents increase risk in AppSec programmes?
A: They compress the time available to detect misuse, so a permissioning mistake can be exercised and forgotten before a review cycle catches it. That raises the importance of minimal privilege, agent ownership, and traceable execution records. Without those controls, incident response may know an action occurred but not who or what performed it.
Q: How should security teams govern AI-generated code in production pipelines?
A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.
Q: What should incident response teams do when an AI agent may have acted outside policy?
A: They should prioritise reconstruction over assumptions. If the agent may already be gone, responders need logs that identify the agent instance, its permissions, the tools it used, and the resources it touched. That evidence determines whether the event can be contained, explained, and audited with confidence.
Technical breakdown
Why disposable code breaks static AppSec controls
Static AppSec controls assume software has a durable lifecycle. Scans, code review, and approval gates work best when code persists long enough for a security team to inspect it, prioritize defects, and remediate later. AI-generated code and short-lived agents change that timing. If a workload exists for hours or days rather than weeks, the control cannot rely on periodic inspection alone. The practical problem is not just code quality, but governance latency: the control arrives after the software has already executed, branched, or disappeared.
Practical implication: Move controls earlier in the workflow and validate them at creation time, not only in scheduled review cycles.
Agent identity and permissions have to be structural
An AI agent is not just another script. It is a software entity that can act within a workflow, invoke tools, and carry permissions across tasks. That makes identity and authorization the real control plane. If permissions are assigned informally or managed after deployment, the agent can already have done damage by the time a team notices. Structural governance means identity, scope, and access boundaries are defined where the agent is created, with traceable ownership and explicit limits on what it can touch.
Practical implication: Bind each agent to a scoped identity, minimal privileges, and clear ownership before it is allowed to operate.
Telemetry becomes the basis for incident reconstruction
When an agent acts independently, incident response needs traceability that goes beyond traditional application logs. Teams need to know what the agent did, what tools it called, what data it touched, and whether that behaviour was within policy. Without telemetry designed for agent activity, responders may know that something happened but not reconstruct the decision chain well enough to contain it confidently. This is an identity and governance problem as much as a detection problem, because the runtime record must connect action back to the agent instance and its permissions.
Practical implication: Instrument agent activity with traceable event logs and decision records that support post-incident reconstruction.
NHI Mgmt Group analysis
Runtime governance is becoming the new AppSec boundary: when code is generated and executed faster than review cycles can keep up, the security model has to move from pre-deployment approval to in-workflow control. The old assumption was that developers were the primary control point. That assumption no longer holds in environments where any employee can create software or an agent quickly. Practitioners should treat the workflow itself as the control surface.
Agent identity is now an application security issue, not just an IAM concern: once software can act on its own inside production workflows, permissions management becomes part of AppSec architecture. That creates a direct bridge between application security, NHI governance, and privilege design. The field should stop treating agent identity as a side topic and start treating it as the mechanism that makes runtime enforcement possible.
Disposable systems create governance debt: if a workload or agent exists only briefly, controls built around periodic review, recertification, and later remediation lose effectiveness. This does not mean governance is impossible. It means the industry needs controls that attach to creation, execution, and telemetry rather than assuming a stable software object will still be there tomorrow. Practitioners should redesign for short-lived systems, not hope they behave like traditional applications.
Traceability becomes the deciding factor in AI-era response: the hardest question is no longer whether a security team can detect a bad event, but whether it can reconstruct what a transient agent did before it vanished. That raises the bar for auditability across the whole software lifecycle. Organisations should measure whether they can explain agent actions, not just whether they can observe system output.
What this signals
Runtime governance will matter more than developer education: the model has shifted from teaching every contributor to write secure code toward enforcing policy where code and agents are created, executed, and revoked. That makes traceability and issuance controls the practical centre of gravity for AppSec programmes.
AI-generated software exposes a governance gap between creation and review: the shorter the lifespan of code or an agent, the less value there is in controls that assume later inspection will be enough. Practitioners should watch for security processes that still depend on durable software lifecycles.
Agent identity is becoming the control surface for AI-era application risk: once an agent can act, the key question is no longer only what it did, but what it was allowed to do. Teams should prepare to align application security, IAM, and NHI governance around that runtime boundary.
For practitioners
- Define agent identity at creation Assign each AI agent a unique, scoped identity and ownership record before it can execute work. Tie that identity to explicit permissions, data boundaries, and a revocation path so the control exists at issuance, not after deployment.
- Move policy enforcement into the workflow Embed policy checks into the same systems that generate, approve, and run AI-created code. The goal is to enforce guardrails inside the workflow where the action happens, rather than relying on separate review gates that lag behind execution.
- Build telemetry for agent traceability Log which agent acted, which tools it used, what resources it accessed, and which policy decision applied. Preserve enough detail to reconstruct transient behaviour after the agent has already disappeared.
- Rework AppSec for short-lived software Treat disposable code and ephemeral agents as a different operating model from traditional applications. Replace assumptions about enduring codebases with controls that focus on creation-time authorization, runtime monitoring, and immediate containment.
- Test incident response against rogue agent scenarios Run incident exercises that assume the suspect workload may no longer exist by the time responders arrive. Validate whether teams can identify the agent, reconstruct its actions, and decide what evidence survives long enough for investigation.
Key takeaways
- AI-generated code and disposable agents undermine AppSec models that depend on durable code and delayed review.
- The practical control shift is toward runtime governance, where identity, permissions, and telemetry are enforced at creation and execution.
- Teams that can trace agent actions and constrain access structurally will be better positioned than those relying on training and approval gates alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on agents receiving or inheriting permissions without structural governance. |
| NHI-10 — Human Use of NHI | Employees are effectively creating and operating software through non-human identities and assistants. | |
| Recommendation — Scope every agent to least privilege before it can execute production actions. Govern agent-created software as NHI activity and bind it to owned identities and policy. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article’s core risk is uncontrolled agent identity and permission inheritance in production workflows. |
| Recommendation — Enforce explicit agent identity and permission boundaries before tool use begins. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Rogue agents acting with inherited access create credential and movement abuse potential. |
| Recommendation — Map agent misuse scenarios to credential access and lateral movement detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about moving access control into runtime governance for AI-created workloads. |
| Recommendation — Apply PR.AA-05 to ensure runtime permissions are explicit, minimal, and traceable. | ||
Key terms
- Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
- 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.
- 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.
- Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org