An assistant that drafts from public information differs from an agent that reads client files or changes financial records. Our recommended approach is a narrow, documented pilot with evidence of working controls before access expands. Secure development guidance covers the full lifecycle, not just the initial model or prompt. [1]
1. Name the use case and the accountable people
Write a short approval record: intended task, permitted users, data categories, connected systems, allowed actions, foreseeable harm, and success measures. Name a business owner and a technical operator, including deputies and stop authority. NIST calls for documented responsibilities and executive accountability for AI risk decisions. [2]
Treat a new connector, sensitive dataset, or write permission as a scope change needing review. An approved summarizer is not automatically approved to become an autonomous email sender.
2. Secure the accounts and information first
Use approved business identities, appropriate strong authentication, managed devices, and role-based access. Review overshared files and old accounts before connecting them to search or retrieval. Verify that the system enforces the current user's permitted scope, including when shared indexes or service identities are involved.
Keep connector credentials outside prompts and source documents. Use narrowly scoped, revocable credentials and separate test and production access. Do not connect a personal account simply because enrollment is easier. NCSC guidance addresses protecting systems, data, and the software supply chain. [1]
3. Verify the actual product, plan, and data path
Document where prompts, retrieved files, outputs, logs, and feedback go; who can access them; and what retention, deletion, hosting, and contractual terms apply. Include connected apps and subprocessors rather than stopping at the model provider.
For example, OpenAI says business-product and API data are not used for training by default; individual services have different controls. "Not used for training" does not mean "never stored" or that an unrelated connected service has the same terms. Verify the purchased service and settings rather than applying one product's statement to every AI tool. [3]
4. Assume documents can contain hostile instructions
A retrieved email or file can contain instructions intended to redirect an assistant. OWASP identifies this as an indirect prompt-injection risk. A trusted storage location does not make all text inside it an instruction the assistant should obey. [4]
Use layered controls: restrict tools and destinations, separate outside content from authorized instructions, and test attempts to retrieve another client's data or send information somewhere unexpected. A prompt saying "never disclose confidential information" is useful guidance, not an access-control boundary. Read-only access also needs limits on disclosure.
5. Put consequential actions behind real authorization
Start with drafting or read-only tasks where practical. Permit only the actions the workflow needs. Enforce access and transaction limits in the application or service, not solely in the model's instructions. OWASP connects excessive functions, permissions, and autonomy with unwanted actions. [5]
Require a meaningful approval step for high-impact actions. Show the reviewer the actual recipient, data, amount, or record change. Bind approval to that specific action; a generic "continue" or approval of a previous draft is not blanket authority for later changes.
6. Validate output before another system trusts it
Check required fields, destinations, file types, and transaction rules. Treat generated code and commands as untrusted until reviewed and executed only in an appropriately restricted environment. Do not let a model response directly become a database operation, system command, or public message without the controls appropriate to that use. OWASP warns about downstream harm from improper output handling. [6]
Human review must be feasible. A reviewer needs source records, time, relevant expertise, and authority to reject the result; a nominal approval button is not the same as effective oversight.
7. Test failure, shutdown, and recovery before launch
Our pilot checklist should include an unauthorized-data request, a misleading document, an incorrect answer, a wrong-recipient attempt, duplicate actions, revoked access, service failure, and a spending-limit event. Record expected behavior, actual results, gaps, and who accepts remaining risk.
Demonstrate how to pause automation, revoke connectors, cancel queued actions where possible, and return to a non-AI process. Some external actions cannot simply be undone. Define approval and recovery around that fact rather than promising universal rollback.
8. Operate and review what you deploy
Log enough to investigate decisions, access, approvals, and failures, but restrict log access and avoid creating an unnecessary second store of sensitive prompts or secrets. Monitor quality, cost, access changes, and incidents. Train users on allowed data, verification, escalation, and reporting mistakes. Ongoing monitoring and secure updates are part of NCSC's operating guidance. [7]
Release gate: demonstrate the permitted data scope, approval boundary, test results, assigned operator, and a working stop process. An unresolved high-impact gap is a reason to narrow or delay the pilot, not merely add a disclaimer.
Blue Tree Technology® can discuss the technical and operating requirements of your proposed use. Agree the actual delivery scope in writing. We recommend reviewing this guidance every 30 days and sooner after material product, policy, connector, or permission changes; this cadence is our editorial choice, not a universal regulatory requirement.
Sources and further reading
[1] NCSC and partners: Guidelines for secure AI system development
[2] NIST AI RMF 1.0: Core, especially GOVERN 2.1-2.3
[3] OpenAI: How your data is used to improve model performance
[4] OWASP: Prompt Injection (2025 risk guidance)
[5] OWASP: Excessive Agency (2025 risk guidance)