An AI automation can look harmless in a demo and still create a substantial security problem in production. The difference is connectivity. Real workflows need accounts, APIs, documents, databases, SaaS platforms, logs, credentials, and often third-party model providers. Each connection changes the attack surface.
Security therefore belongs in the architecture of the automation, not in a checklist completed the day before launch.
Map the data flow
Document what enters the workflow, where it goes, what services process it, what is stored, and what leaves the organization. Include logs and temporary processing, not only the final database. This exercise often exposes unnecessary data collection or a vendor connection that the project team had not considered sensitive.
Use the least privilege the workflow actually needs
Automation accounts should not inherit broad administrator access simply because it is convenient during development. Give each integration the minimum permissions required for its function. Separate development and production credentials, protect secrets in an appropriate secret-management mechanism, and establish a rotation and revocation process.
Treat model output as untrusted input
Generated text can be wrong, manipulated, or unexpectedly formatted. Do not let an AI response become a privileged system action without validation appropriate to the risk. High-impact actions may require deterministic checks or human approval before execution.
The same principle applies to external content supplied to a model. Documents, webpages, emails, and user messages can contain malicious or misleading instructions. The surrounding application should enforce authorization and business rules rather than expecting the model to police itself.
Log actions people may need to reconstruct
When something goes wrong, teams need to know which account acted, what workflow version was running, what system was called, and what action occurred. Logging should support investigation without unnecessarily reproducing sensitive content. Access to logs should itself be controlled.
Plan for vendors and supply-chain risk
Understand the providers involved in the workflow and what happens when they change. Review relevant security terms, data handling, subprocessors, authentication options, incident processes, and service dependencies. NIST CSF 2.0 includes governance and supply-chain considerations that can help organizations structure this work.
Have a safe failure mode
An unavailable model, expired credential, broken integration, or suspicious output should not leave the business process in an unknown state. Decide whether work should pause, fall back to a manual queue, retry under controlled conditions, or alert an owner.
NIST CSF 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover. AI automation does not replace those fundamentals. It makes disciplined application of them more important because software may be acting across systems at machine speed.