Security Policy

1. Scope and responsibility

• This policy covers the SaaufAI website, the API, the Playground, Wisps, Apps, the Safeguards program and the admin panel at ai.saauf.xyz, and the systems they run on.
• SaaufAI is run by a private individual based in Poland, who is responsible for every part of this policy: setting it, applying it, checking it and changing it. There are no employees or contractors.
• If anyone else is ever given access to production systems or personal data, they must first sign a confidentiality agreement and accept this policy, get their own accounts (never shared ones) with only the access they need, and lose that access the same day their role ends.
• The main legal requirements are the GDPR (in particular Art. 5(1)(f), 25, 28 and 32 to 34) and the Polish data protection act. SaaufAI is a micro operator, so it falls outside the NIS2 Directive and the Polish national cybersecurity system act (ustawa o krajowym systemie cyberbezpieczeństwa); we check this again every year. AI transparency duties under the EU AI Act (Art. 50) are covered in the Legal notice and the Model disclosures.
• We publish a STAR for AI Level 1 self-assessment (CAIQ v4.1 and AI-CAIQ) with the Cloud Security Alliance. It is our own assessment, not an independent audit or certification.

2. Where the service runs

• Vercel hosts the website, API and Wisps as serverless functions.
• Google Cloud runs the API server at api.saauf.xyz on a hardened virtual machine (USA) reachable only on HTTPS, with administrator access only through Google's identity-aware proxy, and keeps the database backups in the EU (Warsaw).
• Supabase runs the database in the EU (Frankfurt). The database cannot be reached from browsers; only the server talks to it, with a key held as a server secret.
• SaaufAI has no offices, servers or datacenters of its own. Physical and environmental security (buildings, power, cooling, hardware and its disposal) is handled by these providers and the cloud datacenters they use, under their own independently audited security programs.
• The full list of providers that process personal data, and where they are, is in the Privacy Policy.

3. Classes of data

4. Encryption and keys

• All traffic to SaaufAI, to the database and to upstream providers uses TLS (HTTPS).
• Upstream provider keys, connection keys and App credentials are encrypted at rest with AES-256-GCM. Passwords are stored as scrypt hashes; API keys and session tokens only as SHA-256 hashes, so we cannot read them back. Session cookies are signed with HMAC-SHA256 and are HTTP-only and secure.
• Keys and tokens are generated with a cryptographically secure random number generator. Each secret has one purpose (data encryption, session signing, push notifications, webhook verification) and is kept only as an encrypted environment variable on the hosting platform, never in the code repository.
• A secret is rotated at once if it may have been exposed. You can revoke your own API keys at any time; upstream provider keys can be withdrawn from the admin panel immediately.
• We do not offer customer-managed encryption keys.

5. Access control

• Production: only the operator has access to the hosting, database, email, code repository, domain and alerting accounts. Each of these accounts uses multi-factor authentication and a unique password from a password manager.
• Admin panel: reached through an unadvertised sign-in path and limited to one Discord identity. Anyone else gets a plain "not found". Every admin page and action checks the signed admin session.
• Your account: passwords need at least 10 characters and may not be built from your email address; repeated failed sign-ins are slowed down; a sign-in with an unknown email takes as long as a wrong password. Multi-factor sign-in is not offered yet.
• API keys: random, shown once, and can be limited to one model or provider, to a rate per minute, hour or day, and to a token, request, spending or date budget.
• Separation between accounts: every query is limited to the signed-in account or the API key's owner, and row level security is enabled on database tables.
• The operator looks at customer data only when needed to run the service, answer a request, investigate abuse or meet a legal duty.

6. Changes and development

• Every change to the code and the database schema is a reviewed commit in a private git repository, and database changes are numbered migrations applied in order.
• Before a change is deployed it is type-checked and, where it affects what users see, tried in a preview. Deployments are built by the hosting platform from the repository, and any deployment can be rolled back to the previous one at once.
• Secrets are never committed. Production data is not copied into development or test environments.
• Changes that affect how personal data is used are reflected in the Privacy Policy before they go live, and account holders are emailed before significant changes.

7. Vulnerabilities and dependencies

• The code uses few third-party packages, from the official npm registry, with versions pinned in a lockfile.
• At least once a month we check dependencies for known vulnerabilities and apply security updates for the framework and libraries. Fixes are applied within 7 days for critical issues, 30 days for high and 90 days for others, sooner if a problem is being exploited.
• Reporting a problem: email ai@saauf.xyz or use the support page (scope and rules are on the Security disclosure page). We reply within a few days, keep you updated and credit you if you want. We will not take legal action over good-faith research that respects other people's data, avoids disrupting the service and does not run automated scans at volume.

8. Logging and monitoring

• For each request we log metadata only: which key and account, which model, token counts, cost, status and timing. Safeguard events record which rule fired. Content is not logged.
• Logs are kept for 30 days and then deleted by an automatic daily cleanup; only daily totals per model and key stay, for 365 days. They are only reachable server-side and in the admin panel.
• Accounts are scored automatically for signs of abuse or unusual activity, and the operator reviews flagged accounts. Safeguards and failures can send alerts to the operator straight away.
• Models and providers can be health-checked at any time. Upstream failures are detected automatically and traffic moves to another key, provider or disclosed fallback.

9. AI-specific safeguards

• Each model's provider, fallbacks and safeguard model are disclosed on its page, so you know where your prompts go.
• Safeguard rules limit request rates, token budgets and input size, and can screen content categories with a classifier model, before a request reaches the model.
• Wisps ask for your approval before actions you have not allowed in advance, such as sending email. Text they read from emails, websites or Apps is treated as information, not instructions from you.
• Text sent to the Safeguards program is checked in memory and not stored or used for training.

10. Security incidents

1. Notice: from alerts, monitoring, a provider's notification or a report to ai@saauf.xyz.
2. Contain: for example revoke or rotate keys and secrets, disable accounts, models or providers, declare an outage, or roll back a deployment.
3. Assess: what happened, which data and people are affected, and how serious the risk is.
4. Notify: where a personal data breach is likely to result in a risk to people, we notify the Polish supervisory authority (Prezes Urzędu Ochrony Danych Osobowych) within 72 hours of becoming aware of it (Art. 33 GDPR); where it is likely to result in a high risk, we tell the people affected without undue delay (Art. 34). If it concerns text we process for a Safeguards program member, we tell that member without undue delay (Art. 33(2)). Serious incidents may also be reported to CERT Polska, and crimes to the police.
5. Fix and learn: remove the cause, check that the fix works, and update this policy or the service where needed.

Every personal data breach is recorded with its facts, effects and the actions taken, including breaches that did not need to be reported (Art. 33(5) GDPR).

11. Availability and backups

• Models can have several providers and an ordered list of fallbacks; upstream keys are pooled, rotated and skipped automatically when they fail; outages are shown on the affected model pages.
• The database is a managed Supabase database. Every night it is also backed up to Google Cloud Storage in the EU (Warsaw), encrypted at rest and kept for 30 days; the backup job can add backups but not change or delete them. At least once a year, and after significant changes, we check that a backup can be restored.
• The code and database migrations live in a git repository with a copy off the hosting platform, so the service can be rebuilt.
• SaaufAI does not promise a level of availability (see the Terms).

12. Suppliers

• We choose providers that offer data processing terms under Art. 28 GDPR, publish independent security attestations, and store data in the EU where possible.
• Providers that process personal data for us are listed in the Privacy Policy; upstream AI providers are shown on each model's page. We review the list and each provider's terms at least once a year and before adding a new one.

13. The operator's devices

• Devices used to run SaaufAI have full-disk encryption, a screen lock after a few minutes, a firewall, and current operating system and browser updates.
• Secrets are kept in a password manager, not in documents or messages. Personal data is not copied to devices except when needed for a task, and is deleted afterwards.
• A lost or stolen device is handled as a security incident: its sessions are signed out and the secrets it held are rotated.

14. What is up to you

Security is shared. We look after the service; you look after how you use it:

• Keep API keys secret: not in client-side code, public repositories or screenshots. Use a separate key per app, scope keys and set limits, and revoke a key straight away if it may have leaked.
• Use a strong, unique password for your SaaufAI account.
• Pick models by their disclosures, and do not send special categories of personal data or data about children unless you have to and are allowed to.
• Review what you let Wisps do, and the Apps and connections you give them.
• If you use SaaufAI in your own product, tell your users how their data is processed, including that it is sent to the AI providers shown on each model's page.
• Tell us at once at ai@saauf.xyz if you suspect misuse of your account.

15. Review

We review this policy at least once a year, and after any significant change to the service, the law or our providers, or after an incident. The effective date at the top shows the current version.

Related

• Privacy Policy
• Terms of Service
• Acceptable Use Policy