Version 1 · Last updated 2026-09-05
Starkie Teams handles something people are rightly protective of: photographs of their face. This page describes the technical and organisational measures we apply, and it is the security annex referenced by our Data Processing Addendum. Starkie AI is based in Italy; the service runs on infrastructure in the United States and the European Union, listed at /legal/subprocessors.
All traffic to and from the application travels over TLS. Uploaded selfies and generated images are stored in Amazon S3 with server-side encryption at rest; the database is encrypted at rest by our managed Postgres provider.
Every photo in Starkie Teams lives under a private storage prefix, and the application never hands one out except as a short-lived presigned link: an hour for the galleries and downloads people see, and up to 24 hours for the links our generation provider needs to read a member's uploads. A link stops working once it expires. The application never links a member's selfies, headshots or branded profile picture from our public CDN, and never embeds them in an email.
Administrator access to an organisation is role-based: only signed-in users who are an owner or an admin of that organisation can reach its data, and requests from anyone else are answered as if the organisation did not exist, so membership is not leaked. While Starkie Teams is unreleased, an email allowlist gates the admin app on top of that.
Members never create an account. They reach their own consent, upload and gallery pages through an unguessable token in their invitation link, which is scoped to that one member and is invalidated when their data is deleted. Infrastructure credentials follow least privilege: the application's storage and email keys carry only the permissions the service actually uses.
Every stored object is namespaced by organisation and by member, and every database query for organisation data is scoped by organisation. One customer's people, photos, credits and settings are never visible from another customer's admin app, and a download archive is built only from the members of the organisation that requested it.
Uploaded selfies are deleted a set number of days after a member's photos are ready — the organisation chooses between 7 and 90 days, 30 by default — by a scheduled job. The private model trained on those selfies is deleted at the same time, unless the organisation has opted in to keeping it so members can retake without re-uploading.
A member can delete everything from their own privacy page. The purge removes their uploads, their generated images, the trained model and any download archive that contains their photos, then anonymises their record. An administrator can remove a member with the same effect, and an organisation can ask us to delete all of its data. Privacy-relevant actions — consent, deletion requests, purges, member removal — are written to an audit log, and a completed deletion is confirmed by email with a deletion certificate.
We use a small number of providers to run the service, listed with their purpose and processing region at /legal/subprocessors. Each is bound by data protection terms, and we give organisation administrators 30 days' notice by email before adding or replacing one.
The database is backed up by our managed Postgres provider with point-in-time recovery. Backups inherit the provider's encryption, and we never use a restore to bring back data a member has deleted. Generated images are stored durably in S3; built download archives are deliberately short-lived and are removed automatically.
We investigate suspected incidents as they arise. Where an incident is a personal data breach affecting a customer's data, we notify that customer without undue delay and within 72 hours of becoming aware of it, and assist with their own notification duties. We keep dependencies patched and monitor application errors continuously.
If you believe you have found a security problem, email security@starkie.ai with enough detail to reproduce it. We will acknowledge your report, keep you updated while we fix it, and we will not pursue researchers who report in good faith, avoid privacy violations and give us reasonable time to respond. Please do not test against real members' data.