Before an agent touches your systems.

Access and permissions

1. Does the agent have its own identity? A dedicated service account per system, never a person’s login, so access can be scoped, logged, and revoked on its own.
2. Is every permission the least it needs? Read, propose, and write are separate grants. A folder, not the drive. A mailbox label, not the mailbox.
3. Which writes wait for a person? Send, file, pay, delete, and changes to customer data sit behind an approval gate unless the action is reversible and the owner agreed otherwise in writing.
4. How is access revoked? A written step to remove credentials and integrations when the pilot ends, a person leaves, or the scope changes.

Data flow and retention

5. What reaches the model provider? List the fields and documents sent with each request. Redact what the task does not need.
6. Is the data used for training? Check the provider’s business or API terms and the account setting, record the answer, and re-check when plans or providers change.
7. Where is it processed and how long is it kept? Provider, hosting, integration platform, logs, and backups each have a location and a retention period. Write them down.
8. Who can see the logs? Traces often contain the same data as the request. Restrict them like the source.

Prompt injection and untrusted content

Prompt injection is when content the agent reads (an email, a web page, a PDF) contains instructions that try to override its rules. OWASP ranks it first in its Top 10 for LLM applications. It is not exotic; it is any document written by someone who is not you.

9. Is retrieved content treated as data, never as instructions? The agent’s rules come from its system prompt and configuration, not from whatever it reads.
10. Are tools allow-listed per task? A triage agent does not need a tool that sends money. Fewer tools, fewer ways to be redirected.
11. Does the agent confirm before acting on instructions found in content? “The invoice says to update the bank details” is a stop rule, not an action.
12. Have you tested with injected inputs? Put hostile documents in the test set: hidden text, contradictory instructions, requests to reveal other records.

Actions and money

13. Are actions idempotent? A retry after a timeout must not create a second record, email, or payment.
14. Are there thresholds and rate limits? Amounts, counts per hour, and recipients outside the organization each have a ceiling that routes to a person.
15. Is there a dry-run mode? The workflow can run end to end and show what it would do without doing it. Use it for every change.
16. Is there a kill switch? One documented step stops the workflow, and the owner knows where it is.

Logging and audit

17. Does every result record who asked, which sources were used, what was proposed, and who approved? That record is the audit trail and the raw material for the next test set.
18. Can you reproduce a decision? Model, prompt version, source versions, and tool calls are recorded so a disputed result can be replayed.

Operations and incidents

19. Who is on the launch checklist? Named people monitor failures, receive alerts, investigate incidents, maintain dependencies, and approve changes. Support coverage is written into the agreement.
20. What happens when the provider changes? Model deprecations, price changes, and term updates are routine. A rerun of the test set and a review of the data terms are the standing response.

None of these questions requires a certification to answer. They require a written scope, which is what the security and data page describes and what we agree before access is shared.

Sources

External references used in this guide. Figures are quoted with their original baseline; none is a measurement of our own work.

1. OWASP: Top 10 for LLM applications (2025)
2. NIST AI Risk Management Framework (AI RMF 1.0)
3. Microsoft: Taxonomy of failure modes in AI agents
4. Model Context Protocol: tool and data connections