How the platform is built, and what we do not claim
Architecture and process, described concretely. Where a claim would need an independent audit we have not had, this document says so rather than implying the audit exists.
Last updated
1. What this page does not claim
Starting here, because it is the part most vendor security pages leave implicit. SentryFlow holds no SOC 2 report, no ISO 27001 certificate, and no DPDP certification — the last of which does not exist as a thing to hold. Nothing on this site should be read as an attestation, and any badge suggesting otherwise would be dishonest.
What follows is a description of design decisions and operational practice. It is the sort of material that would be tested during a real audit, and it is offered so you can evaluate the architecture on its merits rather than on a logo.
2. Credential handling
Connector credentials are encrypted with a per-tenant data key, itself wrapped by a key in a managed KMS that you can control. Key custody is the important detail: where you hold the key, you can revoke our ability to decrypt without waiting on a support ticket.
Scope is declared by the workflow rather than granted at the account level, so two workflows sharing an integration do not share its permissions. Adding a step that needs a wider scope triggers a fresh consent naming the specific addition, and revoking a credential affects one workflow rather than every workflow that touched the integration.
3. Tenancy isolation
Tenant data is separated at the storage layer with row-level policies keyed on tenant identity, and every query path carries that identity rather than deriving it from application state. Execution runs in per-tenant contexts so one workflow cannot observe another's payloads.
Processing region is a per-workflow field, including for model inference. A workflow pinned to an India region cannot be relocated by an account-level settings change.
4. Access control, ours and yours
Inside your workspace, access is role-based, and approval gates can require that two approvers be distinct named users so segregation of duties is enforced by the workflow rather than by the org chart.
On our side, production access requires hardware-backed multi-factor authentication, is granted for a defined window rather than standing, and is logged. Engineers do not read customer payloads to debug: parked runs expose their inputs to you, not to us, and a support request that genuinely needs our eyes on data requires your explicit grant.
5. Audit integrity
Every run, edit, approval, and denial is written with actor, resource, and outcome. Entries are append-only, and each includes a digest of its predecessor, so altering or deleting one breaks verification at that point. The verification tool reports the first broken link rather than a bare pass or fail, which is what makes the result actionable.
This makes tampering detectable, not impossible. That is the achievable property, and claiming more would be the kind of overstatement this page is trying to avoid.
6. How changes reach production
Changes require review by someone other than the author, pass automated checks including dependency and secret scanning, and are deployed through a pipeline that no engineer can bypass manually. Scope review is part of shipping any feature that touches a connector, handled by whoever is building it rather than by a separate team that arrives at the end to say no.
Dependencies are pinned to exact versions. Automated upgrade proposals are reviewed rather than merged on green, because a passing test suite does not tell you what a new transitive dependency does.
7. Incidents
We maintain a runbook naming who decides to notify, because deciding that during an incident is the slowest possible time to decide it. Where a breach affects your data we notify you with what we know, what we do not yet know, and what we are doing — an initial notification that admits uncertainty is more useful than a delayed one that sounds complete.
We rehearse this. A notification process first exercised during a real incident fails during a real incident.
8. Reporting a vulnerability
Write to security@sentryflow.tech. Reports are acknowledged within 24 hours, every day of the week, and read by the security team directly rather than by a triage queue.
We will not threaten or pursue legal action against anyone reporting in good faith, and we do not require you to sign a disclosure agreement before reporting. We ask only that you give us reasonable time to fix an issue before publishing, and that you avoid accessing other customers' data while investigating — if you need to demonstrate impact, tell us and we will arrange a way to do it safely.