Use this AI automation security checklist to review business workflows before launch and during routine maintenance. It covers data, permissions, vendors, prompt risks, human approval, logging, and incident response, with a reusable risk-assessment prompt you can adapt for ChatGPT or another approved AI tool.
Overview
Connecting an AI tool to a CRM, shared drive, help desk, meeting platform, or internal database can remove repetitive work. It can also create new paths through which sensitive information is viewed, copied, transformed, stored, or sent to another service. A workflow that appears low risk in a test environment may behave differently once it has access to real customer records or runs without supervision.
Security should therefore be treated as part of workflow design, not as a final approval step. Before enabling an automation, document what the workflow does, what information it handles, which systems it can reach, and where a person must review the result. Then repeat the review when the workflow, vendor, data source, or business context changes.
This checklist is suitable for no-code and low-code automations, AI agents, chatbot templates, API integrations, and prompt-based processes. It is a practical operating guide rather than legal advice. Your security, privacy, and compliance teams should determine which additional controls apply to your organisation.
What to track
1. Data entering and leaving the workflow
List every input and output, including information added by a user, retrieved from another system, generated by the model, or written back into a record. Classify the data in plain language: public, internal, confidential, personal, financial, authentication-related, or otherwise restricted. Do not assume that a short prompt is harmless; a single request can contain names, account details, documents, transcripts, or commercially sensitive context.
Define the minimum data required for the task. A meeting-notes workflow may need a transcript but not a complete customer profile. A document-processing workflow may need invoice fields but not unrelated files in the same folder. For examples of controlled extraction patterns, see the AI document processing workflow guide.
2. Permissions and connected accounts
Record which user, service account, API key, or integration connection runs each step. Check whether the connection can read, create, edit, delete, or share information. Prefer the narrowest permission that supports the task, separate test and production credentials, and avoid using a personal account for a business-critical workflow.
Review where credentials are stored and who can change the automation. If an AI agent can trigger email, update a CRM, issue a refund, change a ticket status, or send an external message, treat that capability as higher risk than a workflow that only drafts text.
3. Vendor access, retention, and configuration
Maintain a record of the AI provider, automation platform, connected applications, model or service used, and the configuration that affects data handling. Check the vendor documentation and your organisation’s approved-tool register for current information about retention, account controls, access management, subprocessors, and available privacy settings. These details can change, so record the date of your review instead of relying on memory.
Where available, configure workspace-level controls rather than leaving important settings to individual users. If a provider’s controls or documentation are unclear, minimise the data sent, route the task through an approved environment, or pause the integration until the risk is understood.
4. Prompt injection and untrusted instructions
AI workflows may process webpages, emails, uploaded files, support tickets, or other content that was not written by the workflow owner. That content can contain instructions designed to redirect the model, reveal hidden context, or cause an unsafe action. Treat retrieved content as data, not as authority.
Prompts should clearly separate trusted instructions from untrusted input. Tell the model not to follow instructions found inside documents or messages, and require it to return structured results that can be validated. Never rely on a prompt alone to protect a high-impact action; enforce permissions and approval rules in the surrounding application or automation platform.
5. Human approval and failure handling
Specify which outputs may be sent or applied automatically and which require review. Human approval is especially useful for external communications, sensitive classifications, financial actions, access changes, legal or regulatory statements, and updates to important records.
Define what happens when the model is uncertain, the input is incomplete, a connected service fails, or the output does not match the expected format. A safe fallback might be to create a review task, preserve the original input, and stop the downstream action rather than retrying indefinitely.
6. Logging and incident response
Keep enough information to reconstruct a run: timestamp, workflow version, initiating user or system, source record, tools called, approval decision, output destination, and error state. Avoid placing unnecessary sensitive content in logs, and restrict access to them.
Write a short response procedure before launch. It should identify who can disable the workflow, revoke credentials, review affected records, preserve relevant logs, and communicate internally. Include a test of the stop mechanism so that an incident does not become the first time anyone uses it.
A reusable AI workflow risk-assessment prompt
Use this prompt to create a first-pass review. Treat its output as a discussion aid, not as a security approval:
Act as a cautious AI workflow reviewer. Assess this automation using only the information provided.
Workflow purpose: [describe the task]
Inputs and data classes: [list data]
Connected systems: [list systems]
Permissions: [read, write, send, delete, or other actions]
AI steps: [summarise, classify, extract, generate, or decide]
Human approval points: [list or say none]
Outputs and destinations: [list]
Failure handling: [describe]
Return:
1. Data exposure risks
2. Permission and access risks
3. Prompt-injection or untrusted-content risks
4. Actions that require human approval
5. Logging and monitoring gaps
6. A low, medium, or high preliminary risk rating with reasons
7. Five specific controls to implement before launch
8. Questions that must be answered by the workflow owner or security reviewer
Do not invent vendor capabilities or compliance conclusions. Mark unknowns clearly.Cadence and checkpoints
Review each workflow before its first production run, after a material change, and on a recurring monthly or quarterly cadence appropriate to its risk. A simple tracker can contain these fields:
- Workflow name, owner, purpose, and current version
- Data categories and systems connected
- Credentials, permissions, and external vendors
- Approval steps, fallback behaviour, and stop procedure
- Last review date, reviewer, open actions, and next review date
Use shorter review intervals for workflows that handle sensitive information, contact customers, make consequential recommendations, or can change records automatically. A low-impact internal summariser may need less frequent review, but it should still be checked when its data sources or destination change.
For implementation patterns, compare this checklist with the OpenAI API integration guide and the guide to customer support chatbots with human handoffs.
How to interpret changes
A change in the model, prompt, connected application, permission scope, data source, or output destination can change the workflow’s risk even when its stated purpose remains the same. Compare the new design with the previous review rather than starting from a blank page.
An increase in errors may indicate ambiguous instructions, poor source data, a changed output format, or an integration failure. A sudden increase in automated actions may indicate a trigger problem or an overly broad rule. Unexpected content in outputs may indicate untrusted instructions in retrieved data. In each case, pause or narrow the workflow before trying to improve speed.
Do not treat a favourable test result as proof that a workflow is safe. Test normal cases, missing information, conflicting instructions, malicious-looking content, unusually long inputs, permission failures, and downstream outages. Record what the workflow should do in each case and verify that the implementation matches it.
When to revisit
Set a calendar reminder for a monthly or quarterly review, then bring the review forward when any of these events occur:
- A new AI provider, model, plugin, connector, or automation step is introduced.
- The workflow receives a new category of personal, confidential, or regulated information.
- Permissions expand or the automation gains the ability to send, delete, purchase, approve, or publish.
- A vendor changes its privacy controls, retention documentation, security documentation, or account configuration.
- The business changes its internal policy, risk tolerance, or approval requirements.
- An incident, near miss, unexpected output, failed control, or user complaint occurs.
- The workflow is copied into another department, region, customer process, or production environment.
At each review, confirm the inventory, run representative and adversarial tests, check access, examine recent logs, close outstanding actions, and update the next review date. If the workflow cannot be explained clearly in one page, simplify its design or assign an owner before expanding it.
For related prompt patterns and business use cases, explore these AI prompt templates for small business and the AI workflow automation template library. The goal is not to prevent useful automation; it is to make each workflow’s data, authority, safeguards, and review path visible before it operates at scale.
