Owners who connected an agent quickly and want to confirm it is safe
15-minute security pass
List every tool your agent can currently reach
The AI agent security checklist for a small business
Start here, before the detail. Managed hosting already covers the layer under the floorboards—isolation, managed security updates, daily backups, free SSL, and auto-restart—so your checklist is not about servers. It is about the workflow you actually see: what the agent is allowed to touch, and how hard a mistake would be to take back. Run these nine checks:
- Grant read-only first. Add the power to change or send only where a specific job truly needs it. See the four-level permission model.
- Set each workflow's autonomy. Choose read, draft, approve, or act to match how bad a mistake would be.
- List every connected tool. Disconnect anything no current job uses, following a pre-connection checklist.
- Treat credentials as keys you can take back. Nothing typed into a chat or a note—use sign-ins you can revoke.
- Gate high-impact actions. Money, sending, publishing, and deleting each wait behind an approval step—see the guardrails for those moments.
- Give the agent its own logins where you can, separate from your personal accounts.
- Read one recent run end to end, so you see what it did, not what you assumed. Start with the basics of watching a run.
- Confirm one disconnect switch. You should be able to cut any tool's access from a single place, today.
- Review permissions regularly. Put a 15-minute pass on the calendar each month, part of a standing review.
Why it matters: an agent is only as safe as the smallest thing it cannot undo. How to judge it: every item above is reversible and checkable in minutes—if any check takes you longer than that to answer, that is the gap. The common failure is skipping the whole pass because it sounds technical; it is not, and the cost of skipping shows up as a sent message or a charge you cannot recall. The trade-off: fifteen minutes of tightening now, against an afternoon of cleanup later.
Permissions and autonomy: grant the least that still works
What to do: connect each tool as read-only by default, then raise it to change, approve, or act only for the one workflow that needs it. Autonomy is the sibling setting—decide per job whether the agent may only read, draft for you, wait for your approval, or act on its own.
Why it matters: broad write access paired with full autonomy is what turns a small misread into a real-world action. The two settings multiply; the safest agent has exactly enough of each to finish its job and nothing it cannot justify.
How to judge it: for every connection, can you say in one sentence what the agent is allowed to change? If the honest answer is “everything” or “I'm not sure,” it has too much.
A realistic failure: an owner grants full email send access on day one “to save time.” A drafting task fires early and sends a half-finished reply to a client. Read-only email plus a draft-and-approve step would have caught it in the folder.
The trade-off: least privilege means you will occasionally re-grant access when a job grows. That small friction is the feature, not the bug—each raise is a decision you made on purpose.
Use case: Dana checks a shop she wired up too fast
Dana runs a small online shop on her own. During launch week she connected her agent to email, the calendar, her store, a payments tool, and two others, granting broad access each time so nothing would slow her down. Security was a problem for later. A month in, “later” arrived as a 2 a.m. question: what can this actually do without me?
She had two options. Leave the setup broad and trust that it had behaved so far, or spend fifteen minutes running the checklist. She chose the pass. She listed the connections and counted nine; five of them no current workflow used, so she disconnected them. Two workflows were set to “act” on their own—she dropped both to “approve before.” Payments had no gate at all, so she added one.
Nothing had gone wrong yet—that was the point. The lesson Dana took was that security here was not a product she could buy or a firewall she could switch on. It was a short review she owned and repeated, and the fifteen minutes felt cheap the moment she saw how much the agent could no longer reach by accident.
Dana's checklist pass, before and after
Illustrative figures from one owner's fifteen-minute pass—an example of tightening access after a fast launch, not a customer result, benchmark, or product performance claim.
Five tools no current job needed lost their access.
Two high-impact jobs dropped to “approve before.”
Payments moved behind one confirm step.
Connections: know every tool the agent can reach
What to do: open the list of connected tools and read it like an inventory. For each one, ask whether a live workflow actually uses it. If nothing does, disconnect it. A tool the agent can reach but never uses is pure exposure with no upside.
Why it matters: the blast radius of any mistake is the set of things the agent can touch. Every connection you remove shrinks it. Owners tend to add connections during setup and never subtract, so the list quietly grows past what any job needs.
How to judge it: a healthy list is one you can explain top to bottom—this tool feeds the Monday report, that one drafts replies. Anything you cannot tie to a running job is a candidate to cut.
A realistic failure: a file-storage tool connected for a one-time import stays linked for months. It is not used, not watched, and not remembered—until it is the thing an errant instruction reaches. The pre-connection checklist exists to stop that link from being casual in the first place.
The trade-off: fewer connections can mean re-linking a tool later when a new workflow needs it. Reconnecting takes a minute; an over-connected agent costs you the ability to reason about what it can do.
Credentials: keys you can always take back
What to do: connect tools through their normal sign-in, so access is a permission you can withdraw—never a password pasted into a chat, an instruction, or a saved note. Where a tool allows it, give the agent its own login rather than sharing yours, and turn on multi-factor authentication on the accounts behind it.
Why it matters: a credential is a key. If it lives inside a message thread, you cannot revoke it, you cannot see who used it, and you cannot rotate it without hunting through history. The Federal Trade Commission's small-business guidance is blunt about the basics here: long, unique passwords, never reused or shared. The same discipline protects the accounts your agent connects to.
How to judge it: for any tool, could you cut the agent's access in under a minute without changing your own password? If yes, the credential is a revocable key. If no, it is baked in too deep.
A realistic failure: an owner pastes an account password into the agent's instructions so it can “just log in.” Now the secret is copied into memory and logs, and the only way to revoke it is to change the password everywhere it is used. Sign-in-based connections avoid that trap entirely—more in credentials without the jargon.
The trade-off: a separate login and multi-factor authentication add a few minutes of setup. They buy you a clean off-switch and a record of what the agent, specifically, did.
Guardrails and a review you repeat
What to do: confirm that the four actions with lasting consequences—moving money, sending under your name, publishing in public, and deleting records—each wait for your approval rather than running on their own. Then make the whole checklist a habit: review AI agent permissions regularly, a 15-minute pass on the calendar each month.
Why it matters: guardrails are what separate a reversible draft from an irreversible act, and a one-time audit decays. Tools get added, jobs change, and access you granted for a project outlives it. NIST's AI Risk Management Framework treats governance as an ongoing loop—govern, map, measure, manage—not a certificate you earn once.
How to judge it: try to name the last thing the agent could do that you could not undo. If nothing comes to mind, your gates are probably in the right place. If several things do, that is your list for this month's review.
A realistic failure: a founder sets everything up carefully in month one, then connects three new tools over the summer without revisiting autonomy. By autumn the agent can publish and pay in places no one gated. A recurring review catches drift like that before it matters. See also the action-specific guardrails for sending, publishing, paying, and deleting.
The trade-off: a monthly review is time you spend on something that usually finds nothing wrong. That is exactly why it works—you are paying a small, predictable cost so a large, unpredictable one never arrives.
Try this next
- List every tool your agent can currently reach, and disconnect anything no active workflow uses.
- Set each remaining connection to read-only unless a job needs more, and match its autonomy—read, draft, approve, or act—to how hard a mistake is to undo.
- Confirm money, sending, publishing, and deleting each sit behind an approval step, not on autopilot.
- Put a 15-minute permission review on the calendar each month, and remove access that is no longer used.
Sources and further reading
These primary references support the checklist's core ideas: least privilege and bounded autonomy, strong credentials and access control for a small business, and governing agent risk as an ongoing review rather than a one-time setup.
Directly supports the least-privilege and bounded-autonomy checks: it names excessive functionality, permissions, and autonomy as the core risk and recommends limiting each and requiring human approval for high-impact actions.
Federal Trade CommissionCybersecurity for Small BusinessPlain small-business guidance behind the credentials and access checks—long, unique passwords never reused or shared, limiting who can reach sensitive systems, and regular backups.
NISTSmall Business Cybersecurity CornerA hub of small-business resources, including multi-factor authentication and securing data and devices, that backs the “own login plus MFA” and revocable-key items.
NISTAI Risk Management FrameworkFrames governance as an ongoing govern-map-measure-manage loop, supporting the case for reviewing permissions regularly rather than auditing once.
Ready to put one useful workflow to work?
Start with one clear job, a result you can review, and boundaries you understand.
See launch pricing