The most common myths are that a better model fixes injection, that approval prompts equal safety, that private repositories are safe from hostile text, that self-hosting removes risk, and that a prompt rule is a control. Each is wrong in a way that changes how you set up your team.
Myth 1: A better model makes prompt injection a solved problem
Fact. Better models resist more often, but resisting most of the time is not a control. OWASP lists Prompt Injection as the first entry, LLM01, in its 2025 Top 10 for LLM applications. Design so that a hijacked agent can do little: small permissions, limited network, human review of results.
Myth 2: Approval prompts make an agent safe
Fact. Prompts help only when a person can judge the action and reads it. People who face constant prompts click through. Reduce permissions first, keep prompts for risky actions, and enforce limits in the tool or the operating system. The MCP security guidance says clients should show the exact command before running a new local server and warn about dangerous patterns, which is about making the decision informed, not just frequent.
Myth 3: A private repository is safe from hostile instructions
Fact. Private repositories still contain dependency documentation, issue text, fetched pages, and tool output, all of which can include text written by someone you do not control. Privacy limits who can read the code. It does not limit who can write text that an agent reads.
Myth 4: Self-hosting the model removes the risk
Fact. It changes where prompts go. The agent can still run risky commands, hold broad credentials, and add bad dependencies. Self-hosting also moves patching and model supply chain, OWASP's LLM03, onto you.
Myth 5: A rule in the prompt is a control
Fact. A sentence asking the model not to read secrets is a request. A container that does not mount the secrets is a control. Where it matters, enforce in code, permissions, or the network.
Quick reference
| Myth | What to do instead |
|---|---|
| Better model solves injection | Limit what a hijacked agent can do |
| Prompts equal safety | Shrink the prompt set to risky actions |
| Private means safe | Treat all repository text as untrusted input |
| Self-hosting removes risk | Apply agent controls in both models |
| Prompt rule is a control | Enforce in the tool, OS, or network |
Why the myths persist
They are comfortable. Each one lets a team skip hard work: tune the model, add a click, trust the perimeter, buy the hardware, write a policy sentence. The real work is dull: inventory what the agent can reach, remove what it does not need, log what it does, review what it produces.
What to tell your team
Three sentences go a long way. Agents act with the access you give them. Anything they read can try to steer them. A person is accountable for every change they produce. Our post on one page of AI coding agent rules for developers turns that into a handout.
A short test of your own beliefs
Ask your team which of the five myths they have heard in a meeting this quarter. Then pick one control from the facts column and put it on the next sprint. Small, visible changes beat a large program that never ships.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: what the myths cost
Consider how each myth plays out in one hypothetical team over a quarter.
| Belief | Decision it justified | What happened |
|---|---|---|
| A better model solves injection | Skip network limits | A hostile comment in a dependency caused an unexpected outbound request that nothing stopped |
| Prompts equal safety | Prompt on every command | Developers began auto approving, then turned prompts off |
| Private means safe | No review of dependency text | Instructions in third party documentation reached the agent |
| Self-hosting removes risk | Skip agent controls | A broad token let the agent change pipeline files |
| A prompt rule is a control | Wrote "never read secrets" in instructions | The agent read an environment file during a debugging task |
The team did not suffer a catastrophe in this story. Each event was small. But every one was predictable from the fact beside the myth.
Turning facts into a quarterly plan
| Quarter task | Control | Owner |
|---|---|---|
| Week 1 | Inventory what each agent can run, read, and reach | Platform |
| Week 3 | Move agents into a container with no inherited credentials | Platform |
| Week 5 | Cut the prompt set to the risky tier | Security and engineering |
| Week 7 | Add network allowlist and logging | Platform |
| Week 9 | Add a pull request gate for new dependencies | Engineering |
| Week 11 | Tabletop an agent incident | Security |
None of these depends on which model or vendor you use, which is the point. Controls that survive a tool change are worth more than ones tied to one product's settings.
How to talk about this with executives
Executives rarely need the technical detail. Give them three messages. First, agents act with the access we give them, so we are limiting access. Second, anything an agent reads can try to steer it, so we assume that and limit damage. Third, a person is accountable for every change, so we are enforcing review. Each message maps to a control and a metric you can show.
Questions to ask yourself
- If an agent here were fully hijacked for ten minutes, what is the worst outcome?
- Which of our controls exist only as written instructions?
- Who is the named owner of each agent in use?
- When did we last test a control rather than assume it?
A reading list for your team
The OWASP Top 10 for LLM Applications gives shared vocabulary for prompt injection, excessive agency, and supply chain, and the Model Context Protocol security guidance covers local server risks in practical terms. Reading both takes under an hour and makes team discussions more concrete.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice how findings are tracked and prioritized instead of assumed away.
Quick check
Which myth is most dangerous?
Usually the belief that a prompt rule is a control, because it leaves nothing enforced when the model errs or is steered.
Do these apply to every tool?
They describe how language model agents work in general. Test each tool for its own behavior.
What is the first control to add?
Run the agent in a container with no inherited credentials. It removes the largest class of mistakes with a small amount of work.
Sources
Last reviewed: 19 October 2026.
