Security
Last updated: September 2026
Security is fundamental to everything we build at Flitch Solutions Pty Ltd ABN 57 682 821 512 of 191 St Georges Terrace, Perth, WA 6000, Australia (“Flitch”). This page describes our security practices, infrastructure, and how we protect your data.
1. Overview
Here's a quick summary of our security practices:
- Encrypted: All data encrypted in transit and at rest.
- Secure Infrastructure: Built on AWS with industry best practices.
- Privacy by Design: No training on your data by AI providers.
- Access Controls: Role-based permissions and secure authentication.
2. Infrastructure Security
Our infrastructure is built on trusted cloud providers with robust security practices:
Amazon Web Services (AWS)
Primary hosting infrastructure. AWS maintains SOC 2, ISO 27001, and other compliance certifications.
Neon (PostgreSQL)
Database hosting with automated backups, encryption at rest, and secure network isolation.
Vercel
Application hosting with automatic HTTPS, DDoS protection, and edge network security.
Stripe
PCI DSS Level 1 certified payment processing. We never store card numbers.
3. Data Encryption
Encryption in Transit
All data transmitted between your browser and our servers is encrypted using TLS 1.2 or higher. We enforce HTTPS for all connections and use HSTS to prevent downgrade attacks.
Encryption at Rest
All data stored in our databases and file storage is encrypted at rest using AES-256 encryption. Database backups are also encrypted.
Credential Security
We do not store usernames or passwords. All authentication is handled through OAuth providers (Google and Microsoft), meaning your credentials remain securely managed by your identity provider.
4. AI Provider Security
When you build with AI, your prompts are processed by AI providers. Here's how we ensure your data remains secure:
Zero Data Retention for Training: We reach every model through a commercial API, which means your data is not used for model training. This is contractually guaranteed by those API agreements. Inference runs on Anthropic and Google, on OpenAI or xAI where a team selects them, and on Amazon Bedrock when a provider is unavailable; the same terms apply on each.
Anthropic (Claude)
- No data retention for training via API
- SOC 2 Type II certified
- Enterprise security controls
Google (Gemini)
- No data retention for training via API
- Enterprise-grade security
- ISO 27001, SOC 2 certified
Amazon Bedrock
- Runs the same Claude models when the primary provider is unavailable
- No data retention for training per AWS service terms
- ISO 27001, SOC 2 certified
Replicate
- Icon generation only
- Receives the text prompt describing the icon, never your data
Every processor we use, what it handles and how transfers are covered, is listed at flitch.io/sub-processors.
5. Authentication & Access Control
Authentication
We use OAuth-only authentication, meaning we never handle or store your passwords:
- Google OAuth: Sign in securely with your Google account.
- Microsoft OAuth: Sign in securely with your Microsoft account.
- Single sign-on: On the Business plan, sign in through your own identity provider. Okta and Microsoft Entra are supported over both SAML and OIDC.
Single sign-on and multi-factor authentication
Flitch does not run its own second factor, and stores no passwords at all. Authentication is delegated, so the controls you already enforce are the controls that apply:
- Your multi-factor policy, conditional access rules, device compliance requirements and session lifetimes apply to Flitch unchanged.
- Removing someone in your identity provider removes their way of signing in to Flitch. There is no separate Flitch password to revoke. API keys are the exception, and are covered below.
- Single sign-on only becomes active once you prove ownership of your email domain with a DNS record, so nobody can claim a domain they do not control.
- A provider is scoped to one business and routes only the domain it has verified.
- SAML is configurable to what your provider requires: signed authentication requests, encrypted assertions, and multiple signing certificates for rolling a certificate over without downtime. Ask and we will enable them for your connection.
API keys and offboarding
An API key belongs to the team rather than to the person who created it, so that a departure does not silently break an integration that the team depends on. That has a consequence worth stating:
- Removing someone from your identity provider does not revoke a key they issued. The key keeps working until a team admin revokes it, which they can do at any time from Settings, API Keys.
- Only team admins can issue or revoke keys, and every key names the person who created it, so the list doubles as the offboarding checklist.
- Keys can be given an expiry when they are created, which is the simplest way to make this self-correcting.
- A key reaches only the datasets it was granted, never every dataset in the team, and never anything outside the team it belongs to.
- The audit-log scope is the exception to all of the above: it is re-checked against its creator on every request, so it stops working the moment they are no longer a business admin.
Session Security
- Secure, httpOnly session cookies
- Automatic session expiration
- Session management through account settings
Team Access Controls
Team accounts support role-based access control with admin and member roles. Admins can manage team members and control access to what the team builds.
Audit logging
On the Business plan, a business admin can read and export everything that happened across every team they own:
- Sign-ins, membership and role changes, sharing and publishing, data source and credential changes, and billing events, each with the person, the time and the outcome.
- Export as CSV, JSON Lines, or OCSF, the schema AWS, Splunk and CrowdStrike built together, so it lands in your SIEM without a parser written for us.
- A polling API for continuous ingestion, delivering each event exactly once.
- Events are kept for 365 days.
When Flitch support needs access
Our staff cannot let themselves into your space. Support asks, an admin of that space approves, and the access expires by itself. Every request, approval, refusal and entry is written to your own audit log, and you can end it at any time. In an emergency, such as nobody being able to sign in to approve, access can be opened without waiting: it lasts one hour, you are emailed the moment it happens, and it is recorded the same way.
6. Application Security
We follow security best practices in our application development:
Security Headers
- Content Security Policy (CSP)
- X-Frame-Options (clickjacking protection)
- X-Content-Type-Options
- Strict-Transport-Security (HSTS)
- X-XSS-Protection
Security Practices
- Input validation and sanitisation
- Parameterised database queries
- CSRF token protection
- Rate limiting on sensitive endpoints
- Regular dependency updates
7. Workflow Security
A workflow is work your space does on its own: it runs on a clock with nobody watching, and it can send email, call addresses you set, and run SQL somebody on your team wrote. Each of those is controlled, and here is how.
Calling an address
- Private addresses are refused. Before a webhook or an API step calls an address, the host is resolved and every private, loopback, link-local and cloud metadata address is refused, including a public name that resolves to one. A refusal never repeats the address, because one often carries a token in its path and your run history is readable by your whole space.
- Checked on every run, not on save. A name that resolved to a public address yesterday can point somewhere else today, so the check runs each time rather than once when the step was written.
- Redirects are not followed. A response redirecting to a private address would walk straight past the check just made, so a redirect ends the call instead.
- A webhook secret is write-only. A secret header you set so the far end can be verified is stored and never shown again, and it is stripped from any copy of the workflow, so duplicating one never hands its credential to whoever pressed duplicate.
Sending email
- Only members of your space. An email step reaches people in your own space and nobody else. Asked to email each customer their own row, it refuses at run time rather than sending.
- Nothing is sent twice. A step that sends keeps a watermark, so a nightly send does not resend yesterday's rows. A run that sent some rows and then failed is reported as partly done rather than failed, because nothing sent can be taken back and a retry would send the first ones again.
Who can start a run
- A dashboard cannot reach a workflow unless you say so. A workflow is reachable from a dashboard or app only when it carries the trigger that allows it. Without that, no published page can start it. It is off until somebody adds it.
- A published page gates runs twice. A signed-in reader is someone we can name; an anonymous visitor is asked to sign in. Allowing anyone to run it is a separate setting that is off until you turn it on, and either way runs are rate limited per caller.
- A run belongs to whoever built the workflow. Runs are authorised and billed against the workflow's owner rather than whoever pressed the button, which is also why a workflow whose owner has left the space is reachable by nobody.
What is recorded, and what stops
- Every run keeps a trace. Step by step: what arrived, what left, and a sample of the rows. For a step that acted on the outside world it records what was sent, naming the host rather than the full address. A run started by a schedule records nobody as the actor, because nobody was watching; one a person started records them.
- A failing workflow is switched off. After repeated consecutive failures it stops running on its schedule and its owner is emailed the reason, so a broken integration does not retry indefinitely and does not fail silently.
- SQL runs away from every credential. A query written in a workflow runs in a separate service rather than in the worker, because the worker holds database, file store and model credentials and a query somebody wrote should run beside none of them. It runs in a locked database engine: a single SELECT, verified by the engine's own parser, with network and filesystem access switched off, no extensions, a memory ceiling, nothing written to disk, and the configuration locked so the query cannot turn any of that back on.
What each step does, and the limits on a run, are documented at docs.flitch.io.
8. Data Isolation
We implement strict data isolation to ensure your data remains private:
- Multi-tenant architecture: All data is scoped to your account or team.
- Database-level isolation: Queries are always filtered by account/team ID.
- API access checks: Every API request validates access permissions.
- File storage isolation: Uploaded files are stored in account-specific paths.
9. Data Breach Response
In accordance with the Australian Notifiable Data Breaches (NDB) scheme, we maintain incident response procedures:
- Detection: We monitor for security incidents and anomalous activity.
- Assessment: We assess potential breaches within 30 days as required.
- Notification: If a breach is likely to cause serious harm, we notify affected individuals and the OAIC as soon as practicable.
- Remediation: We take immediate steps to contain and remediate any breach.
10. Vulnerability Reporting
We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly:
Report vulnerabilities to:
[email protected]Please include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Any suggested fixes (optional)
We commit to acknowledging reports within 48 hours and will keep you informed of our progress. We ask that you give us reasonable time to address vulnerabilities before any public disclosure.
11. Compliance
Flitch holds neither a SOC 2 report nor ISO 27001 certification today. Both are planned. Where those certifications appear elsewhere on this page, they refer to our infrastructure and AI providers, not to Flitch.
What we can give you now is specific rather than certified: the isolation model above, what we encrypt and where, the full list of sub-processors that touch customer data, our data processing agreement, and how sign-in behaves when it runs through your own identity provider.
If your review needs something not covered here, ask and we will answer it directly rather than pointing you at a report. Support response targets and contractual commitments are agreed per contract on Enterprise.
12. Contact Us
If you have questions about our security practices or want to report a security concern, please contact us:
Email: [email protected]
Address: 191 St Georges Terrace, Perth, WA 6000, Australia
For information about how we handle your data, please read our Data Use & Privacy page and Privacy Policy.
Security FAQ
Common questions about how Flitch protects your data.