AdKinex is launching soon. Be the first to get access →

Security

Last updated: May 9, 2026

1. Our Approach

AdKinex handles advertising performance data and, for users who connect Google Ads, OAuth credentials that grant access to live ad accounts. We treat that responsibility seriously. Our security posture is built around three principles: collect as little as we can, encrypt everything in flight and at rest, and keep an immutable record of any action AdKinex takes on a user’s behalf.

2. Encryption

  • In transit: all traffic uses TLS 1.2 or higher. HTTPS is enforced site-wide and HSTS is set by our hosting platform.
  • At rest: data stored in our managed database and object storage is encrypted with AES-256 by default.
  • Application-layer encryption: Google OAuth refresh and access tokens are additionally encrypted with AES-256-GCM before being written to the database, using a key held in a separate environment variable. This means even an attacker with raw database access cannot use OAuth tokens against your Google Ads account.

3. Authentication

  • AdKinex is passwordless: we support email one-time codes and Google OAuth as the only sign-in methods.
  • Because we do not store passwords, password leaks are not a possible attack vector for AdKinex.
  • Sessions are managed by our authentication provider using short-lived access tokens that are refreshed automatically.
  • During the private beta, access is restricted to invited email addresses on an explicit allowlist; non-invited users cannot create or sign in to an account.

4. Account Isolation & Access Controls

  • Every business table in our database is protected by row-level security (RLS) policies that scope reads and writes to the authenticated user.
  • Sensitive tables (encrypted OAuth tokens, write-action audit logs, billing identifiers, lead records) are accessible only via privileged service-role credentials and are not reachable from the browser, even with a valid user session.
  • Internal access to production systems is limited to the smallest team practical and is granted on a least-privilege basis.

5. Google Ads Write Boundaries

For users who connect a Google Ads account, AdKinex enforces strict, hard-coded limits on what we can write back to your account, both in code and at the database level:

  • The only write action AdKinex can perform is the addition of negative keywords at the ad-group level with EXACT match type, after explicit user approval.
  • AdKinex cannot pause campaigns, ad groups, or keywords; cannot change bids, bid strategies, or budgets; cannot create, modify, or delete campaigns, ad groups, ads, or assets; and cannot modify targeting or schedules.
  • These boundaries are encoded as database CHECK constraints and table-level permissions, not just as application logic, so they cannot be silently bypassed by a code change.

6. Immutable Audit Logging

Every write action AdKinex performs on a connected Google Ads account is recorded in append-only audit logs. Those audit-log records cannot be deleted by anyone — the database refuses DELETE statements on those rows at the trigger level. This gives you a permanent, tamper-resistant record of what AdKinex did on your behalf.

7. Infrastructure & Compliance Inheritance

AdKinex is built on top of mature, audited infrastructure providers. While AdKinex itself has not yet undergone independent SOC 2 or ISO 27001 audits, we inherit security controls from the following providers:

  • Database, authentication, and object storage: SOC 2 Type II audited.
  • Application hosting and edge network: SOC 2 Type II and ISO 27001 audited.
  • OAuth identity provider: industry-leading, with continuous third-party audits.

We are evaluating SOC 2 Type II readiness for AdKinex itself as we scale and will update this page when an audit is in progress.

8. Backups & Recovery

Database backups and point-in-time recovery are provided by our managed database platform under their standard retention policies. We have not yet committed to public Recovery Time Objective (RTO) or Recovery Point Objective (RPO) targets; we will publish formal targets as our scale and customer base warrant.

9. Incident Response

We monitor for security and availability incidents and maintain an internal process for triage, containment, and remediation. In the event of a confirmed personal-data breach affecting your information, we will notify affected users without undue delay and in any event within the timelines required by applicable law. To report a suspected incident, contact support@adkinex.com.

10. Vulnerability Disclosure

If you believe you have found a security vulnerability in AdKinex, please report it to support@adkinex.com. Provide a detailed description and, if possible, a reproduction. We will acknowledge receipt within five (5) business days and work with you to validate and remediate the issue. We do not currently run a paid bug-bounty program, but we genuinely appreciate responsible disclosures and will credit researchers (with their consent) once a fix is shipped.

11. Payment Security

When paid plans are activated, payment will be processed by Stripe. Full payment-card numbers never reach AdKinex servers; we receive only payment-method tokens and customer/subscription identifiers. Stripe is PCI-DSS Level 1 compliant.

12. Contact

For any security or compliance question, please reach us at support@adkinex.com.