Short answer: When a code assistant becomes an agent that reads repositories, runs commands, and calls tools, its biggest risk shifts from producing wrong code to taking unsafe actions. The OWASP Top 10 for LLM Applications (2025) names prompt injection, sensitive information disclosure, supply-chain weaknesses, improper output handling, and excessive agency among the leading risks. This checklist maps those categories to concrete controls—especially for teams running self-hosted agents.
A code-completion tool that suggests a wrong line is a productivity problem. A coding agent that reads an attacker-influenced issue, then runs a shell command with your credentials, is a security problem. The difference is autonomy plus tools, and it changes the threat model entirely.
The OWASP Top 10 for LLM Applications, updated for 2025, is the most widely referenced starting point for that model. Below, its categories are translated into the specific ways they appear in an AI coding agent, and the controls that address them.
Why coding agents change the threat model
A modern coding agent typically:
- ingests untrusted content—issue text, code comments, web pages, dependency READMEs;
- holds tools and permissions—a shell, Git access, network egress, package installation;
- runs with some autonomy—it can chain actions without a human approving each step.
That combination means a malicious instruction hidden in content the agent reads can become a malicious action. Securing the model output alone is not enough; you must constrain what the agent can do.
The 2025 OWASP LLM Top 10, applied to coding agents
| OWASP category (2025) | How it appears in a coding agent | Primary control |
|---|---|---|
| Prompt Injection (LLM01) | Hidden instructions in an issue, comment, or dependency redirect the agent | Constrain tools; require human approval for high-impact actions |
| Sensitive Information Disclosure (LLM02) | Source, secrets, or prompts sent to a model provider or logs | Egress control, secret redaction, scoped credentials |
| Supply Chain (LLM03) | Poisoned models, packages, or plugins enter the workflow | Pin and verify sources; use internal mirrors |
| Improper Output Handling (LLM05) | Generated code or commands executed without checks | Sandboxed execution and mandatory review gates |
| Excessive Agency (LLM06) | The agent has more permission or autonomy than the task needs | Least privilege and explicitly bounded task scope |
| System Prompt Leakage (LLM07) | Configuration or secrets embedded in prompts are exposed | Keep secrets out of prompts; assume prompts can leak |
OWASP periodically revises the list and its numbering. Confirm the current entries and definitions on the OWASP Gen AI Security Project before building a control matrix against them.
A control checklist for teams
Regardless of the tool, work through these before granting an agent access to real repositories:
- Trust boundary. Diagram where untrusted input enters and where the agent can act. Assume any content the agent reads may contain instructions.
- Least privilege. Give the agent the narrowest credentials, repositories, and network scope a task needs—nothing standing.
- Egress control. Know and restrict every outbound path: model endpoints, Git hosts, package registries, telemetry, logs.
- Secret hygiene. Keep credentials out of prompts and generated artifacts; rotate anything an agent could have observed.
- Sandbox and isolation. Run execution in disposable, resource-limited environments that cannot reach production by default.
- Human review gates. Require review before high-impact actions—merges, deployments, infrastructure changes, dependency additions.
- Logging and audit. Record tasks, tool calls, and outcomes so a surprising action can be investigated.
- Supply-chain verification. Pin model and package sources; validate integrity; prefer internal mirrors for air-gapped or regulated work.
- Model and data terms. Confirm what a provider retains, trains on, and where data is processed.
- Incident rehearsal. Test with non-sensitive code first, and practice revoking access and rolling back agent actions.
Where self-hosting helps—and where it does not
Self-hosting an agent platform gives an organization real control over egress, isolation, logging, and data residency. Those are exactly the levers several OWASP categories depend on, which is why self-hosted deployment is attractive for regulated and proprietary work.
But self-hosting does not by itself remove prompt injection or excessive agency. Those risks live in how the agent processes content and what tools it can call, not in where the server runs. A self-hosted agent with broad credentials and no review gate is still dangerous.
MonkeyCode’s public materials describe private and offline deployment and a managed workflow around tasks and review. Treat that as helpful infrastructure for these controls, not as a substitute for them. Two related direct answers are worth reading next: whether self-hosting is automatically private and whether MonkeyCode sends code externally, alongside the site’s security and data-flow boundaries.
Bottom line
The move from assistant to agent is a move from “is the code correct?” to “what can this system do, and who approved it?” Use the 2025 OWASP LLM Top 10 to enumerate the risks, apply least privilege and review gates to constrain actions, and verify each control with non-sensitive code before trusting a boundary. Self-hosting can strengthen several of these controls, but it does not replace them.
Source boundary: The risk categories referenced here are from the OWASP Top 10 for LLM Applications (2025 edition), checked July 20, 2026. OWASP revises the list over time; confirm the current entries and numbering directly. This article is general security guidance, not a certification of any specific product or deployment.