The risks are real

The same autonomy that makes agents useful makes them hazardous. An unsupervised agent can loop forever, burn through your budget in API calls, take harmful or irreversible actions (delete the wrong files, send the wrong email), or be hijacked by prompt injection — malicious instructions hidden in a web page or document it reads, telling it to ignore you and do something else. These aren't edge cases; they're the default failure modes you must design against.

Essential guardrails

A production agent needs hard limits, not good intentions:

• Step and budget caps — a maximum number of iterations and a spend ceiling, so a confused agent stops instead of spiraling.
• Human-in-the-loop approval — require a person to confirm anything irreversible or high-stakes (payments, deletions, external messages).
• Least privilege — give each tool the minimum access it needs. An agent that only reads shouldn't hold write keys.
• Input and output validation — check tool arguments before running them and sanity-check results before acting on them.
• Observability — log every step, decision, and tool call so you can audit, debug, and catch problems early.

Prompt injection specifically

Because agents act on text they read, treat all external content as untrusted. Don't let a fetched web page's instructions override your own, and keep the agent's permissions narrow so even a successful injection can't do much damage.

Treat an agent like a powerful but junior employee: give it a clear scope, real limits, and supervision on anything that matters. You wouldn't hand a new hire unlimited spend and the production database on day one — don't hand an agent that either.

Try this: For an agent you'd actually deploy, write down the single most damaging thing it could do if it went rogue or got injected. Then design the one guardrail that makes that impossible — usually least privilege or a human approval step. Securing the worst case first is how real agent safety starts.