Security & trust
Your data is yours. We keep it that way.
Sysflows is built for teams that handle real customer relationships. Every organisation gets its own isolated database, all credentials are encrypted at rest, and every AI suggestion is human-confirmable, not autonomous by default.
How we protect your data
The key technical commitments, in plain language.
Database-per-tenant isolation
Your organisation gets its own database, not a shared table with a tenant ID column. Queries from other accounts cannot reach your data, by design.
Data residency
Choose where your data lives: US, EU, or Australia. Your selection is set at account creation and determines where your database is hosted, where background processing runs, and which regional AI endpoint serves your account.
SSO / SAML
Connect your identity provider using SAML 2.0. Available on Pro. Agents sign in through your existing directory; Sysflows never stores their passwords.
Audit logs
Every significant action (ticket changes, settings edits, agent invites, data exports) is recorded with a timestamp and actor. Available on Pro.
Role-based access control
Built-in and custom roles control what each agent can see and do. Multi-role assignment is supported. Access is least-privilege by default.
Encryption of stored secrets
Connector credentials, mailbox passwords, and SMTP details are encrypted at rest. They are never stored in plaintext or written to application logs.
Human-in-the-loop AI
Every AI suggestion (draft replies, triage decisions, summaries) is shown to an agent for review before it does anything. No action is taken without a human confirming it, unless you explicitly configure autonomous trust on a specific AI Agent.
Frontier models via Amazon Bedrock
AI features run on your choice of models, including Anthropic Claude and GLM, accessed through Amazon Bedrock in the region that matches your data residency: N. Virginia for US, Ireland for EU, Sydney for Australia. Your data is used only to generate responses for your account. It is not used to train foundation models.
Governed MCP, both directions
MCP is off by default and Pro-only. Outbound calls pass one audited boundary that blocks internal-network targets and caps volume; inbound access uses scoped, instantly-revocable tokens that can never do more than the person they belong to. Every call is logged without storing the payload.
Billing through Stripe
Card details are never transmitted to or stored on Sysflows servers. Payment is handled entirely by Stripe's embedded Payment Element, which is PCI-compliant.
AI that you control
AI is included in every plan, but it is never automatic unless you choose that.
Per-feature opt-out
Each AI capability (draft replies, auto-triage, thread summaries, spam classification, knowledge search) has its own on/off toggle in your settings. Turn off any feature you do not want to use. There is also a master switch that disables all AI for your account at once.
Every suggestion is confirmable
When AI proposes a draft reply or a triage decision, the agent sees it and decides what to do next: edit, accept, or discard. Nothing is sent or applied without a deliberate human action, unless you explicitly set a named AI Agent to "trusted" for a specific skill.
How AI data is handled: Ticket content sent to the AI is processed through Amazon Bedrock, in the AWS region matching your data residency, to generate suggestions for your agents. Sysflows does not share your data with third parties for advertising or model training. Token usage is logged to your account's usage ledger and is visible in your billing dashboard.
Common questions
How is my data isolated from other customers?
Each organisation gets its own database, provisioned from a template at account creation. There is no shared schema with a tenant filter. A bug in the application layer cannot accidentally return another customer's records, because the connection itself is scoped to your database.
What does "data residency" cover?
When you choose US, EU, or AUS at signup, your primary database and background workers are provisioned in that region. This covers ticket data, cases, contacts, files, and conversation history. AI processing is covered too: calls go to the Amazon Bedrock endpoint in the matching region (N. Virginia for US, Ireland for EU, Sydney for AUS), so ticket content sent to the AI stays in-region. Some third-party services (such as Stripe for billing) operate from their own infrastructure; their data handling is governed by their own terms.
Can Sysflows staff see my tickets or customer data?
Sysflows staff do not have routine access to your account data. A super-admin console exists for platform operations (plan management, provisioning), but access to individual account content requires deliberate action and is logged. We do not browse customer data for any purpose other than investigating a support request you have raised.
Does AI use my data to train models?
No. Content sent to the AI is processed through Amazon Bedrock only to generate a response for your account in that session. Amazon Bedrock does not use your inputs or outputs to train models and does not share them with the model providers. Sysflows does not fine-tune or retain your data for any AI training purpose.
What happens if I exceed my AI token allowance?
You receive alerts at 80% and 100% of your monthly token allowance. Once the allowance is exhausted, AI features that require token consumption are paused, and no automatic overage is charged. If you want to continue using AI that month, you can opt in to a top-up ($20 per 1M additional tokens) from your billing settings. You decide before any extra spend occurs.
How is MCP access controlled?
MCP (the Model Context Protocol) is a Pro-only feature, off by default. When your agents or workflows call an external MCP server, every call goes through a single egress boundary that requires HTTPS, refuses to connect to private or internal network addresses, applies a timeout, enforces a per-month call cap, and writes a payload-free audit record. When an external MCP client connects into Sysflows, it authenticates with a scoped Personal Access Token bound to one person and tenant: its effective access is the intersection of the token's scopes and that person's own permissions, so a token can never do more than the human behind it. Tokens are stored hashed, shown once, and can be revoked instantly by their owner or an admin. As with any external connection, once data leaves your boundary the receiving system governs it: we make that grant deliberate, scoped, capped, and audited, and we say so plainly at the point you create a token.
Is there a security hardening roadmap?
Yes. Planned work before general availability includes public-form and chat anti-spam measures (honeypot fields and rate limiting), CSP header hardening, portal session and cookie review, and additional rate limits on the login and signup surfaces. We publish our roadmap honestly: if something is not yet built, we say so.