Unexpected code execution by agents

What it is

Many agents write code and run it as part of their work: analysis scripts, shell commands, database queries, configuration. Whatever reaches that execution path runs with the agent's privileges on whatever machine the agent occupies. The risk is unreviewed execution. Vulnerable code that a person accepts from an assistant and ships is a different risk, covered in insecure AI-generated code.

How it happens

• Content the agent reads contains text that ends up inside a command it runs.
• The agent installs a package to complete a task, and the package is hostile.
• Generated code deserialises or evaluates data it was given.
• The agent runs on a developer's workstation or a build server with broad access.

Why it matters

Code execution is the most general capability an attacker can obtain. From it follow credential theft, movement to other systems, destruction of data and persistent access. It is rated critical because the consequence is not limited to the agent's own task.

Warning signs

• Agents execute code outside an isolated environment.
• The execution environment can reach the internal network or the internet without restriction.
• Agent processes start child processes that no task explains.
• Packages are installed at run time.

Who owns it

Security architecture owns the isolation standard. Engineering owns each agent's execution environment. The owner of the platform the agent runs on is accountable for what that environment can reach.

In practice

A data analysis agent is asked to chart a spreadsheet received from a third party. A cell contains text that the agent incorporates into the script it writes, and the script reads the environment's access keys and posts them to an external site. The same pattern generalises to any agent that turns untrusted input into something executable.