Security Overview
Version: 0.1-draft Effective date: not yet in force (draft)
Draft pending review by a qualified Romanian lawyer before use. Items marked [TBC] must be confirmed by engineering before this page is published. They correspond to the measures marked "[TBC – confirm before signature]" in Annex 2 of data-processing-agreement.md, and both documents must be updated at the same time.
1. About this page
1.1 This page describes, in plain terms, how ALTTAB PROFIT SRL, a limited liability company (the "Company") protects the 1ads Platform and Customer Data. It describes the safeguards we have today, what we have not done yet and what we plan.
1.2 This page is informational. The Company's contractual security commitments are set out in the Terms (terms-of-service.md) and the Data Processing Agreement (data-processing-agreement.md), including its description of technical and organisational measures under Article 32 GDPR. If this page and those documents differ, those documents prevail.
1.3 Certifications. The Company does not currently hold SOC 2, ISO/IEC 27001 or any other security certification or attestation. We do not claim compliance with any certification standard. See section 11 for our roadmap.
2. Architecture and hosting
2.1 The Platform runs on the Company's own on-premises Kubernetes cluster, located in Romania (EU) and operated by the Company itself under its FirstIT brand. It does not run in a public cloud, and no third party operates the cluster, so there is no hosting sub-processor (subprocessors.md).
2.2 The following components run inside that cluster and are not offered as public services: the PostgreSQL databases, secrets management (HashiCorp Vault), the background job queue (graphile-worker, on PostgreSQL) and the identity provider for sign-in, SSO and MFA (Keycloak, self-hosted at auth.1ads.net). None of them is exposed directly to the internet: only the edge web server (Caddy) is reachable from the internet, and it publishes the Keycloak sign-in pages, while the Keycloak administrative interface is reachable only from an allowlist of addresses. Error tracking uses the self-hosted Sentry instance that the Company operates, under its FirstIT brand, in the same infrastructure [TBC: confirm network exposure of the Sentry endpoint and the network-policy rule that lets api and worker report to it]. Communication between components is restricted by default-deny Kubernetes network policies: each component may reach only the components it needs.
2.3 Some functions rely on sub-processors, for example AI model providers and transactional email (Amazon SES in the EU). The full list, with locations and purposes, is in subprocessors.md. Third-Party Platforms that the Customer connects (ad platforms, analytics, ecommerce, CRM and social networks), and the identity providers the Customer uses for SSO, are the Customer's own providers, not our sub-processors.
2.4 The public website https://1ads.net is a static site served by the same edge server. It does not use analytics or advertising tools at launch.
3. Tenant isolation
3.1 The Platform is multi-tenant. Customer Data is logically separated by tenant and, within a tenant, by client workspace. Every access to Customer Data is scoped to the tenant and workspace of the authenticated user. Separation is enforced in the database through PostgreSQL row-level security policies per tenant and per workspace, in addition to application checks. The application's database roles cannot bypass row-level security (none of them is a superuser or has the BYPASSRLS attribute). Only the backup role has the BYPASSRLS attribute, so that complete database dumps can be made. That role is read-only (PostgreSQL's built-in pg_read_all_data role), cannot modify data and is used only by the nightly backup job. [TBC – confirm first successful backup and restore.] The public access-request form uses a separate database role that can only insert new access requests and cannot read any data.
3.2 Data received from a Third-Party Platform for one Customer is used only for that Customer. We do not pool such data across Customers (for example, as required by section 5.b of the Meta Platform Terms).
4. Encryption
4.1 In transit over public networks. All public endpoints (https://1ads.net, https://app.1ads.net, the REST API, the MCP server and the sign-in pages) are served over TLS by the edge web server (Caddy), with certificates from Let's Encrypt and HTTP Strict Transport Security (HSTS). [TBC: confirm minimum TLS version 1.2.]
4.2 Inside the private cluster network. Traffic between components inside the cluster (for example between the application and PostgreSQL, or between the token service and Vault) is currently not encrypted. It runs on a single private network and is restricted by default-deny network policies. Encryption of this internal traffic (Cilium WireGuard or TLS) is planned and is scheduled before general availability. [Planned – not yet implemented]
4.3 At rest. Nightly database backups are encrypted (see section 7.3). Encryption at rest of the servers' disks, including the database volumes: [TBC – confirm with infrastructure owner]. We do not claim disk encryption until it is confirmed.
4.4 OAuth tokens and credentials. Tokens for the Customer's connected accounts are encrypted with the HashiCorp Vault Transit engine (AES-256-GCM), under a key derived separately for each tenant, connection and provider. The key material never leaves Vault. Only an isolated token service can ask Vault to encrypt or decrypt tokens, and it does so only when needed to call the relevant Third-Party Platform API. Tokens are never sent to AI models. [TBC: confirm tokens are excluded from logs and error reports.]
5. Identity and access
5.1 Customer users. (a) Sign-in, SSO and MFA are handled by our self-hosted identity provider (Keycloak). Single sign-on (SSO) is available by federation with the Customer's own identity provider, such as Okta, Microsoft Entra ID, Google Workspace or OneLogin; SSO is configured manually for each Customer. Automatic directory synchronisation (SCIM provisioning and deprovisioning) is not available at launch; when a person leaves, the Customer removes them in the Platform (section 12.1(a)). One identity provider is included on Pro, Agency 15 and Agency, and several on Enterprise; on Starter, Growth and Agency Starter, SSO is an add-on per identity provider (Order Form C.2 and C.3). (b) Multi-factor authentication (MFA) is mandatory for all users who do not sign in through SSO. (c) Roles and permissions control who can view data, create proposals, approve changes and publish content. Approval workflows can require several steps (for example agency and then client). (d) During the closed access programme, accounts are created only after the Company manually reviews and approves the access request.
5.2 API and MCP. The MCP server uses OAuth 2.1. API access is limited to the scopes granted. [TBC: API key scoping, rotation and expiry.]
5.3 Company personnel. [TBC: least-privilege access for staff, MFA on all administrative access, logging of administrative access to production, and the rules for support staff accessing Customer Data, for example only at the Customer's request.]
6. AI-specific safeguards
6.1 Human approval. The AI never executes changes on ad accounts or publishes content by itself. Changes run only after an authorised person approves them, or, when later made available, under an auto-approval policy configured by the Customer within the Platform's hard caps. Auto-approval policies are disabled during the Access Program (access-program-terms.md, Section 8.5), without exceptions. See ai-transparency-notice.md.
6.2 Audit log. Every proposal, approval and executed action is recorded in an audit log with pseudonymised user identifiers.
6.3 Prompt-injection defences. Content from web pages, comments, product feeds and documents is treated as untrusted data. AI Features cannot execute actions on their own; tools available to the AI are limited to what the feature needs; and every change requires approval. Residual risk remains and is described in ai-transparency-notice.md.
6.4 Credentials kept out of prompts. OAuth tokens and secrets are never included in prompts sent to AI models.
6.5 LLM observability. We monitor AI quality and errors with Langfuse, self-hosted in our own infrastructure, with redaction of personal data.
6.6 Model providers. We use the commercial APIs of Anthropic (our primary provider; Claude Opus 5.5 by default for the AI chat) and OpenAI (image generation and, optionally, some text tasks). Under the terms currently applicable to us, they do not train their models on API data. We have requested zero data retention from Anthropic. We do not use Customer Data to train AI models.
6.7 Web Intelligence. Web Intelligence reads public pages only, respects robots.txt and text-and-data-mining opt-outs, and never logs in to websites.
7. Logging, monitoring and backups
7.1 Error tracking. We use Sentry, self-hosted in our own infrastructure, to track application errors on the server side. No error data is sent to an external error-tracking service. [TBC: scrubbing of personal data and secrets from error reports.]
7.2 Monitoring and alerting. [TBC: infrastructure monitoring, alerting and on-call arrangements.]
7.3 Backups. The PostgreSQL databases are backed up every night as logical dumps. Each dump is encrypted with age (X25519) before it is written to network storage in the same facility, which is a separate failure domain from the database disk. Only the public encryption key is present in the cluster; the private key needed to restore is kept offline. Backups are deleted after no more than 14 days. The backup job uses a read-only database role. [TBC – confirm first successful backup and restore.] [TBC: restore testing, planned quarterly.] Until database replication is introduced, a failure could lose up to 24 hours of data (recovery point objective of 24 hours).
8. Data retention highlights
8.1 Some data has short retention periods by default: (a) comments and direct messages from connected social accounts: 30 days by default; (b) LinkedIn member data: no more than 24 hours, as required by LinkedIn's API terms; (c) database backups: deleted after no more than 14 days; (d) pseudonymised IP address hash and browser user agent recorded with access requests, and pseudonymised IP address hash and browser data recorded with ROI estimate requests: deleted after 30 days.
8.2 Full retention rules, including deletion when the contract ends, are in data-retention-schedule.md, with summaries in privacy-policy.md and data-processing-agreement.md.
9. Secure development and operations
9.1 Production deployments go through automated pipelines (Jenkins) and GitOps (Flux): changes to production are made through version-controlled configuration, not by hand.
9.2 Secrets are stored in Vault, not in source code, and are delivered to each component separately, so each component receives only its own secrets.
9.3 Container images are scanned for known vulnerabilities (Trivy) in the build pipeline before they are deployed. [TBC: mandatory code review before merge, dependency scanning, patching timelines, and separation of development, staging and production environments.]
9.4 Access-request form. The public access-request form is protected against spam and abuse by a hidden honeypot field and a check of how long the form was open, without any third-party CAPTCHA and without cookies. We store a pseudonymised hash of the sender's IP address (salted SHA-256, truncated) and the browser user agent, both deleted after 30 days. The confirmation email sent to the applicant has fixed text, never repeats what was submitted, and is sent at most once per address in 24 hours.
10. Incident response
10.1 We maintain a procedure for detecting, assessing and responding to security incidents. [TBC: confirm that a written incident response procedure exists before publication.]
10.2 Where an incident affects personal data that we process as a processor on behalf of a Customer, we notify the Customer without undue delay, as set out in data-processing-agreement.md, so that it can meet its own obligations.
10.3 Where we act as controller (for example for account and contact data), we notify the Romanian data protection authority (ANSPDCP) within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people, and we inform the people concerned where required by Article 34 GDPR.
10.4 Business continuity. We have not yet committed to formal recovery time or recovery point objectives. The current technical recovery point is up to 24 hours (section 7.3); database replication with continuous archiving is planned before general availability. Any service level commitments are those set out in service-level-and-support.md and the Order Form.
11. Compliance status and roadmap
11.1 Current status. No certification or third-party attestation. [TBC: whether an independent penetration test has been performed and, if so, when.]
11.2 Planned. [TBC: certification roadmap to be confirmed by the founder.] We will update this page if an audit is planned.
11.3 Questionnaires. We can answer reasonable security questionnaires from Customers and prospects, under a non-disclosure agreement where needed. Write to ops@1ads.net.
12. Shared responsibility
12.1 Security is shared. The Customer is responsible for: (a) managing its Authorized Users, roles and approvers, and removing access promptly when people leave; (b) using SSO or MFA and protecting its credentials, API keys and OAuth clients; (c) granting only the necessary scopes when connecting Third-Party Platforms, and revoking connections it no longer needs; (d) configuring approval workflows and, where available, auto-approval policies with care; (e) vetting the MCP clients and AI agents it connects to the Platform; (f) the security of its own systems and of the Third-Party Platforms it uses.
13. Vulnerability disclosure
13.1 How to report. If you believe you have found a security vulnerability in the Platform, please write to ops@1ads.net with a description, the affected URL or component, the steps to reproduce and the potential impact. Please do not include personal data of others in your report beyond what is strictly necessary. [TBC: publish /.well-known/security.txt (RFC 9116) and a PGP key.]
13.2 What we do. We aim to acknowledge reports within 2 Business Days, to keep you informed of our progress, and to tell you when the issue is fixed. With your agreement, we will credit you publicly once the issue is resolved.
13.3 In scope. https://1ads.net, https://app.1ads.net, the public REST API and the MCP server operated by the Company.
13.4 Out of scope. Third-Party Platforms, our sub-processors' services, Customer-operated white-label domains not hosted by the Company, social engineering of staff or Customers, physical attacks, denial-of-service attacks, and automated scanning that generates significant traffic.
13.5 Testing rules. Please: (a) use only accounts you own or test accounts we provide. Because access is currently by approval only, you can request a test tenant at ops@1ads.net; (b) not access, modify or delete data of other users or Customers; if you encounter such data, stop, do not keep a copy, and tell us; (c) not degrade the service or affect other users; (d) not exploit the vulnerability beyond the minimum needed to demonstrate it; (e) give us reasonable time to fix the issue before any public disclosure; we propose 90 days, or sooner if we agree; (f) comply with the law.
13.6 Safe harbour. If you act in good faith and follow these rules, we will consider your research authorised, will not bring legal action or file a criminal complaint against you in connection with it, and will not ask anyone else to do so. If a third party brings legal action against you for research carried out under these rules, we will make it known that your research was authorised by us. This safe harbour covers only systems operated by the Company; we cannot authorise testing of systems that belong to others, such as Third-Party Platforms or sub-processors. It does not cover activity that breaches the rules above or the law.
13.7 No bug bounty. We do not currently offer monetary rewards for reports.
14. Contact
- Security reports and questionnaires: ops@1ads.net
- Personal data questions: privacy@1ads.net
- Support: support@1ads.net