Server-side data access
Tenant-bearing reads go through workspace-scoped server routes and shared DAL helpers. Supabase service-role access is backend-only.
Trust & security
A concrete trust story for single-tool workflow operators.
FlowSentinel is for operators who run one primary automation tool and need assurance, evidence, and recovery follow-through without exposing confidential workflow data unnecessarily. The self-serve path proves value on a single provider before anyone asks for broader coverage.
This page describes shipped product behavior, not a certification claim. It is meant to help buyers understand what data FlowSentinel accesses, what stays out of user-facing surfaces, and how to interpret evidence and recovery claims.
For customer setup, onboarding stays single-tool first: create the workspace, choose one provider, connect it, then let FlowSentinel show verified status, missing proof, and the next action.
After setup, the readiness summary should tell the same story in one pass: what was connected, what FlowSentinel can currently observe, what still needs evidence, and when the next review happens.
One provider first
Trust starts with the provider you actually use today: Make, n8n, or Zapier. FlowSentinel labels provider maturity instead of hiding parity gaps.
Evidence before claims
Review surfaces separate observed evidence from inferred signal, then show uncertainty when proof is incomplete.
Bounded beta posture
FlowSentinel does not sell enterprise theater. It sells a practical assurance loop with explicit limits and no fake compliance language.
What FlowSentinel accesses
Workspace and account context
Workspace membership, role, account email, and billing state are used to decide who can view, export, or change sensitive settings.
Workflow metadata and run evidence
FlowSentinel reads workflow names, provider ids, run status, timestamps, error summaries, issue families, governance fields, and verification evidence needed for review.
Provider installation settings
Connected-provider credentials are used server-side for scans, syncs, and verification checks. They are not rendered back into review, export, or browser-facing surfaces.
What FlowSentinel does not do
The product is intentionally not an autonomous workflow operator. Provider-native execution tools remain the place for replay, manual repair, and low-level debugging.
- Does not auto-remediate, replay, mutate, or disable workflows on your behalf.
- Does not claim a workflow is fixed because an AI summary sounds confident.
- Does not expose service-role database access to browser code.
- Does not turn beta evidence into compliance certification claims.
How sensitive data is protected
Redaction before egress
Tokens, cookies, webhook URLs, API keys, authorization headers, and credential-like fields are redacted or dropped before logs, AI context, review pages, and evidence exports.
Permission-scoped exports
Evidence exports require workspace owner/admin authority, an explicit export purpose, no-store response headers, and an audit event.
Raw payload restraint
Default product behavior favors metadata, error summaries, and evidence artifacts. Raw payload capture remains opt-in rather than the normal operating path.
How to read evidence and recovery claims
FlowSentinel is strongest when it says exactly what it has observed and what remains inferred. A recovery claim should become stronger only when runtime evidence or smoke proof supports it after the fix.
Observed evidence
Provider run status, persisted issue records, scan output, verification-check result, review history, and audit events that FlowSentinel has actually seen.
Inferred signal
Likely cause, blast-radius hints, cadence pressure, dependency pressure, and workflow-risk interpretation derived from observed evidence plus known workflow metadata.
Uncertainty
Cases where provider depth is partial, runtime evidence is sparse, recovery proof is stale or missing, or Zapier coverage comes from forwarding/inventory baseline rather than direct API parity.
Recovery verification interpretation
Treat recovery as verified when FlowSentinel has post-fix runtime evidence or a passing supported verification check. Treat it as unverified when the issue was closed without fresh proof. Treat it as unstable when later evidence regresses or verification fails again.
Current beta limits buyers should know
Make is the strongest path today. n8n is supported with meaningful review, evidence-consistency, and verification-check coverage. Zapier now carries stronger runtime proof classification through forwarded incidents, proof summaries, replay/follow-up evidence, verified-recovery flags, and regression-after-recovery warnings, but it still does not have direct API parity or in-app run-now verification checks.
Workspace owners/admins can configure bounded retention windows for scoped evidence artifacts and run audited purges. Full workspace/account deletion and provider-side deletion remain governed follow-up paths, not beta compliance guarantees.