APPENDIX D: SAFETY AND SECURITY CHECKLISTS

INTRODUCTION TO THIS APPENDIX A checklist is a list of questions you answer yes or no before you trust a system. These checklists cover three areas: permissions, defense against prompt injection, and supply-chain security for Model Context Protocol (MCP) servers and other tool integrations. Write the answer yes, no, or partly beside every item, and treat every no or partly as a task on your to-do list. No checklist makes a system safe by itself, because safety comes from several independent safeguards working together, which is the idea of defense in depth. Checklist 1: Permissions Does every tool have a written permission level, such as read or write or delete? Does the agent receive only the smallest set of tools it needs, following the rule of least privilege? Is there an allow-list that names the tools and actions that are permitted? Is there a deny-list that names the actions that are never permitted? Are file paths checked so the agent cannot escape its permitted folders by using tricks such as dot-dot path pieces? Is every action that changes or deletes data classed as an action tool and given extra safeguards? Does a human have to approve actions that are hard to undo? Does a human have to approve actions that spend money or contact other people? Does a human have to approve actions that touch data beyond the agent's normal area? Does the approval request show the reviewer enough detail to decide quickly and correctly? Is there a defined fallback if no human answers an approval request in time, and is that fallback to stay safe rather than to proceed? Is every approval or denial written to a log that cannot be edited by the agent? Are saved permissions reviewed and expired regularly instead of lasting forever? Are passwords, keys, and tokens kept out of prompts, code files, and logs? Are secrets supplied through environment variables or a secrets store instead of being typed into files? Does each agent have its own identity, so its actions can be traced to it? Can permissions be taken away quickly in an emergency? Checklist 2: Injection Defense Is all text from outside, including web pages, files, emails, and tool outputs, treated as untrusted by default? Is untrusted text clearly marked and kept separate from the developer's instructions? Is there an instruction hierarchy that says developer rules outrank anything found inside outside content? Does the system refuse to follow instructions found inside fetched content, and does it log the attempt? Are tool descriptions checked for hidden instructions before they are shown to the model? Is the model prevented from reaching private data and the open internet in the same step, to block data exfiltration? Are outgoing network connections limited to an approved list? Are the results of tools checked before they are passed on to risky actions? Where possible, is the part that reads untrusted material separated from the part that can take powerful actions? Is there a test containing a hidden instruction in your evaluation set, and does it run every time you change the system? Is the agent's behavior watched for sudden changes in the tools it calls, which can signal that it was hijacked? Does the system say plainly to users that it can make mistakes and can be tricked? Checklist 3: Supply-Chain Security Do you keep a list of every Model Context Protocol (MCP) server and tool package your agent uses? Do you know who publishes each server, and can you check that the publisher is who they claim to be, which is called origin authentication? Do you install only from sources you have reason to trust? Do you pin each package to a specific version so that a surprise update cannot change its behavior? Do you read the tool descriptions a new server provides before you allow it? Do you run Static Application Security Testing (SAST), which scans program code for flaws without running it, on code you depend on or write? Do you scan downloaded packages for known problems and malicious code? Do you check the integrity of each server, for example by comparing a published fingerprint with the one you downloaded? Do you run new servers inside a sandbox first, with limited file and network access? Do you give each server only the permissions it needs? Do you watch for changes in a server's tools after you approved it? Does your monitoring connect each prompt to the tool calls and later actions it caused? Do you have a way to switch a server off immediately if it turns out to be harmful? Do you review all the above on a regular schedule, since the field changes quickly?