Security Policy

1.1 Infrastructure

1.2 Encryption

• Encryption in transit: all communications use end-to-end HTTPS/TLS 1.2+.
• Password encryption: stored with bcrypt hash via Supabase Auth. Never stored in plain text.
• Integration credential encryption: WordPress passwords and Google Search Console OAuth tokens are encrypted with AES-256-GCM before being stored in the database.
• At-rest encryption: the Supabase database encrypts stored data via disk encryption.

1.3 Authentication and access control

• JWT-based authentication (JSON Web Tokens) with verification on each request to the server.
• Google OAuth 2.0 support as an alternative login method.
• Row Level Security (RLS) on all database tables: each user can only access their own data.
• Role-based access control: strict separation between standard users and administrators.
• Dedicated internal token for server-worker communication (isolation of internal processes).

2.1 Server security

• HTTP security headers (Helmet): Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy.
• CORS protection: strict whitelist of authorized origins (ALLOWED_ORIGINS).
• Rate limiting: 100 requests per minute per user to prevent abuse.
• Specific rate limiting: 1 free audit per IP per day.
• Input validation on all API endpoints.
• SQL injection protection via parameterized queries (Supabase client).

2.2 Frontend security

• No secrets or API keys stored in frontend code.
• Separate environment variables for frontend (only public keys) and backend (private keys).
• User input sanitization before rendering.

2.3 Integration security

• WordPress: credentials (Application Passwords) are encrypted with AES-256-GCM and transmitted over HTTPS. They are deleted immediately upon disconnection.
• Google Search Console: standard OAuth 2.0 authentication. Refresh tokens are encrypted with AES-256-GCM. Revocable at any time.
• Bing Webmaster Tools: API key provided by the user, encrypted with AES-256-GCM. No OAuth; direct connection. Removable at any time.
• Shopify (pending approval): OAuth 2.0 Authorization Code Grant. Access tokens encrypted with AES-256-GCM. Preventive rate limiting (bucket 40, leak 2/s). Relevante.IA does not access store customer data or orders.
• Stripe: payment processing fully delegated to Stripe. Relevante.IA never accesses complete credit card data.

3.1 Data minimization

• We only collect data strictly necessary to provide the service.
• Prompts sent to AI providers contain only public data about the user's business (web content, trade name). No personal data is sent (email, password, payment data).
• The context optimization system (SRO Skill Context) reduces the volume of data sent to AI by ~35% compared to a complete send.

3.2 Data isolation

• Each business operates as an aggregate root in the database with isolated relationships.
• Row Level Security (RLS) ensures that one user cannot access another user's data under any circumstances.
• Asynchronous jobs (BullMQ) are processed in isolated workers with a dedicated internal token.

3.3 Retention and deletion

• Retention periods are defined in the Privacy Policy.
• Upon account cancellation, integration credentials are deleted immediately.
• After the retention periods have elapsed, data is irreversibly deleted or anonymized.
• The user may request export of their data in JSON format before cancellation.

Users may request that their analyses be processed exclusively with providers headquartered in the USA/EU (excluding DeepSeek) by writing to contacto@relevanteia.com.

We periodically review and update our security measures to adapt to new threats and best practices. If you have questions about our security or wish to report a vulnerability, contact us at contacto@relevanteia.com.

Responsible disclosure:

If you discover a security vulnerability in our platform, we ask you to communicate it responsibly before any public disclosure. We commit to investigating and resolving any verified vulnerability as soon as possible.