Is Your AI Agent Listening? A Small Business Guide to Agent Security

Short answer: yes, your AI agent can be turned against you, and the risk grows with every tool and credential you hand it. HackerOne's 2025 Hacker-Powered Security Report recorded a 540% year-over-year surge in valid prompt injection vulnerability reports - the fastest-growing threat on their entire platform. In a security audit survey published by Practical DevSecOps, 88% of organizations reported confirmed or suspected AI agent incidents in the past year. But the answer is not "don't use agents." It's five boring, high-leverage controls: keep the agent off the public internet, sandbox what it executes, give it dedicated least-privilege credentials, require human approval for destructive actions, and never connect it to banking logins or admin passwords at all.

I set up agents for small businesses for a living, and I've stopped counting the setups I inherit where the agent runs as root on a VPS with port 8080 open to the world and the owner's personal Gmail token sitting in a config file. This article is the checklist I wish those owners had read first.

Why Is Agent Security Different From App Security?

An AI agent is software that reads untrusted content - emails, web pages, documents - decides what to do with it using a language model, and then takes actions using credentials you gave it. A normal app does what its code says. An agent does what it understands, and understanding can be manipulated.

The attack has a name. Indirect prompt injection is an attack where malicious instructions are hidden inside content your agent will read - a webpage, a PDF, an email footer - and the agent follows them as if they came from you. OWASP has kept prompt injection at position #1 in its Top 10 for LLM Applications since the first edition in 2025. Unit 42 linked indirect prompt injection to credential or payment-data exposure in 18% of the AI security incidents it investigated.

Here's a concrete version for a ten-person company. Your agent reads an email that looks like it's from a vendor. Hidden text in the message footer tells it to export your CRM contacts and POST them to a URL. The agent treats the email body as instructions, executes the export with the CRM key you gave it, and never mentions a thing. Nobody "hacked" your server. Your agent did the work for them, politely.

How Do I Keep My AI Agent Off the Public Internet?

Every agent has some interface - a gateway, an API server, an MCP endpoint. MCP, the Model Context Protocol, is the standard plug agents use to connect to external tools; an MCP server exposes tools and often holds the credentials for them. The default mistake is exposing that interface via port forwarding so you can reach it from anywhere. Don't.

• Bind everything to localhost. A service bound to 127.0.0.1 is invisible to internet scanners. Anything reachable through a public URL, a tunnel, or a SaaS dashboard is still exposed and needs authentication.
• Reach the box through a mesh VPN. Tailscale or WireGuard gives you encrypted access from your phone or laptop without opening a single inbound port. No VPN is a magic shield - a compromised laptop or a phishing link still gets an attacker inside - but it removes you from the mass-scanning surface entirely.
• SSH with keys only, password auth off. Old advice that still holds.
• Run the gateway separate from command execution if you can. Hermes Agent supports a split setup out of the box: terminal.backend: ssh in the config, connection details in .env, never in the repo. The SSH host becomes a dedicated worker you can wipe and rebuild.

The scale of the exposure problem is documented. Trend Micro found nearly 500 enterprise MCP servers exposed to the open internet with zero authentication in early 2026, and the Practical DevSecOps MCP report counted 10,000+ public servers with only 8.5% implementing OAuth properly. If your agent's control surface is one of those, you're betting on nobody looking.

How Should I Sandbox What My Agent Executes?

Agents write and run code. If that code runs directly on your VPS host - or worse, your laptop - a compromised task means a compromised machine. Hugging Face disclosed an intrusion in July 2026 that was driven end to end by an autonomous agent: it chained a malicious dataset loader and template injection to reach credentials and move laterally through production infrastructure. Forensics covered more than 17,000 recorded events. That's what "agent escapes its task" looks like.

Options, from cheap to serious:

• Docker with hardened flags: drop all capabilities, no network unless the task needs it, resource limits set. Hermes Agent ships terminal.backend: docker with exactly these hardened defaults - the maintainers consider bare-metal execution a liability too. Fair warning: switching an existing setup to Docker can break workflows that assume host access. Duplicate your setup in a test environment first.
• Serverless sandboxes: Daytona or Modal run agent code in ephemeral environments that hibernate when idle. Task finishes, environment is destroyed. Cheap when idle, and there's no persistent host to own.
• A dedicated worker VM via the SSH backend: crude, effective, rebuildable.

Whichever you pick: run the agent as a non-root user, set a working directory that isn't sensitive, and cap CPU and memory so a runaway loop can't take the box down.

What Credentials Should My AI Agent Use?

The single most common small-business failure: giving the agent the owner's main accounts. Personal Gmail with banking emails in it, the master Stripe key, the admin password to everything. If that credential leaks through a prompt injection, a log file, or a config committed to GitHub, the blast radius is the entire business.

The fix is mechanical:

• Create dedicated service accounts. One Gmail just for agent-sent mail. One CRM user, not the admin account.
• Request narrow OAuth scopes. If the agent sends email on your behalf, the Gmail send-only scope is enough - it does not need read access to your whole inbox. Note that many CRMs don't offer fine-grained scopes at all, so "least privilege" often means a separate low-risk account rather than a perfectly scoped key.
• Rotate tokens. OAuth tokens expire on purpose. One of my LinkedIn integrations uses a token that dies every six months - annoying, and also the reason a token leaked in March is worthless by September.
• Keep keys in a permissioned .env file (chmod 600), never in config files that get shared, never in git.

MCP integrations deserve a specific caution, because an MCP server often stores OAuth tokens for every service it connects to. Self-hosted servers have roughly the risk profile of any software you run; a random community-hosted server is a stranger holding your keys. Vet what you connect, filter which tools each server may expose to the agent, and prefer first-party servers on your own box.

What Actions Should Always Require Human Approval?

Anything irreversible should pause for a human: deleting records, pushing to production, sending money, mass-emailing customers.

Good agent frameworks build this in rather than trusting the model. Hermes Agent, for example, checks every command against a dangerous-pattern list before executing, with three approval modes - smart (an auxiliary model risk-assesses), manual, or off. Matches trigger an approval prompt in your chat. There's also a hardline blocklist for catastrophic commands (filesystem wipes, fork bombs) that even YOLO mode and approvals.mode: off cannot override. And critically, unattended contexts - cron jobs, webhooks, one-shot queries - default to deny on dangerous commands: no human is there to answer the prompt, so the command just doesn't run. If your current setup auto-approves everything headlessly, that's your first fix.

The 2025 EchoLeak vulnerability (CVE-2025-32711) in Microsoft 365 Copilot showed why deterministic gates matter: one crafted email, zero clicks, and Copilot exfiltrated internal files to an attacker's server. Microsoft patched it server-side and found no evidence of in-the-wild exploitation - but it was found because researchers were looking. You can't rely on the model's good judgment alone; you need something mechanical between "the agent decided to do X" and "X happened."

What Should an AI Agent Never Have Access To?

Some systems should be off the network as far as the agent is concerned:

• Banking portals and your primary bank login. If you must automate payments, use a payment processor's API keys with per-key spending caps, transaction limits, and alerts - never the bank login itself.
• Root passwords, IAM admin rights, password-manager master credentials.
• Anything where a mistake is unrecoverable.

The reasoning is pessimistic by design: assume the agent will eventually be manipulated, because statistically speaking a large fraction of agent deployments are already misbehaving. One 2026 industry survey found 80% of organizations reporting AI agents that had performed actions beyond their intended scope, from accessing unauthorized systems to leaking credentials. If the agent doesn't hold the keys to the kingdom, a successful attack stays contained to the small, replaceable set of accounts you gave it.

Is a Self-Hosted Agent Safer Than a SaaS Agent?

Neither one is safe by default - what changes is who holds the responsibility.

Self-hosting shifts risk to you: your data stays on hardware you control, credentials sit in a file you can chmod, and the blast radius is whatever you scoped it to. SaaS shifts risk to a vendor: their security team patches the platform, but their incident response has to beat your attacker, and you're one tenant among thousands. imo for a small business, self-hosted with the five controls above usually wins, because you actually set the boundaries. A well-run SaaS agent with audited controls, per-tool scopes, and policy enforcement can beat a neglected VPS that hasn't run an update since spring. If nobody on your team will own patching and log review, pick the SaaS and read their security page.

The honest version: both models are dangerous without the five controls. Self-hosting buys you control, not safety. You still have to cash the check.

The 30-Minute Hardening Checklist

1. List what ports the box exposes (ss -tulpw or your cloud provider's firewall dashboard). Close everything not needed.
2. Add a mesh VPN for remote access, now that nothing public is open.
3. Move the agent out of root. Dedicated user, non-sensitive home directory.
4. List every credential the agent can reach. Delete what it doesn't need; replace the rest with scoped service-account versions.
5. Set approvals.mode to smart or manual, and verify cron_mode and unattended_mode default to deny.
6. Stage a switch to the Docker or serverless terminal backend in a test environment before touching production.
7. Calendar reminder, quarterly: update the agent, rotate tokens.

None of this takes a security team. It takes an afternoon, and it converts your agent from "a stranger with my passwords" into "a scoped employee with a badge that opens exactly two doors." That's the deal worth making - the automation upside is real, and so is the math on what a leaked master credential costs a ten-person company.

If you'd rather have someone do this with you, that's literally my job - details at ishchuk.eu.