Security
A factual summary of FinkMesh launch security practices and where to report vulnerabilities.
Current posture
FinkMesh is an early-stage automation product for workflows, credentials, webhooks, run logs, support attachments, and connected services. We use practical technical and organizational safeguards, but we do not currently claim SOC 2, ISO 27001, HIPAA, PCI DSS service-provider, or formal data residency certification.
Security controls
Authentication and workspace access
- Account authentication protects dashboard access.
- Workspace roles and invite controls limit who can view, edit, publish, and manage shared resources.
- Permission checks protect support tickets, runs, workflows, variables, connections, and administrative surfaces.
Encryption and transport
- Public application traffic is served over HTTPS/TLS through the hosting and edge infrastructure.
- Workspace secrets, OAuth tokens, API keys, and encrypted variables are encrypted before storage.
- Customers should avoid sending secrets over plaintext HTTP endpoints or embedding full credentials in run logs, prompts, or screenshots.
Credentials and secrets
- Workspace credentials, OAuth tokens, API keys, and encrypted variables are encrypted before storage.
- Secret values are non-revealable after storage and must be rotated to replace.
- Users should rotate credentials after team changes, suspected exposure, or provider-side incidents.
Workflow execution
- Publish readiness checks block incomplete or unsafe workflow configurations.
- Plan limits, concurrency controls, rate limits, webhook validation, and payload caps protect the runtime.
- Workflow error guardrails can auto-pause workflows after repeated failures to avoid wasting runs.
Monitoring and operations
- Operational dashboards track database health, cron heartbeats, queue backlog, stuck runs, dead letters, and support outbox status.
- Workflow run history, step results, errors, and audit records help teams investigate failures.
- Administrative and operational access is limited to people who need it to operate, secure, support, and troubleshoot the service.
- FinkMesh uses managed infrastructure backup capabilities and maintains operational restore procedures for launch operations.
Support attachments
- Support screenshots and attachments require authentication.
- Uploads are type and size restricted.
- Users should avoid uploading secrets, full credentials, regulated data, or unrelated personal data in support tickets.
Deletion and incident response
- Account, workspace, and data deletion requests are handled through support, subject to identity verification and legal exceptions.
- Security incidents are triaged by severity, affected systems, data exposure risk, and customer impact.
- When we determine that customer notification is required, we will contact affected customers through account, support, or administrative channels.
Infrastructure
FinkMesh currently uses Vercel for application hosting, Neon for Postgres database storage, Cloudflare for edge/network services, Stripe for billing, Resend for email, and other vendors listed on the Subprocessors page as needed to operate the service.
Customer responsibilities
Customers are responsible for configuring workflows safely, connecting only authorized systems, limiting access to workspaces, rotating credentials, reviewing AI output, monitoring critical workflows, and avoiding unnecessary secrets or sensitive data in payloads, logs, prompts, and support screenshots.
Vulnerability reporting
Send suspected vulnerabilities, account compromise reports, exposed-token reports, or abuse issues to contact@finkmesh.com. Include a concise description, reproduction steps, affected URLs or workflow ids, timestamps, and impact. Do not access, modify, delete, exfiltrate, or disrupt data that is not yours while testing.
Good-faith security reports that follow these rules and the Acceptable Use Policy will not be treated as platform abuse solely because they identify a vulnerability. FinkMesh does not currently operate a paid bug bounty program.