Scope an AI security review around real actions
Map model inputs, retrieved data, tool permissions, approvals, and external effects. Define an AI review that tests boundaries rather than clever prompts.
Scope an AI application review around what the system can read and do. A conversation that only drafts text has a different risk profile from an agent that reads customer files, sends messages, or changes account settings. List those capabilities before selecting test prompts.
The model is one component. Retrieval, tool routing, authorization, approval screens, storage, and background jobs can each change the outcome. The scope should explain which component enforces each boundary and which evidence will show that it worked.
What belongs in the action map?
| Boundary | Question to answer |
|---|---|
| User identity | Which account and tenant does the request represent? |
| Retrieved content | Can the model receive another tenant's documents? |
| Instructions | Can untrusted content change tool permissions? |
| Tool arguments | Who validates the destination and operation? |
| Approval | Is approval bound to the exact action that runs? |
| Credentials | Which service identity executes the action? |
| Result storage | Who can read the output or resume the job? |
This is a suggested review map. The OWASP threat modeling guidance provides a framework for identifying data flows and trust boundaries. Apply it to the whole workflow, not only the prompt.
Which tests need separate approval?
Agree on external effects before testing them. Sending an email, creating a booking, or changing a repository is a real action even when an AI starts it. Use approved test destinations and synthetic data. Do not let a model choose new targets or expand the scope.
Specify which model provider receives which material. A local test harness can still send private code to a hosted service. Record the provider, processing purpose, and data terms before that transfer.
For tool-connected systems, inspect the controls outside the model. A prompt that says “ask first” is not equivalent to a server rejecting an unapproved action. The scope should include the policy check and the execution record where those are relevant.
What is a useful completion criterion?
Choose observable results: a cross-tenant retrieval is denied, an approval cannot authorize changed arguments, or a canceled job cannot start a new external action. Use positive and negative cases so a control that blocks every useful task does not appear successful.
Keep model behavior observations separate from enforced security properties. A model declining one prompt does not establish that every paraphrase is safe. Report the tested configuration, provider version where available, and remaining limits.
Discuss your AI workflow with Sourced. Start with the actions and data boundaries. Do not send credentials or private customer conversations in the initial message.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.
Sources
- OWASP Threat Modeling Cheat SheetAccessed
- MCP Security Best PracticesAccessed