What breaks when agentic AI can generate and run code at runtime?

Where runtime code generation breaks the traditional control model

Once an agent can write and execute code during live work, the security question moves from “was this commit reviewed?” to “what authority did the runtime action inherit, and from where did the execution instruction come?” That shift matters because the code path may be ephemeral, context-driven, and outside normal software release gates. The core control point becomes runtime governance, not just code review.

That is why the distinction between a chatbot and an agentic system matters operationally, not just conceptually. AI Agents vs Agentic AI helps frame where autonomy starts to change the risk profile, and Agentic AI Security Guide shows why inputs, tools, orchestration and identity become inseparable once the system can act, not just suggest.

The practical breakage is that approval now has to cover more than source code. Runtime code may be produced from prompts, memory, retrieved context, or tool output, which means the security boundary includes the data sources that shape execution, the toolchain that runs it, and the permissions attached to the actor that triggers it. Static review can still reduce risk, but it no longer gives a complete picture of what the system may do in production.

Why runtime code creation changes trust, privilege, and blast radius

When code is generated on demand, the risk shifts toward delegated authority and short-lived execution paths. The agent may not need a permanent commit, but it still needs a principal, a permission set, and a way to reach sensitive tools or environments. If those permissions are broad, the resulting blast radius can exceed what any reviewer would have accepted for a normal code change.

This is also where agent identity becomes a governance issue, not a naming issue. Agentic AI Identity Guide is relevant because runtime execution depends on how the agent is registered, authenticated, delegated, and retired, while AI Agent Authorisation Guide is the practical control lens for task-scoped access, per-action decisions, and human approval where the action is materially sensitive.

Code generation also creates a trust problem across the full chain of context, execution, and attribution. If the runtime instruction is assembled from hidden prompts, retrieved documents, or prior agent state, teams can lose sight of which input caused the action and whether that input should have been trusted at all. In that model, security failures often look less like a bad commit and more like an over-authorised system following a poisoned or unreviewed execution path.

AI Coding Agents Security Guide is directly relevant because it addresses secrets in context, over-scoped tokens, sandboxing, and agent-authored changes, while AI Agent Observability, Audit and Incident Response Guide matters because runtime execution only stays governable if you can attribute actions, detect anomalies, and revoke access quickly.

What teams should change in build, runtime, and governance

The operating model should treat runtime code generation as a controlled capability, not a productivity side effect. That means separating where code is proposed, where it is executed, and who can authorize the execution. It also means deciding which contexts may trigger execution, because the trigger itself can be as dangerous as the generated code.

For teams that already manage strong identity and access controls, the next step is to extend those controls to the agent’s action layer. Zero Trust for AI Agents supports the idea of verifying the principal and the request at each action, while Agentic AI Compliance Guide is useful where audit evidence, oversight, and accountability need to be demonstrated to governance or regulatory stakeholders.

Practically, teams need a runtime control stack that can answer four questions: who or what requested execution, what context shaped the generated code, what authority was used, and what resource was touched. If any of those answers are unclear, the system is already outside a defensible approval model. The safest pattern is to make execution bounded, observable, and revocable, rather than assuming that source-level checks are enough.

Agentic systems can still be useful when they are allowed to create code, but the organisation has to stop treating code review as the final gate. The real control objective is to keep runtime authority smaller than development freedom, and to ensure the system cannot silently convert context into production-impacting action.

Risk and Threat Considerations

Runtime code generation expands the attack surface because a malicious prompt, poisoned context source, or overly broad tool permission can turn an autonomous workflow into an execution path with real privileges. The highest risk is not merely bad code, but code that is produced and run before normal review, logging, or segregation controls can intervene.

Failure mechanism: An attacker, or even an untrusted context source, influences the agent’s runtime decision so that it writes code with access to secrets, files, APIs, or infrastructure, then executes it under inherited permissions. That bypasses the normal assumption that dangerous logic appears first in a reviewed change set.

Impact: The likely outcome is unauthorized data access, privilege abuse, supply chain contamination, or lateral movement through systems that trusted the agent’s runtime authority. If execution is not tightly scoped and logged, teams may detect the damage after the code has already acted.

Practitioner Guidance

What to verify: Verify that the agent cannot execute code unless the request, the context source, and the target environment are all explicitly authorized for that action. If any one of those is implicit, the control model is weaker than it looks.

Decision rule: If the generated code can reach production data, external APIs, or privileged system functions, require per-action authorization, sandboxing, and fast revocation paths before you allow autonomy to increase.

Common mistake: Treating code review as the main control when the real risk is runtime execution under inherited authority. Review still matters, but it cannot be the only gate once code is generated on demand.

Practitioner takeaway: The key question is no longer whether the code was reviewed, but whether the agent was ever allowed to act with more authority than the organisation can observe, justify, and immediately withdraw.

Related resources from NHI Mgmt Group

• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern machine identity credentials in agentic AI environments?
• What breaks when AI assistant skills can run code before the model sees the prompt?
• What breaks when runtime guardrails are missing from agentic AI?