Secure every stage of an AI workflow.

Map the user interface, identity layer, source systems, retrieval service, model, tools and output destination. Mark where data and instructions cross a trust boundary. Include the administrative paths used to maintain the system.

This provides a shared view for application, data and security teams. It also helps distinguish a read-only assistant from a workflow that can update a system or send information elsewhere. The consequences of an error differ substantially.

Document whose identity is used for each connection. A service account with broad access can change the effective boundary even when the front-end user has limited permissions. Review both the intended access model and its actual enforcement.

Documents and web pages can contain instructions that are irrelevant or hostile to the intended task. A workflow should preserve the distinction between trusted application instructions and untrusted content supplied for analysis.

Prompt injection is one of the risk categories covered by the OWASP project for large language model applications. Use that resource to support a broader review; a checklist alone does not establish that a particular implementation is secure.

Include content from attachments, extracted files and connected systems in the review. Its origin may affect how much trust the application can place in it. Keep the instructions governing the application separate from material being summarised or searched.

Define each tool’s permitted operations and the minimum access needed for the task. Enforce authorisation in the application and connected systems. Do not rely on the model to make access-control decisions.

For consequential actions, specify the human review step and show the reviewer what is about to happen. Separate drafting a proposal from sending it, and preparing a change from applying it. Limit the scope of actions that can happen without review.

Check the parameters passed to each tool as well as the tool name. Permission to update one approved record should not become permission to update an arbitrary record selected by generated text. The connected system remains an enforcement point.

Decide where generated output will go. Text intended for a person requires different handling from content passed into a command, query, browser or business system. Validate outputs according to their destination and intended use.

Prepare failure cases and recovery procedures. Test attempts to access unauthorised material, misuse tools and bypass review. Log enough to investigate problems while applying the organisation’s data-handling requirements. The appropriate safeguards should follow a scoped assessment of the implementation.

Agree which operational details are necessary to investigate a failure, who can access them and how long they are retained. Avoid collecting full source documents or sensitive prompts by default when a smaller record supports the operating need.

Illustrative example: a workflow prepares an email from a report. The review step should show the proposed recipient, message and attachments before anything is sent. Approval of a draft should not silently authorise a different recipient or a later change to the attachments.

Define which changes require a new review and enforce that rule in the application. Give the reviewer an explicit way to reject or revise the action. This turns “human in the loop” into a decision a person can understand and exercise.

Choose one end-to-end task and review it with the application, identity, data and security owners. Start with the user’s permissions and trace every source, tool and destination the request can reach. Record the controls that enforce a boundary and the evidence needed to confirm that they work.

Include a document that contains irrelevant instructions, a user who lacks access to a source and a tool request outside the approved operation. Define the expected behaviour before testing. The result should make it clear whether the application refused access, limited the action, requested a review or stopped the workflow.

For a workflow that can take action, inspect what the reviewer actually sees. A button labelled Approve is insufficient context if the target record, recipient or proposed change remains hidden. The approval should apply to the specific action the application will execute. Changed action details may need a new review.

Finish with a recovery exercise. Confirm who can disable the affected capability, how a reported incident reaches the responsible team and which records support investigation. Capture open issues with owners and acceptance criteria. This produces a practical improvement plan for the next release.

A new integration can change a workflow’s capabilities without changing its visible interface. Review changes to tools, source access, model configuration and user groups before expanding a release. Our cybersecurity services can help scope the assessment and prioritise the work.