Security
How we protect marks and data.
How marks and per-creator keys work, how your data and your fans' details are protected, the limits we are honest about, and how to report a problem.
At a glance
Strong defaults, honest limits.
Per-creator keys
Each creator's marks use their own secret key, derived on use and never stored.
HMAC-SHA256 tags
Current copies carry a 256-bit keyed tag spread across layers.
Encrypted secrets
Integration keys and tokens are encrypted; passwords use Argon2.
Not unbreakable
Marks are tested against published conditions. No system survives every change.
In full
Eight sections, in plain English.
1. How marks work
Trace gives each recipient's copy its own invisible mark. A mark is a code, not a name: it points to a delivery record in the creator's account. Each copy carries more than one layer:
- a learned watermark embedded in the picture or sound;
- a second, keyed layer and small keyed changes to the file, made with the creator's own secret key;
- for current copies, a 256-bit tag computed with HMAC-SHA256 from the creator's key and the delivery, with each layer carrying part of it.
When you run a leak check, Trace reads what it can from the leaked copy and compares it with that creator's delivery records. A match means the leaked copy was made from the copy delivered to a particular account.
2. Per-creator keys
- Every creator has their own secret marking key. A mark made with one creator's key cannot be read as another creator's mark.
- Keys are not stored in the database. Each is derived when needed from a master secret held in the hosting environment, using HKDF. A short check value lets the service detect a wrong master key.
- Keys are never returned through the app or API.
- Keys can be rotated. Copies marked with an older key stay checkable.
3. Protecting your data
- In transit: all traffic uses TLS.
- Secrets at rest: integration API keys, access tokens, webhook secrets and two-factor secrets are encrypted at the application level before they are stored.
- Media at rest: files in Cloudflare R2 are encrypted at rest by Cloudflare.
- Passwords: hashed with Argon2. We cannot see your password.
- API keys: shown once; we store only a keyed hash (HMAC-SHA256).
- Vault links: one-time links that expire; the IP address and browser that opened one are deleted after 90 days.
- Webhooks: signed in both directions so each side can check a message is genuine.
4. Access control
- Every request is checked against the signed-in account; one account cannot read another's fans, content or cases.
- Agency teams have roles (owner, manager, chatter) and an audit log of actions.
- Two-factor authentication (authenticator app) and passkeys are available on every account.
- API keys can be scoped and revoked at any time.
- CreatorSense staff access to customer data is limited to what is needed for support and security.
5. Honest limits
No security or watermarking system is perfect, and we do not claim ours is.
- Marks are tested against the changes listed in the robustness report. Heavier edits, re-creation with AI, or combining several people's copies can defeat a match.
- A match shows which account a copy was delivered to, not who shared it.
- A no-match result is inconclusive.
- Marks do not stop copying or screen recording.
- We rely on our hosting and storage providers' security as well as our own (see Subprocessors).
6. Standards we build to
Our security and privacy practices are aligned with ISO 27001 (information security management), ISO 27035 (incident management) and the GDPR, together with the Australian Privacy Act. These are the standards we build to and hold ourselves to. Formal certification is planned; we do not claim to be certified today.
7. Incidents
If we find a security incident, we contain it, investigate, fix the cause and keep a record. If it affects your personal information or your fans' details, we tell you without undue delay, and we notify the OAIC and affected people where the Notifiable Data Breaches scheme requires. Customers under the DPA are notified as section 6 of the DPA sets out.
If you think your account has been accessed by someone else, change your password, revoke your API keys and email info@creatorsenseai.com straight away.
8. Reporting a vulnerability
Email info@creatorsenseai.com with the subject "Security report", what you found and how to reproduce it. Please:
- give us a reasonable time to fix it before telling anyone else;
- only test against your own account and data;
- do not access, change or delete other people's data, degrade the service, or use social engineering;
- do not run automated scans or load tests.
If you follow these rules and act in good faith, we will not take legal action against you for the research, we will keep you updated, and we will credit you if you want. We do not run a paid bug bounty.
CreatorSense, a business name of Matt Orchard (sole trader), ABN 65 815 285 275, Sydney NSW, Australia.
Other legal documents: Privacy Policy · Terms of Service · Acceptable Use Policy · Refund Policy · Referral Programme Terms · Data Processing Addendum · Subprocessors · Cookie Policy · Copyright Policy.
Questions
Ask us anything about security.
info@creatorsenseai.com · CreatorSense · Sydney NSW, Australia. We answer by email; there are no calls to book.