Running an AI agent locally feels natural.

Your code is already on your machine. Your terminal is there. Your files are there. The agent can install packages, run tests, edit code, and help you move faster.

But this convenience also creates risk.

An AI agent is not just a chatbot when it can use tools. It may be able to read files, run shell commands, access environment variables, call network services, and modify a repository. If the agent misunderstands the task, follows a malicious instruction, or receives unsafe content from a file, the damage can happen in the same environment where you do your real work.

The problem is agency

OWASP lists "excessive agency" as one of the major risks for LLM applications. The idea is simple: when an AI system is given too many tools, too much permission, or too little oversight, small mistakes can become real actions.

For a local coding agent, that may mean editing the wrong file, running an unsafe command, exposing a token, or trusting instructions that were hidden inside a document or dependency.

Prompt injection is another risk. A malicious README, issue description, webpage, or data file can contain instructions that try to override what the user actually asked the agent to do.

Local machines are messy

Most personal development machines are not clean rooms.

They often contain SSH keys, API tokens, browser sessions, private notes, local databases, work projects, personal projects, and half-finished experiments. Even careful developers accumulate sensitive context over time.

If an agent runs with broad local access, it may be near more information than it needs.

That does not mean local agents are always bad. Local execution can be useful, especially for privacy, offline work, and fast iteration. But it should not be treated as automatically safe.

Cloud agents can be safer by default

A cloud environment is not safe just because it is in the cloud. It has to be designed well.

But a properly isolated cloud agent has advantages:

It can run in a fresh environment made for one task.
Access to repositories, secrets, and network domains can be scoped.
Logs and actions can be easier to audit.
The environment can be deleted after the task.
The user can review a pull request instead of letting changes land directly on a local machine.

This is why I think many agent workflows are better when they run in a controlled cloud container or virtual machine, with human review before merge.

The right rule is not "local or cloud"

The better rule is: run the agent where the permissions match the task.

If the task needs only one repository, the agent should not see your whole home folder. If the task does not need the internet, network access should be off. If the task needs secrets, those secrets should be scoped and temporary. If the task changes code, the result should be reviewed before it becomes part of the main branch.

Cloud execution makes this easier to enforce because the environment can be created around the task. Local execution often starts from the opposite direction: the agent begins near everything, and the user has to remember to restrict it.

A practical position

For quick local experiments, local agents are fine if you understand the risk.

For important repositories, client work, production systems, or machines with sensitive files, cloud execution is usually the better default. The agent should work inside a controlled environment, produce a diff, and let a human review the result.

AI agents are useful, but they are still software with permissions. Treat them that way.

Sources and further reading

OWASP Top 10 for LLM and Gen AI Apps, 2025: https://genai.owasp.org/llm-top-10/
NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
Anthropic Claude Code security guidance: https://code.claude.com/docs/en/security
OpenAI Codex cloud documentation: https://learn.chatgpt.com/docs/cloud

Keywords

#ai-agents, #ai-security, #cloud-agents, #local-ai, #developer-security

The hidden risk of running AI agents on your own machine