Client-owned systems
Production workflows use your business accounts and workspaces wherever practical.
Security and data
Useful automation without giving up control
Security is not a paragraph added at the end. Access, data, actions, approvals and fallback are designed into the workflow from the start.
Core controls
Proportionate, practical and easy to understand
The exact controls depend on the information involved and the consequence of a mistake.
Least access
Use named accounts, limited permissions and time-bound access rather than shared passwords.
Only needed data
Use the minimum information required for the agreed outcome and avoid unnecessary copies.
Human approval
Keep sensitive messages, exceptions and consequential actions behind an authorised person.
Test before trust
Use realistic examples, known edge cases and clear acceptance checks before launch.
Fallback and stop route
Make it clear what happens when information is missing, confidence is low or a system fails.
AI-specific controls
AI does not get unlimited freedom
AI-assisted workflows need clearer boundaries because the output can vary. The system should know what it may use, what it may do and when it must stop.
- Ground output in approved sources where accuracy matters
- Treat emails, documents and web content as untrusted input
- Limit the tools and actions available to the workflow
- Retest after material changes to models, prompts, sources or permissions
Access and credentials
Use business identities, not passwords in email
Access should be granted through the client’s normal administration route wherever possible.
Preferred approach
- Named business accounts
- Multi-factor authentication
- Minimum permissions
- Access removed or reduced after handover
Recorded for each workflow
- Owner and users
- Approved data sources
- Permitted actions and approvals
- Fallback, support and review status
Plan for failure
A useful system can still go wrong
Third-party services fail, data changes and unusual cases appear. Important workflows need visible errors, a manual route and someone who knows what to do next.
DetectMake failures and uncertain output visible
StopPrevent unsafe or repeated action
RecoverUse a clear manual fallback
ReviewLearn from incidents and update the workflow
Straight answers
Security and data FAQs
Will OxTech Automation need administrator access?
Sometimes, but only where the agreed build requires it. The preferred route is limited, business-owned access that can be removed or reduced after handover.
Will our data be used to train public AI models?
That depends on the selected platform, account type and settings. I review the agreed data route and business workspace before use; the client approves the platform and contract.
Do you provide a data-processing agreement?
Where OxTech Automation processes personal data on a client’s behalf, the commercial documents should define roles, instructions, security expectations and return or deletion.
Does this page guarantee security?
No. It explains the implementation approach. Formal legal, cybersecurity, regulatory or penetration-testing assurance may require an appropriate specialist.
How do I report a security concern about this website?
Email security@oxtechautomation.com with the affected page, what you observed and how it can be reproduced. Please do not include unnecessary personal or confidential information.
Start with the consequence
What would happen if the workflow made a mistake?
That answer helps set the right access, approval, testing and fallback.
Start with one repeated task
Clear limits before launch.