Review the data-security approach
See how BaristaLabs scopes source data, least-privilege access, vendor/model assumptions, retention, and rollback before sensitive workflow work moves toward production.
Read the data security pageBrewing...
Brewing...
AI workflow security review worksheet
Use this worksheet to map what an AI workflow may read, which vendors or models see the data, what it may draft or change, who approves risky steps, what gets logged, and how your team can roll back a mistake.
Best fit for support triage, appointment intake, CRM notes, document extraction, website updates, finance/admin review, and other workflows where AI gets close to customer records or business systems.
Review packet preview
Reviewer sees
Source evidence, proposed action, policy rule, risk reason, before/after preview, and approve or escalate decision.
An AI workflow security review should start with one named workflow, not a general argument about whether AI is safe.
The useful question is smaller: for this workflow, what data boundary is needed, what data is excluded, which systems are touched, which actions are allowed, which actions require approval in a review queue, what evidence appears in the queue, and what record after the run will exist?
Write those answers down before choosing broader permissions. The worksheet can become the implementation brief for the builder, the review packet for security or compliance, and the operating reference for the workflow owner. It also connects the data-security questions to the broader responsible AI operating model the team uses for approvals, receipts, rollback, and expansion.
Copy-paste artifact
Copy this into a working document. Fill it out for one workflow before the workflow receives production credentials, broad source access, or permission to write into a system of record.
What to write: Name the repeatable workflow in one sentence.
Security review question: What exactly are we reviewing?
What to write: Name the person or role accountable for the workflow outcome.
Security review question: Who owns the business risk after launch?
What to write: Name who implements and maintains the workflow.
Security review question: Who can change access, logs, prompts, integrations, and rollback behavior?
What to write: Form submission, ticket, CRM change, email, uploaded document, scheduled job, manual request, or API event.
Security review question: Why does the workflow start, and can false triggers happen?
What to write: Help desk, CRM, inbox, CMS, database, file store, billing tool, calendar, internal app, or third-party API.
Security review question: Which systems need access review?
What to write: List the records, fields, documents, messages, excerpts, or embeddings the workflow may use.
Security review question: What minimum data is required?
What to write: Public, internal, confidential, customer data, regulated data, financial data, health data, legal data, HR data, credentials, or mixed.
Security review question: How sensitive is the data involved?
What to write: Name what the workflow must not read: unrelated customer records, credentials, payment details, medical/legal/HR notes, broad drives, private margin notes, or old exports.
Security review question: What is outside the boundary?
What to write: Client-owned account, service account, OAuth scope, read-only token, write token, admin access, or temporary access.
Security review question: Is the workflow least-privilege enough for v1?
What to write: List AI model providers, vector stores, automation tools, APIs, storage providers, and whether data leaves the client's environment.
Security review question: Which vendors or services see the data?
What to write: Document vendor settings, project retention, logging, deletion, and whether data may be used for model training.
Security review question: What happens to data after the run?
What to write: Exact systems, records, fields, documents, or knowledge bases the workflow may read.
Security review question: What can the workflow see?
What to write: Replies, summaries, notes, categories, extracted fields, routing suggestions, website copy, or review packets the workflow may prepare without execution.
Security review question: What can the workflow prepare safely?
What to write: Only low-risk, reversible actions after testing; include limits and stop conditions.
Security review question: What autonomy is allowed in v1?
What to write: External messages, CRM/system-of-record updates, publishing, refunds/credits, access changes, status changes, or sensitive escalations.
Security review question: Where must a person approve first?
What to write: Legal/medical/financial advice, hiring decisions, credential sharing, irreversible deletion, pricing promises, contract terms, regulated determinations, or unsupported public claims.
Security review question: What stays manual?
What to write: Name who approves, edits, rejects, or escalates proposed actions.
Security review question: Who is the human control point?
What to write: Source record, excerpts, proposed action, before/after preview, policy rule, risk reason, confidence/routing signal if used, and rollback note.
Security review question: Can the reviewer make an informed decision?
What to write: Sensitive fields, angry customer, legal/security/refund language, conflicting records, missing source, high dollar amount, regulated data, public claim, or low confidence.
Security review question: What stops automation?
What to write: Run ID, trigger, source IDs, data boundary note, proposed action, policy check, reviewer decision, final action, destination system, timestamp, model/tool version, rollback path.
Security review question: Can the team reconstruct what happened?
What to write: Where logs/receipts live, who can access them, how long they stay, deletion trigger, export/handoff expectation.
Security review question: Does the record become an unmanaged data store?
What to write: Correction email, restore record, revert publish, reopen ticket, revoke access, amend CRM note, notify security/compliance, or incident owner.
Security review question: How can the team unwind a mistake?
What to write: First 25 records, first 50 tickets, first two weeks, or all items until reviewed by the owner.
Security review question: How will the pilot earn more permission?
What to write: Anything unresolved before launch.
Security review question: What must be answered before production access?
Need approval rules too?
The security worksheet maps what the workflow touches. The approval policy decides what the workflow may do with that access, when a person must approve, and what stays manual.
Use the approval policy worksheetThis example stays approval-gated. The workflow reads a new support ticket, checks limited customer context, drafts a response, suggests a category, and prepares a CRM note. A person reviews before anything is sent or written to the system of record.
Example: Triage and draft reply for new customer-support tickets.
Example: Support operations lead.
Example: Internal automation owner or BaristaLabs implementation lead.
Example: New support ticket created in the help desk.
Example: Help desk, CRM, approved support knowledge base, email platform after approval.
Example: Ticket subject/body, customer ID, plan tier, open-ticket count, last support note for the same account, relevant approved KB article.
Example: Customer data, internal support notes, potentially sensitive account context.
Example: Payment card details, unrelated customer records, credentials, private sales notes, HR/legal notes, broad CRM exports.
Example: Read-only help desk/CRM access for draft preparation; send/update permissions held behind reviewer action.
Example: Model receives ticket text, limited account context, and approved KB excerpts. No broad CRM export. Vendor/model settings must be documented before launch.
Example: Use project-approved model settings. Do not store unrelated ticket excerpts in workflow logs. Follow help desk retention for support records unless security/legal sets a stricter rule.
Example: Current ticket, same-account recent support note, plan tier, approved support KB.
Example: Draft reply, suggest support category, list missing information, prepare CRM note for review.
Example: Create internal review packet only. No customer message, CRM note, refund, status closure, or escalation change.
Example: Send customer reply, save CRM note, close ticket, escalate to billing/security/account owner.
Example: Promise refund, quote legal terms, approve cancellation exception, request credentials, discuss another customer's data, mark the issue resolved without review.
Example: Support lead or trained support reviewer.
Example: Original ticket, relevant KB excerpt, customer context shown, draft reply, CRM note preview, risk reason, and approval rule.
Example: Refund language, security/access issue, angry customer, legal threat, account cancellation, conflicting CRM notes, missing source evidence, regulated-data mention.
Example: Ticket ID, run ID, sources shown, draft reply, policy check, reviewer edits, final sent message, CRM note, reviewer ID, timestamp, correction path.
Example: Receipt stored with the ticket/CRM activity. Do not create a separate store of unrelated customer context.
Example: Reviewer can send correction, amend CRM note, reopen ticket, escalate to support/security owner, and attach correction note to the receipt.
Example: Review first 50 tickets and all escalated tickets before considering any low-risk auto-tagging.
Example: Confirm whether support tickets may include regulated data; confirm model/vendor setting; confirm who can approve retention exceptions.
Before production access
If the workflow can send, update, publish, or touch sensitive records, the approval queue should show the evidence a reviewer needs before execution.
Read the approval queue guideA workflow that drafts an internal summary does not need the same review as one that changes customer records, sends external messages, handles credentials, or touches regulated data.
Use the lightest review that still lets a reasonable owner explain what happened and recover from a mistake. When the workflow touches customers, records, money, access, public claims, or regulated work, keep review and receipts visible until the failure modes are understood.
Security review emphasis: Confirm source data, owner, draft-only boundary, and whether logs contain sensitive material.
Security review emphasis: Require reviewer evidence, approved final message, correction path, and receipt.
Security review emphasis: Require before/after preview, approver, destination field, restore path, and receipt tied to the record.
Security review emphasis: Require explicit business policy, approval role, reconciliation path, and careful exclusion of sensitive payment data unless the system is designed to hold it.
Security review emphasis: Require least privilege, approver, expiration/revocation path, security escalation rule, and no credential exposure in prompts or logs.
Security review emphasis: Require source evidence, reviewer, approved final copy, publish target, rollback/revert link, and claim-safety review.
Security review emphasis: Involve the client's legal, privacy, compliance, security, or operational stakeholder before production use. Document retention, access, escalation, and review requirements.
The first production version should usually be narrower than the demo. Keep the stop line visible. If the workflow cannot show its source evidence, explain its proposed action, route to the right reviewer, leave a useful receipt, or offer a rollback path, it is not ready for more autonomy.
Common v1 manual-only actions include refunds, contract language, medical or legal advice, account access, credential handling, deleting records, final hiring or HR decisions, unsupported public claims, and anything a reviewer cannot unwind cleanly. A shadow week can reveal which actions deserve more review before launch.
Related resources
See how BaristaLabs scopes source data, least-privilege access, vendor/model assumptions, retention, and rollback before sensitive workflow work moves toward production.
Read the data security pageTurn the worksheet into operating rules for what the workflow may read, draft, change, send, escalate, log, and roll back.
Use the approval policy worksheetGive reviewers the proposed action, source evidence, risk reason, policy rule, and final execution record before risky work leaves the queue.
Read the approval queue guideLog what started the run, what the workflow saw, what it proposed, who reviewed it, what happened, and how the team can correct it later.
Copy the agent receipt templateUse the worksheet as an input to a process-automation or AI-consulting conversation before broad permissions are granted.
No. This worksheet is an implementation-planning artifact, not legal advice, a compliance guarantee, or a certification claim. Regulated or sensitive workflows should involve the client's legal, privacy, compliance, security, or operational stakeholders before production use.
No. The worksheet makes the boundary visible so the right people can review it. The actual security posture depends on the implementation, vendors, permissions, hosting stack, data handling, monitoring, and operating process.
Yes, if the workflow touches sensitive systems. The worksheet exposes platform requirements that a demo may hide: permission scopes, vendor data handling, evidence display, approval routing, audit logs, retention controls, and rollback support.
That should be documented for the specific project and vendors involved. For client deployments, BaristaLabs favors vendor and model settings that keep client data out of public model training, and the worksheet should name the expected setting before production use.
No. Low-risk, internal, reversible actions may become safe to automate after testing. Customer-facing, financial, access-related, regulated, public, irreversible, or ambiguous actions should stay under review until the workflow has evidence that more autonomy is safe.
Treat unresolved security, legal, privacy, compliance, vendor, retention, or rollback questions as launch blockers for production access. The workflow can often continue as a prototype or shadow-week test while those answers are collected.
The worksheet defines what should be logged. The agent receipt is the run record left behind after the workflow drafts, routes, updates, sends, publishes, or proposes action.
Security review for one workflow
BaristaLabs helps teams define source data, vendor/model assumptions, approval gates, receipt fields, retention expectations, and rollback paths before AI workflows touch real customer or regulated work.