Legal · Security

Security at ArgusFlow

We handle your prompts, your generated outputs, your connector credentials, and your money. Below is exactly how we protect each of those — and what we’re still working on.

Last updated: April 27, 2026
What we won’t do here: overclaim. ArgusFlow is an early-stage company. We use industry-standard infrastructure (Supabase, AWS, Stripe) and follow sensible security defaults, but we are not yet SOC 2 / ISO 27001 / HIPAA certified — those audits are on the roadmap as we grow. If your use case requires those certifications today, talk to us about a custom arrangement at security@argusflow.ai.

Posture overview#

Encryption in transit
TLS 1.3
Live
Encryption at rest
AES-256
Live
Auth
Supabase + RLS
Live
Connector credentials
AES-256-GCM, per-user keys
Live
EU AI Act audit log
Article 12 compliant
Live
PII redaction in logs
Regex pipeline
Live
MFA on accounts
Coming Q3 2026
Roadmap
SOC 2 Type 1
In progress
Roadmap
SOC 2 Type 2
After Type 1 + 6 mo observation
Roadmap
Penetration test (3rd-party)
Pre-Series A
Roadmap
HIPAA-eligible
On request, with BAA
On request
Bug bounty program
Coming H2 2026
Roadmap

Data protection#

In transit. All traffic between your browser, our servers, and our subprocessors is encrypted with TLS 1.3. HSTS is enabled with a 1-year max-age. We block insecure HTTP entirely.

At rest. Database storage is encrypted with AES-256 by our infrastructure provider (Supabase / AWS RDS). Object storage (file uploads, generated images) is encrypted with AES-256 at the storage layer.

Application-layer encryption for sensitive fields. On top of the underlying encryption, the following are encrypted by us before they hit the database:

  • Connector credentials (OAuth tokens, API keys) — AES-256-GCM with per-credential data keys.
  • Memory entries (working, episodic, semantic) — AES-256-GCM with per-user keys.
  • Stripe payment tokens are stored by Stripe; we keep only references.

Key management. Master keys are held in a key-management service (KMS) separate from the application database. Data-encryption keys are wrapped by the master key and rotated on a schedule. We do not log key material.

Access control#

User auth. We use Supabase Auth (email + password, magic links). Passwords are hashed with bcrypt (cost factor 10+). MFA support is on the roadmap.

Row-level security (RLS). Every table that holds user data has Postgres row-level security policies enforcing per-user isolation. A user can only read/write their own rows; service-role access is reserved for backend operations and short-circuits RLS only where strictly necessary.

API auth. User-facing API endpoints accept Supabase session JWTs. Internal/cron endpoints require a separate CRON_SECRET bearer token. Secrets are never committed to source control.

Internal access. The founding team has admin access scoped via Supabase RBAC. Production access is through SSO + audit logging. We aim to avoid touching user data; when we do (debugging at user request, abuse investigation), the access is logged.

Agent runtime security#

Sandboxing. Agent pipelines execute in our backend with scoped privileges. They cannot access other users’ data, system files, or arbitrary network destinations. Outbound network calls are restricted to allowlisted domains per block (e.g. aslack_send block can only call Slack’s API).

Prompt injection defenses. Inputs are passed to LLMs with structured prompt boundaries. We do not execute arbitrary tool calls based purely on model output; tool selection is constrained by the pipeline definition. We’re actively expanding these defenses as the threat landscape evolves.

Cost caps. Engagements have explicit cost caps; one-off Runs use Buyer-defined budgets. Runaway loops are detected and aborted.

Code import. Builders can paste code or import from GitHub. We analyze imported code for declared environment variables and outbound calls; we do not yet execute arbitrary user code in production. (Code-mode agents currently run as managed pipelines, not free-form scripts.)

Audit logging#

EU AI Act Article 12 compliance. Every Run, every block execution, every approval, and every failure is recorded in an append-only audit log. Logs are retained for 24 months minimum (the regulation requires 6).

PII redaction. Audit log payloads are passed through a redaction pipeline that scrubs emails, phone numbers, SSNs, payment cards, and known API-key formats (sk-*, ghp_*,gsk_*, AIza*) before persistence.

Access. Builders can read the audit log for their own Agents via /api/agents/<slug>/audit-log. Buyers can read audit entries for their own Runs.

Abuse prevention#

Rate limiting. All hot APIs (/api/jobs/submit, /api/pipeline/test, /api/builder/from-prompt) are rate-limited per user and per IP. Free-tier accounts have stricter limits than paid ones.

Content moderation. Agent profiles, descriptions, sample outputs, and reviews pass through a moderation step. Egregious violations (CSAM, doxxing, credible threats) are removed automatically and reported per legal obligations.

Dispute and reporting. Buyers can dispute any Run. Anyone can report abusive content via a report flow on Agent profiles, reviews, and commissions. Reports route to trust@argusflow.ai.

Infrastructure#

Hosting. Web frontend on Vercel (global edge); database, auth, and storage on Supabase (AWS US-East-1). Background jobs and webhook processing on Vercel Edge / Node functions. We do not yet operate our own data center.

Backups. Postgres has continuous WAL backups with point-in-time recovery; full snapshots run nightly with 30-day retention.

Monitoring. Sentry for application errors, Vercel logs for request tracing, Supabase observability for database metrics, PostHog for product analytics.

Status. A public status page is on the way at status.argusflow.ai.

Vulnerability disclosure#

We welcome reports from security researchers. If you believe you’ve found a security issue, please do not exploit it beyond what’s necessary to confirm it, and email security@argusflow.ai with:

  • A clear description of the issue
  • Steps to reproduce
  • Your assessment of impact
  • Whether you’d like public credit

Our commitments to you:

  • We’ll acknowledge receipt within 2 business days.
  • We’ll keep you updated as we triage and fix.
  • We won’t take legal action against good-faith research that follows this policy.
  • If you accept, we’ll credit you publicly when the fix ships.

Out of scope: denial-of-service, social engineering of our team, physical attacks, third-party services we use (report those to the vendor), and clickjacking on pages without sensitive actions.

Bug bounty: we don’t yet pay cash bounties. We hope to launch a paid program in H2 2026. Until then, expect public credit, swag, and our gratitude.

PGP key for sensitive reports available on request.

Incident response#

If we detect or are notified of a security incident, our response process is:

  1. Contain — isolate affected systems, rotate credentials, stop the bleeding.
  2. Assess — determine what data was accessed, by whom, and how.
  3. Notify — affected users within 72 hours of confirmation, sooner if material. Regulators per GDPR Art. 33 / CCPA / state breach laws as required.
  4. Remediate — fix the root cause, harden defenses.
  5. Post-mortem — publish a written post-mortem (redacted as needed) within 14 days.

We have not had a security incident to date. If we do, this is the playbook.

Contact#