Security

Primary registration and sign-in use expiring email links, secure HttpOnly session cookies and server-side authorization checks. Legacy passwords, where present, are stored only as password hashes.

Public authentication flows use rate limits and Cloudflare Turnstile. Production cookies use Secure and SameSite controls, and session lifetime is limited.

Every protected operation resolves a specific user, workspace and role. Owner, admin, editor and viewer permissions are checked server-side; channel-level permissions further limit destinations.

Composer, calendar, API and worker paths use concrete channel IDs and validate workspace ownership. Disabled, missing or cross-workspace profiles are rejected before a publish job proceeds.

Connected-provider credentials are encrypted at rest with authenticated AES-256-GCM encryption. Secrets and raw API tokens are excluded from normal UI, audit metadata and user-facing errors.

Workspace Agent API tokens are shown only at creation, stored as non-recoverable verification material and issued with explicit scopes and profile access. Tokens can be named, tested, rotated and revoked; scheduling and publishing require elevated scopes, workspace permission and exact per-action confirmation.

Quick connection tokens expire automatically after 24 hours, 7 days, 30 days or 90 days. A user may choose 30 or 90 days only after accepting a separate increased-risk warning; Quick tokens can never be non-expiring. After acknowledging the warning, a user may paste the complete Quick setup once into its intended private agent task. The setup must not be placed in a public or shared chat and should be revoked when the task ends.

Secure connection tokens are copied separately into secret storage and never included in setup instructions or prompts. Only a freshly authenticated workspace owner can create a non-expiring secure token; it remains visible in the connection inventory, is periodically flagged for review and stays valid only until revoked.

Production traffic uses TLS and Cloudflare network protection. The application sets content-security, framing, referrer, MIME-sniffing and permissions headers and validates request payloads, upload limits, UUIDs and provider-specific publishing rules.

Internal endpoints use dedicated authentication and are not treated as ordinary public user routes. Sensitive actions create scoped audit events without credential values.

Human review is the default for agent-created drafts. Approval policies, readiness checks and provider validations run before scheduling or publication. Queue jobs are idempotent where supported and publish state is reconciled with provider responses.

Removing a social profile is blocked while active scheduling or publishing work depends on it. Removal clears credentials, disables posting slots and prevents the worker from using the profile.

Production health checks monitor web, worker, database, Redis and queue dependencies. Alerts, structured logs and audit history support incident investigation without intentionally recording raw provider credentials.

Database and stored media are backed up with a documented restore procedure and normally 14-day rotating retention. Backup access is restricted and restore drills are part of release readiness.

KORD maintains an incident-response process for triage, containment, remediation and customer notification. Personal data breaches affecting customer data are reported to the customer without undue delay as described in the DPA.

Send suspected vulnerabilities privately to [email protected]. Include the affected URL or component, impact, safe reproduction steps, relevant timestamps and whether any data may have been accessed. Do not include access tokens or unnecessary personal data.

Give us reasonable time to investigate before public disclosure. We do not currently operate a paid bug-bounty program and cannot promise payment.

Use only accounts and workspaces you own or have written permission to test. Stop if you encounter another person's data, a credential, destructive behavior or service instability and report it immediately.

• Do not publish, modify, delete or download another customer's data.
• Do not use social publishing actions, send email, create payment activity or complete OAuth for someone else.
• Do not use denial of service, high-volume automation, social engineering, malware, physical attacks or third-party provider testing.
• Do not demand payment or threaten disclosure. Preserve only the minimum evidence needed for the report and delete it when asked.
• Good-faith testing that follows these rules will not be treated by KORD as an attack, but this statement cannot authorize activity against third parties or override applicable law.