Is your bot team safe?
Grok Bot and comparable always-on agent teams sign into your tools with your credentials and act without an approval gate, on top of a live, unpatched prompt-injection vulnerability. This checklist covers the three risk areas: approval gates, credential and API-key blast radius, and prompt injection exposure.
Enter your email to get the printable PDF version of this checklist, and get notified when new agent-safety checklists ship.
Technical Insights
Monthly deep-dives on SaaS architecture (no fluff).
Approval gates
Every write action requires an explicit human approval step
A bot team with standing credentials and no approval gate can send emails, move money, or push code the moment it decides to, not the moment you decide it should.
Bots are scoped to one task at a time, not a standing mandate
An always-on agent with an open-ended mandate keeps acting after the context that justified the first action has changed, without approval catching the drift.
Every action a bot takes is logged with what it did and why
Without an audit trail you cannot tell whether an unsupervised bot did the right thing for the right reason, only that something happened.
There is a single kill switch that revokes a bot mid-task
If a bot starts acting on bad instructions, you need to stop it before it finishes the task, not after.
Credential & API-key exposure
Bots hold least-privilege credentials, not your personal login
A bot that signs into Gmail, Stripe, or your CRM with your own credentials has your full blast radius the moment it is compromised.
API keys are scoped per bot and per tool, not shared account-wide
One shared API key across every bot and tool means one injected instruction can reach every system that key touches.
Credentials rotate automatically and expire if unused
Standing credentials that never rotate stay valid long after the task that needed them, widening the window an attacker has to use them.
Payment and billing access is isolated from general-purpose bots
Stripe and billing credentials sitting in the same session as a general web-browsing bot turn a prompt-injection bug into a theft.
Prompt injection
Content a bot reads from the open web is treated as untrusted input
A bot that browses the web and executes instructions it finds on a page is exposed to the live prompt-injection exfiltration vulnerability already reported against agent-team products.
A bot cannot both read untrusted content and take an unreviewed action in the same step
Separating "read" from "act" is the control that stops an injected instruction on a webpage from becoming a credentialed action.
The team has reviewed known injection incidents against comparable agent products
Prior agent-driven crypto thefts came from injection plus excessive agency, the same combination an unreviewed bot team ships with by default.
Bot-to-bot messages are validated before one bot acts on another bot's output
When bots message each other and build reusable routines, an injected instruction can hop from one compromised bot to every bot that trusts it.
This checklist tells you where to look. It does not verify that your setup is actually safe. If you want your approval gates, credential scope, and injection exposure checked against your real stack, not self-reported against a list, a fixed-scope Ship Check audit does that.
Get a full Ship Check →