← Back to home
Security

Security & Data Handling

This page explains how CronAI stores job data, handles authentication and secrets, and how to report security issues.

Data Handling Overview

CronAI stores job configuration, execution metadata, alert policies/channels, and team membership data so it can schedule jobs, record outcomes, and notify your team.

Execution responses may be stored as snippets for debugging when enabled. Teams should configure retention to match their operational and compliance needs.

Secrets and Encryption
  • Job headers and auth values are encrypted at rest using application-level encryption before being persisted in Convex.
  • Alert channel secret fields are encrypted at rest before being persisted in Convex for new/updated channel configs. Existing channels should be backfilled using the migration mutation.
  • Secret values are masked in the UI after save.
  • Jobs can reference server-side environment variables using env:VAR_NAME where supported.
  • Integration secret encryption should follow the same pattern before shipping new provider connections.
Authentication and RBAC
  • Authentication is handled with Clerk.
  • Authorization is enforced server-side with team-aware permissions.
  • Team roles include owner, admin, member, and viewer.
  • Super admin mode exists for platform-wide visibility and support workflows.
Infrastructure and Execution Model

CronAI schedules and executes jobs from CronAI-managed infrastructure using Convex scheduled functions/actions and outbound HTTP requests. CronAI does not execute arbitrary customer code.

This model is designed for scheduled HTTP jobs, health checks, webhooks, and API-driven automation, not general-purpose compute tasks.

Logging and Retention

CronAI records execution history, alerts, and audit events for observability and operations. Retention controls should be configured by team and, where needed, per job.

If stricter retention or redaction is required, disable response storage for sensitive jobs and reduce retention windows.

Incident Response
  • Security reports are reviewed manually by the maintainer and triaged by severity.
  • Critical issues are prioritized for mitigation and user communication.
  • Affected users will be contacted when a confirmed issue impacts their data or service usage.
Responsible Disclosure

Please use the contact channel on the public site for security reports and include clear reproduction steps, affected endpoints, and impact. A dedicated security.txt file is published for discovery.

Third-Party Processors
  • Clerk (authentication)
  • Convex (application database and backend functions)
  • Vercel (frontend hosting)
  • Resend (email delivery for alerts/contact notifications)
  • AI providers (OpenAI/Anthropic) when AI features are enabled in your deployment