Security

1. Hosting and platform

• The application, database, storage, and authentication run on Lovable Cloud, a managed backend platform.
• The edge and DNS layer are provided by Cloudflare.
• Server-side code runs in a serverless edge runtime; no long-lived servers we manage directly.

2. Encryption

• All traffic to the app, dashboard, widget, and API is served over HTTPS (TLS).
• Data at rest in the managed database and object storage is encrypted by the platform provider.
• Secrets are stored in the platform's secret store, not in source code.

3. Authentication

• Email + password sign-in via the managed auth provider, with Google OAuth also supported.
• New passwords are checked against the Have I Been Pwned breach corpus (k-anonymity; only a 5-character hash prefix is sent) and rejected if compromised.
• Optional two-factor authentication (TOTP authenticator app) with one-time recovery codes stored as salted hashes.
• Sign-up and sensitive auth flows (sign-in, forgot-password) are gated by Cloudflare Turnstile and per-IP rate limits.
• Sessions are managed by the platform's auth service with signed tokens; passwords are hashed by the auth provider and we never see plaintext passwords.

3a. Transport and application security headers

• HTTP Strict Transport Security (HSTS) with a one-year max-age and includeSubDomains; preload.
• Content Security Policy locks scripts, styles, and connections to an explicit allowlist; object-src 'none'; no unsafe-eval.
• Cross-Origin-Opener-Policy, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy applied to every response.

4. Authorization and tenant isolation

• Every workspace is isolated at the database layer using row-level security policies keyed to the workspace and the authenticated user.
• Roles (owner, admin, member) are stored in a dedicated table and checked server-side; roles are never trusted from the client.
• Server functions that touch customer data run through an auth middleware that verifies the caller before any query executes.

5. Widget and public endpoints

• Embedded widgets are locked to the domains listed in the workspace's allowlist.
• Per-IP and per-widget rate limits protect against abuse and cost-exhaustion attacks.
• Public webhook and widget endpoints validate input with schema checks before processing.

6. AI and data handling

• Customer documents and chats are used only to answer questions inside the customer's workspace.
• We do not use customer content to train foundation models.
• Prompts and retrieval context are constructed server-side; the client cannot inject system prompts.

7. Input handling

• File uploads are checked for type and size before ingestion, and screened against known-malware hashes via VirusTotal.
• URL ingestion enforces an allowlist / SSRF protections against internal network targets.
• Widget chat context is fenced against prompt-injection from retrieved documents, and visitor PII in questions is redacted before it is cached or logged.

8. Logging and monitoring

• Application and edge errors are captured for debugging and reliability via Sentry, with PII and secret fields scrubbed before transmission.
• Security-relevant events (auth changes, role changes, deletions, admin actions) are recorded in an append-only audit log.
• Structured server logs use a field allowlist and PII scrubber; logs are retained for up to 12 months.

9. Backups and availability

• The managed database is backed up by the platform provider on its standard schedule.
• We do not offer a contractual uptime SLA on free plans. Paid-plan SLAs, if any, will be stated in the order form.

10. Vulnerability reporting

If you believe you have found a security issue, please email daniyal@agenticcore.tech with details and steps to reproduce. Please do not publicly disclose the issue until we have had a reasonable opportunity to fix it. We will acknowledge reports within 5 business days.

11. Shared responsibility

We secure the platform, code, and default configuration. Customers are responsible for choosing strong passwords, protecting their credentials, managing who they invite into workspaces, and reviewing AI output before acting on it.

12. Changes

Security controls evolve. This page will be updated when material controls change. Historical versions are available on request.