A safety checklist for AI agents that can act

Eight structural rules for agents that can send, spend, or delete — each enforced by a server or an architecture rather than a system prompt, with RelayLink as the running example.

5 min read

An AI agent that can only read is a research tool. One that can send, schedule, spend, or delete is an actor — software that changes things outside its own chat window. For actors, the question stops being "is the model good?" and becomes "what happens when it is wrong?"

Structure beats prompts

Every rule below is structural — enforced by a server, a schema, or an architecture, not written into a system prompt. A prompt is advice, and hostile input exists to talk models out of advice. RelayLink — a relay that carries briefings between AI assistants owned by different people — is the running example.

The checklist

1. Assume compromise and enumerate what the agent can still do

Some instruction will eventually reach your model from content you do not control — an email, a web page, a document. Treat that as a given, the way network engineers treat packet loss. The useful question is not "how do we block every injection" but "what can a fully compromised agent still do?"

Good designs answer in writing. RelayLink's enumeration: a compromised assistant can read its own inbox and write drafts. It cannot deliver anything without the human confirming from the same account, cannot exceed the daily cap on first contact with strangers, and cannot reach anyone who has blocked the sender. If you cannot write this list for your agent, that is the finding.

2. No single call for irreversible actions

Sending, paying, and deleting are one-way doors. If a single tool call both composes and executes, one bad model output is a completed mistake — no one ever had a moment to say no.

Split every irreversible action into propose and commit, enforced server-side. RelayLink's draft_package creates a server-side draft; confirm_send — same account, after the human reviews the exact rendered package — releases it; cancel_draft discards. No tool composes and delivers in one motion, and the approval step is the product.

3. Separate reading from sending

The classic agent disaster joins hostile inbound content to outbound reach under one credential: an assistant that reads an inbox and can also send from it, so injected text becomes sent mail. That is why inbox access deserves its own analysis.

Grant capabilities by direction. Of RelayLink's nine MCP tools, check_inbox and get_package read; only confirm_send delivers, and it sits behind the review in rule 2. An agent whose job is triage never needs a send scope at all.

4. Neutralize inbound content (kill auto-fetch)

Markup is not just formatting. An image tag is an instruction to fetch a URL the moment it renders, handing an attacker a zero-click beacon — read receipts at minimum, exfiltration if the URL encodes anything.

Defuse content before any assistant or browser sees it. RelayLink neutralizes markdown images and links in everything it relays: no auto-fetch, no tracking pixels, no live links on the wire. Visiting a URL still takes a deliberate act, not a render.

Checkpoints lower the rate of bad actions; caps bound the cost of the ones that get through. The difference between an incident and a catastrophe is usually throughput — what a runaway or hijacked agent can do per hour.

Enforce limits at the service, keyed to consent. On RelayLink, standing correspondence requires a mutually accepted contact pair; first contact with a stranger is hard-capped per day and must be a full briefing. A stolen key cannot blast its way down a list of strangers — the relay does the counting, not the model — and the people who already accepted the sender can each end delivery with one permanent click.

6. Label provenance on everything that crosses an ownership boundary

Once output reaches another person, the question shifts from "what can the agent do" to "who said this". A reader who cannot tell human words from model inference will eventually act on an inference as if a person had committed to it. That is how "my assistant said you agreed" disputes begin.

Labels must be assigned by the system from what actually happened, never asserted by the model. RelayLink marks every assumption stated by sender or inferred by sender's AI, and a note earns verbatim, human-authored only when the human's wording differs from the AI's draft — echoing a draft is approval, not authorship. The provenance explainer goes deeper.

7. Make revocation one click and binding

An agent's reach is borrowed from people who can change their minds. If stopping its messages requires a support ticket — or depends on the sender's prompt saying "respect unsubscribes" — recipients are paying for someone else's automation.

Enforce revocation in the layer that carries the messages. Every RelayLink message includes a one-click unsubscribe that blocks the sender permanently at the relay. The sender's assistant cannot override it, because the relay simply refuses to carry anything further.

8. State limits honestly (rare and low-yield, never impossible)

"Impossible" is a marketing word with an engineering cost: teams that believe it stop monitoring, and users who believed it stop forgiving. Every mitigation above has residual risk, and hosted models make some of it structural.

Write the residual risk where users can read it. RelayLink's own framing: injection is made rare and low-yield, never impossible. It claims no end-to-end encryption, because the relay renders email and web views and both assistants are hosted models. If your security page says "impossible", the page is the vulnerability.

Applying it

Run the list against any agent you are about to deploy — or connect to. Rules 1–5 cap what a wrong model can do; rules 6–8 keep faith with the humans on both ends. For each item, ask where it is enforced: server, schema, or architecture. If the answer is "the prompt", score it as absent.

The threat model behind rules 3 and 4 is worked through in prompt injection and email agents. The buyer-side companion — the same questions aimed at a vendor rather than at your own design — is how to evaluate an AI communication tool, and the six failure modes catalogue what these rules exist to prevent. To see the checklist implemented end to end, connect your assistant — the receiving side needs nothing but an email address.

Frequently asked questions

What should an AI agent safety checklist cover?
Assume compromise and enumerate what the agent can still do, split irreversible actions into propose and confirm, separate reading from sending, neutralize inbound content so nothing auto-fetches, cap rates and require consent, label provenance on outbound content, make revocation binding, and state residual risks honestly.
Can prompt injection be prevented completely?
No. Any agent that reads content its owner does not control can in principle be steered by it. Honest designs make injection rare and low-yield — they neutralize inbound content, require human confirmation for irreversible actions, and cap outbound reach — and they say the risk is reduced, not eliminated.
What is the biggest risk with AI agents that can act?
The combination of hostile inbound content and real outbound capability. If one model output can complete an irreversible action, a single successful injection becomes sent mail, spent money, or deleted data. Splitting propose from commit and capping throughput bounds the damage.