A secure-by-design agent has answers to twelve questions before launch: what it reads, what it can reach, what it can do, who it acts as, what needs approval, what is logged, how it was tested, how it is stopped, who owns it, what it costs at worst, how it changes and when it is reviewed. Missing answers are the findings.
Inputs
- What does it read, and who wrote it? List each channel and mark it trusted or untrusted. Untrusted includes customer text, web pages and inbound email.
- Does untrusted text reach a sensitive tool? If so, break the path with a pattern from six design patterns.
Access and actions
- What data and systems can it reach? Narrow to the task.
- What can it change or send? Include indirect actions, such as fetching a URL.
- Does it hold all three of untrusted input, sensitive access and the power to act? If yes, redesign or add supervision, per the Rule of Two.
Identity and approval
- Who does it act as? Its own scoped identity, not a shared or personal login.
- Which actions need approval, and is the prompt informative enough to read?
Visibility and testing
- What is logged? Inputs, tool calls with arguments, outputs, approvals, and who or what triggered the run. Keep secrets out of logs.
- How was it tested? Normal cases, boundary cases and repeated hostile inputs.
Control and ownership
- How is it stopped, and what does stopping break? Test it.
- What is the worst bill? Caps on spend, calls and loops.
- Who owns it, how does it change, and when is it reviewed? A name, a change routine and a date.
How to use the list
Print it as one page. Fill it in with the builder, a security reviewer and the owner. Mark each answer as strong, weak or missing, and attach evidence for the strong ones. A launch with several missing answers should wait.
Scoring guide
- All twelve answered with evidence: ready.
- Some weak: ready with conditions and dates.
- Any of questions 3 to 6 missing: not ready. Access, actions and identity are where damage is decided.
What this list leaves out
It does not replace a threat model for the wider application, and it does not tell you whether a model is accurate for your task. Treat it as the security floor.
Where Safeguard fits
Safeguard's policies, gates, MCP Guardrail, agent identity and asset discovery cover several of these items, and compliance and evidence automation holds the proof. You can also run a free scan at gold.safeguard.sh/scan on the code and dependencies your agent uses.
Quick check
Which questions matter most?
Access, actions and identity (3 to 6), because they decide how much damage a hijacked agent can do.
Does a read only agent need the full list?
A lighter pass is fine, but still answer the input, logging and ownership questions.
Last reviewed: 19 October 2026.
