You do not have a security team. You are the security team, along with being the CEO, the delivery department, and the person who forgot to rotate an API key in March.
Meanwhile your agent stack runs 24 hours a day holding real credentials to your email, your CMS, your billing system, and your clients' data. Always-on automation, broad access, zero dedicated oversight — that combination is exactly what attackers like.
It is also manageable, if you stop treating security as vigilance and start treating it as a checklist. Ours takes 45 minutes a month. Here it is.
Why agents change your threat model
An agent stack changes your threat model in three ways. It acts without you watching, so a compromise runs for hours before anyone notices. It holds standing credentials to systems you used to log into occasionally. And it reads untrusted text — emails, web pages, form submissions — as potential instructions. A static website gets defaced. A compromised agent stack sends invoices.
The good news: a solo stack is a boring target. Nobody is spear-phishing your orchestrator specifically. The realistic threats are leaked keys, over-scoped permissions, prompt injection arriving through routine inputs, and your own agents doing something dumb at scale.
Every item on this checklist maps to one of those four. None of it requires a security background.
Most items take minutes. The discipline is doing them on a schedule instead of after an incident.
Give every agent its own scoped credential
One credential per agent, scoped to the minimum the job requires, is the highest-value control on this list. If your research agent and your publishing agent share an API key, a leak in either exposes both. Separate keys mean a leak has a blast radius of one agent, and revoking it kills one function instead of the whole stack.
In practice that means separate API keys for every service an agent touches, read-only tokens wherever the agent only reads, and hard spend caps on anything metered.
Our content agent can write drafts. It cannot publish, cannot delete, and has never heard of the billing system.
The monthly audit question is one sentence: can any agent do something its job description does not require? If yes, cut the scope the same day you notice.
A secrets vault and zero credentials in prompts or repos should go without saying. Check anyway, because the convenient path violates both at least once a quarter.
Treat every inbound text as hostile input
Prompt injection is not exotic. Any text your agents read — an email, a scraped web page, a form submission — can carry instructions the model may follow as if they came from you. The defense that works for a solo stack is structural, not clever prompting: agents that read untrusted input do not hold write access to anything important, and every outbound action passes an allowlist.
Our inbox triage agent reads everything and can do exactly three things: apply a label, draft a reply for review, and escalate to a human. It cannot send, forward, or delete.
An injected email can waste that agent's afternoon. It cannot spend its permissions, because there are none worth spending.
Where one agent must both read the wild web and take real actions, split it into two agents with a reviewed handoff in between. The pattern costs about a day to build.
Decide what data agents may never touch
Write down, on one page, the data your agents are forbidden to read, store, or send: client financials beyond what a task needs, anything under NDA, credentials, and personal data you would have to report if it leaked. Then enforce the list mechanically — separate storage the service accounts cannot open — instead of trusting instructions to hold.
The mechanical part is the point. A model instructed to never read the contracts folder will comply right up until a task makes reading it look helpful. A service account with no access complies every time.
We keep client personal data in one system the engine holds zero credentials for. Retrieval is always a human action.
The cost is maybe ten minutes of my week. The alternative cost is a breach disclosure email to every client I have.
Log every action and read the diff weekly
Every agent action that touches the outside world — sends, publishes, edits, purchases — goes to an append-only log with a timestamp, the agent's name, and what changed. Once a week, spend 20 minutes reading the summary. This is the control that turns every other control from a hope into a fact you can verify.
You are not hunting attackers so much as noticing drift: the agent that quietly started emailing twice as often, the publish job that ran at 3 a.m. for no reason.
The log is also what makes incidents survivable. 'I can see exactly what it did' is an hour of cleanup. 'I have no idea' is a week.
Ours is one database table plus a Friday summary the engine writes about its own week. Build time was an afternoon.
Set two alerts on top of the log: any action type the stack has never performed before, and any hour with triple the normal action volume. Both are five-minute rules in most automation tools, and both catch the weird stuff early.
Build the kill switch before you need it
You need one action, executable from your phone in under five minutes, that stops every agent: a single environment flag the orchestrator checks before any run, plus a bookmarked page for revoking the stack's OAuth grants. Build it on a calm Tuesday. Then drill it quarterly, so the muscle memory exists on the day you are panicking.
Our quarterly drill takes eleven minutes: flip the flag, watch every queue drain, flip it back.
The first drill found two cron jobs that ignored the flag entirely. That discovery alone paid for the ritual.
A kill switch you have never tested is a hypothesis, not a control.
Print the recovery steps on one page while you are at it — key revocation, password resets, client notification order. Panic reads paper better than it improvises.
Run the 45-minute monthly review
The monthly cadence, first Monday, 45 minutes: rotate any key older than 90 days, re-read each agent's permission scopes against its actual job, skim the month's action log for anomalies, verify the latest backup actually restores, and run one prompt-injection probe against your own intake agent. Put it on the calendar with the same status as a client call.
Quarterly, add the kill-switch drill and a fresh pass over the forbidden-data list, because scope creep is quiet.
None of this is impressive, and that is the point. Security for a one-person agent stack is not a product you buy. It is a short list of boring controls, actually maintained.
The stack earns its keep by running unattended.
The checklist is what makes unattended safe.