The agent's execution environment may include access to credentials, tokens, or capabilities that the agent's LLM-level permissions don't reflect. Generated code can exploit this gap — for example, reading a cloud metadata API endpoint (http://169.254.169.254/) to retrieve instance credentials, then using those credentials to call APIs the agent was never authorized to use at the application level.

This is particularly dangerous in cloud-hosted agent deployments where the execution environment runs with an IAM role that has broader permissions than the agent's application-level controls suggest.

A coding agent asked to implement a feature, fix a bug, or generate boilerplate code may — if its input is manipulated — generate code that appears to fulfill the task while also containing hidden functionality: a hardcoded admin credential, a web shell endpoint, a scheduled task that phones home, or a dependency on a malicious package.

Why this is subtle: The generated code compiles. It passes basic tests. It does what it was asked. The backdoor is hidden in logic that only activates under specific conditions, or in a dependency that looks legitimate. Without code review, it deploys to production and stays there.

This is the agentic version of a software supply chain attack — but instead of a compromised package, the attack enters through the agent's code generation output itself.

Code that recursively calls itself, spawns unbounded subprocesses, writes to disk in an infinite loop, or makes unlimited API calls can exhaust host resources — CPU, RAM, disk, or API quota — until services fail. An agent with no resource limits on its interpreter is capable of self-inflicted denial of service, whether from malicious input or from a naive implementation of a resource-intensive task.

Real pattern: Coding agents asked to "process all files" or "retry until successful" without explicit bounds have generated code that consumed available disk space or ran indefinitely — discovered only when the host became unresponsive.