Security Statement

1. The principles

Three things shape our security decisions:

• Minimize blast radius. If something goes wrong, the damage should stay contained: one user's data, one service, one day's logs. We design for failure containment.
• Default to encryption. Data at rest, data in transit, OAuth tokens with an extra layer. If something can be encrypted at reasonable cost, it is.
• Honest about what we don't have yet. Trendnaut is a small product. We don't pretend to be SOC 2 certified when we aren't. We tell you the actual state.

2. Infrastructure

Trendnaut runs on:

• Neon for the PostgreSQL database, with encryption at rest, automated backups, and TLS for all connections. Production data replicates across availability zones.
• Railway for application hosting and background workers. All services run with environment-scoped secrets, never committed to code.
• Cloudflare R2 for file storage (thumbnails, exports). Files are encrypted at rest with object-level access control.
• Cloudflare for DNS, DDoS protection, and TLS termination at the edge.

All traffic between you and Trendnaut uses TLS 1.2 or higher. We don't accept connections on plain HTTP for the application. Every HTTP request redirects to HTTPS.

We choose providers in part for their security posture. Where a provider doesn't carry formal certifications (SOC 2, ISO 27001), we evaluate their engineering practices, incident history, and transparency. We monitor announcements from every provider and update our practices when they update theirs.

3. Authentication

You sign in to Trendnaut with Google OAuth. We don't store passwords. There's no password to leak, reset, or stuff into another site.

After you sign in:

• We create a server-side session with a randomly generated token.
• The session is stored as an httpOnly, secure, sameSite cookie. JavaScript on the page can't read it.
• Sessions expire after 30 days of inactivity. Logging out destroys the session immediately on both client and server.
• Each session is tied to the IP address you logged in from. If the IP changes significantly between requests (a possible sign of session hijacking), we may prompt re-authentication.

Two-factor authentication isn't implemented in Trendnaut directly yet. Because you sign in via Google, your Google account's two-factor protection applies to Trendnaut logins. Native 2FA at the Trendnaut layer is on the roadmap.

4. OAuth tokens: how we handle the keys to your YouTube account

When you connect your YouTube channel, Google gives us two tokens:

• An access token, short-lived (1 hour). We use it to make API calls on your behalf.
• A refresh token, long-lived. We use it to obtain new access tokens when the previous one expires, without making you sign in again.

Both tokens are encrypted at rest in the database with AES-256, using a key stored in environment variables (not in code, not in the database). When we need a token, we decrypt it in memory, make the API call, and discard the decrypted copy.

Access tokens are never logged. Refresh tokens are never logged or sent to any third party. Not to OpenRouter, not to PostHog, not anywhere outside Trendnaut's database and our own application code.

If you revoke access at myaccount.google.com/permissions, both tokens become invalid immediately. We detect the revocation on the next API call and mark your connection as needing reconnection.

5. Data isolation

Every query in Trendnaut is scoped to the authenticated user's creator profile. There's no admin "view as user" interface. No path in the application exposes Creator A's data to Creator B's session.

Database queries that touch user data go through a data access layer that enforces creator-scoped filtering. We don't write raw SQL that joins across users in user-facing code paths.

For internal analytics and debugging, we work with anonymized aggregates (UUIDs, not names or emails). When we need to investigate a specific issue, we ask the affected user for permission first.

6. Backups

We run daily automated backups of the production database, retained for 30 days. Backups are encrypted at rest with the same standards as production data.

We haven't yet run a full disaster recovery exercise (restoring from backup to a clean environment and verifying integrity). That's on the roadmap before we cross 100 paying users. In the meantime, we rely on Neon's point-in-time recovery for partial restores.

When you delete your account, we remove your data from active systems immediately. Backups containing your data are overwritten within 30 days as part of the normal backup rotation.

7. Logs

We retain application logs for 30 days, then delete them permanently.

What's in the logs:

• HTTP request paths and status codes
• User IDs (UUIDs) for tracing
• Server-side errors and stack traces
• Background job execution status

What's NOT in the logs:

• OAuth tokens (stripped before anything is logged)
• Email addresses or names (we log UUIDs only)
• Cookie values
• Request bodies for sensitive endpoints (auth, billing)

Logs live inside our infrastructure (Railway). They aren't exported to a third-party log aggregator at this time. Access is restricted to the development team for debugging.

8. Vulnerability handling

We accept responsible disclosure of vulnerabilities. Email security@trendnaut.com with:

• A description of the vulnerability
• Steps to reproduce
• The impact you've identified
• Your name (optional, for credit) and PGP key (optional, for encrypted follow-up)

We commit to:

• Acknowledging your report within 48 hours
• Providing an initial assessment and tentative fix timeline within 5 business days
• Keeping you informed throughout remediation
• Crediting you publicly once the fix ships, if you want

We don't run a paid bug bounty program yet. We will credit reporters in a public security acknowledgments page once we have enough material to publish one.

Please don't test against other users' accounts without their permission, run automated scanners that generate excessive traffic, or disclose the vulnerability publicly before we've had time to fix it. We'll work with you on a coordinated disclosure timeline.

9. What we don't do (yet)

Honest list of what we don't have today, and when we plan to address it:

• Formal SOC 2 or ISO 27001 certification. Not feasible at our current stage. We'll pursue SOC 2 when revenue can fund the audit (typically $30K to $60K) and a customer base requires it.
• Two-factor authentication at the Trendnaut layer. Currently relies on your Google 2FA. Native Trendnaut 2FA is on the roadmap.
• Dedicated security engineer. Trendnaut is small. Security is everyone's responsibility, but nobody's full-time job yet.
• Penetration testing. We haven't commissioned a third-party penetration test. Planned before we cross 100 paying users or $10K monthly revenue, whichever comes first.
• Bug bounty program with payouts. We accept disclosure with credit but don't pay yet. We'll start paying when revenue supports it.
• Customer-managed encryption keys (CMEK). Standard at the enterprise tier, not at solo creator pricing. Not on the near-term roadmap.

Telling you what we don't have is part of trust. If any of these matters for your decision, that's fair. We'd rather you know now than be surprised later.

10. Incident response

If we discover a security incident that affects your data, we will:

• Within 72 hours: notify the relevant EU supervisory authority (GDPR Art. 33) with what we know: what data was affected, approximate number of people impacted, likely consequences, and measures taken or planned.
• Within 3 business days: notify ANPD in Brazil (LGPD, ANPD Resolution 15/2024) with the same information.
• Without undue delay: email you directly when the incident presents a high risk to your rights. We won't wait for the full investigation before telling you what happened and what to do.
• Within 7 days: a follow-up email with the root cause, the fix deployed, and any actions you should take (like monitoring for suspicious activity on other accounts).
• Within 30 days: a public post-mortem on our blog or status page, with technical detail for engineers, lessons learned, and changes to our practices.

Not every incident triggers notification thresholds. A server error that exposed no data doesn't require authority notification. We apply the legal tests honestly: GDPR (risk to rights and freedoms), LGPD (relevant or significant damage to the titular).

11. What you can do to stay secure

Security is shared. Here's what we recommend on your side:

• Turn on 2FA for your Google account. Single biggest thing you can do. Since Trendnaut uses Google sign-in, your Google 2FA protects your Trendnaut access.
• Don't share your Trendnaut session with others. If someone else needs to see your analytics, use the export feature.
• Review connected apps periodically. At myaccount.google.com/permissions you can see every app with access to your Google account. If you stop using Trendnaut, revoke our access there.
• Use a password manager for your other accounts. Even though Trendnaut doesn't have a password, the rest of your stack does. Password reuse is the #1 cause of account compromise.
• Watch for phishing. We will never email you asking for your password, OAuth tokens, or payment details. If an email claims to be from Trendnaut and asks for any of those, it isn't from us.

12. Trust over time

Security at Trendnaut today is the security we can honestly deliver as a small team running a focused product. Over time, the bar rises as the product grows.

We update this page when we ship meaningful improvements: adding 2FA, completing a SOC 2 audit, running our first penetration test. We don't claim improvements we haven't shipped.

If you're a security-conscious user evaluating Trendnaut, we're happy to answer specific questions. Email security@trendnaut.com and we'll respond with as much detail as we can share without compromising other users.

13. Contact

For security concerns, vulnerability disclosure, or detailed security questions:

We acknowledge security reports within 48 hours. Privacy and data requests within 15 days, as required by LGPD.