How we handle security and access.
Before a workflow uses live business information, we agree on where that information goes, who can access it and what the system is allowed to change.
Access only to what the job needs
The setup plan identifies each user or service account and the records it needs. Access must be approved by an authorized customer administrator. We require multi-factor authentication where supported and prefer customer-owned accounts when they fit the project.
Credentials belong in an approved secrets store, not in prompts, website forms or source code. Client workspaces and connections need separate access controls. Before live use, testing must confirm that a user cannot retrieve another client's records or restricted information within their own business.
Know where information goes
We document the information a workflow reads, where it is processed and which hosting or AI providers are involved. Only the information needed for the task should be included. The plan must cover encrypted connections and storage, retained logs, backup copies, retention periods and deletion arrangements.
Provider terms and settings must be checked for the selected product and account, including whether submitted information may be used for model training. We do not assume that every service has the same data policy. Sensitive records need a separate assessment before they are introduced.
You decide what the workflow may change
A first project can start read-only or draft-only. Sending a message, creating a booking, changing a record or publishing content requires a defined permission and approval process. An approval must apply to the current details; changing those details must invalidate it.
Permission and action checks belong in the software, not just in an instruction asking AI to behave. An incoming document or email must not be able to grant additional access. Testing includes unauthorized requests, conflicting information, duplicate actions and failed connections.
Payments, banking changes, destructive edits and regulated decisions are not included by default.
A clear response when something goes wrong
Failed steps should create a visible exception, not a false success message. The agreed record of activity should show what ran, which sources and approvals were used, and whether the destination accepted the action, without copying unnecessary confidential material into logs.
Support hours, response expectations, incident contacts and recovery steps are agreed in writing. Where a workflow stores important state, its recovery plan needs a tested restore or a documented manual fallback. Updates are tested before they reach live work.
A suspected data exposure calls for stopping the affected workflow, reviewing and revoking access where needed, and following the agreed incident plan. Notification responsibilities are set by the contract and applicable requirements.
What you receive and how access ends
Your handoff includes the agreed access and data-handling record, test results, operating instructions, support responsibilities and offboarding steps. Your team should know how to pause the workflow and who can authorize a change.
Offboarding covers revoking connections, returning agreed materials and applying the retention and deletion arrangements. Ownership and usage rights for configured workflows, reusable components and third-party software are stated in the project scope rather than assumed.
What this does not promise
No setup can promise perfect security or error-free AI. We do not claim a security certification or suitability for sensitive or regulated work without the required assessment. A provider's security features do not certify our implementation.
If access, data handling or action controls cannot be verified, the workflow stays out of live use. The specific controls, responsibilities and limits belong in the written project agreement.
For this website's own browser and hosting behavior, read the preview privacy notice. Our testing page separates existing fictional exercises from production evidence.