Security

Everything you upload sits in private storage under one account. The buckets are closed to the public internet, so nothing in them has an address that works without a signature, and the signatures are short-lived: a finished render's download link lasts an hour.

• Account-scoped. Every request authenticates as one account. A source group, cut or render belonging to another account is not visible to it: the API answers 404 not_found, because a 403 would confirm that someone else's material exists, and that is not ours to confirm.
• Signed access. API uploads go to a signed URL issued per file; dashboard uploads are session-authenticated and land in the same private buckets. Downloads come back as signed links with an expiry on them, fetched from the same call that reports a render's status.
• The account is the boundary. Inside one, access is account-wide: roles govern settings, billing, members and invites rather than which libraries a person can open. Library and asset permissions are on the roadmap, so today an account is the unit you would hand to a team.
• Deletion reaches storage. Deleting a source group removes the uploaded original and the derivatives made from it - the mezzanine, the extracted audio, the preview proxy - and then the record. Deleting a cut takes its renders and their sidecars with it. A group that is mid-ingest refuses to delete until that job ends, so nothing is pulled out from under a running worker.
• Nothing expires on a timer. There is no retention schedule and no archive tier: what you load stays until it is deleted. The single exception is an account left in arrears for months, which is warned by email repeatedly before its library is reclaimed.

The developer-facing version of this - exact fields, formats and boundaries - is in the security notes in the docs.

Keys are minted in the dashboard, under Settings. The raw key is shown once, at the moment it is created, and never again.

• Hashed at rest. We store a SHA-256 hash of the key and never the key itself. If it is lost there is nothing for us to recover, and issuing a new one is the only route.
• Scoped. Every key carries read, write or admin - or, if none is selected when it is minted, all three; the dashboard says so at the point of choice. A read key cannot start a render; deleting material, registering a webhook endpoint and managing brand kits need admin. A call outside a key's scope returns 403 insufficient_scope.
• Revocable. Revoke a key in the dashboard and it stops authenticating. Scope is the only boundary a key carries - within its scope it reaches everything in the account - so issue one per integration, tick the scopes it actually needs rather than leaving them blank, and revoke on suspicion.
• A key cannot mint another key. There is no API endpoint that creates API keys - the dashboard is the only route, so a leaked key cannot quietly extend itself.
• Rate-limited per key and per account. The ceilings are 60 requests a minute for a key and 120 for the account it belongs to, so a stolen key is throttled long before it becomes interesting. Every authenticated response carries x-ratelimit-remaining.

The developer view of the same surface - scopes per endpoint, error shapes, idempotent replays - is on the API page.

Endpoints are registered with an admin key, over HTTPS only, and the URL is checked before it is accepted: an endpoint pointed at a private address is refused.

• The secret is shown once. A 32-byte secret comes back from the registration call and is never returned again - listing your endpoints does not include it. It is redacted from stored idempotent replays too, so repeating the creation call cannot hand it back.
• Every delivery is signed. Each request carries anjin-signature: t=<unix seconds>,v1=<hex> - an HMAC-SHA256 over the timestamp, a full stop, and the exact body, keyed with your endpoint secret.
• Verify before you trust it. Recompute the HMAC over t.body, compare it in constant time, and reject a timestamp more than five minutes from your own clock. A request that fails either check is not from us.
• Delivery is at-least-once. A delivery times out at ten seconds; anything but a 2xx is retried with backoff, up to twenty attempts, and an endpoint that exhausts twenty deliveries in a row is disabled until you re-register it. Write the handler to tolerate a repeat.
• Payloads carry references. An event names itself, the account, the ids involved and a short summary: the aspect, the duration, whether QC passed. No transcript, media or signed link rides along with it.

Six vendors, each with a job and a boundary. That is the whole list for the platform.

Two things worth adding. Our own operational alerts go to an internal chat webhook and carry no customer material. And there is no monitoring vendor in the path at all - no error-tracking service, no metrics pipeline, no session recorder inside the platform. What this website measures is a separate question, answered on the cookies page.

The maintained list, with each vendor's role and the data it processes, is the sub-processors page. Changes appear there.

We do not train models on your media. There is no Anjin model to train: planning calls Anthropic's API and transcription calls AssemblyAI's, and nothing you upload is used to build anything of ours or shown to another customer.

What those two do with what they receive is set by their own published terms, and the two are not the same, so this page states them separately instead of averaging them. Anthropic's commercial terms say that Anthropic may not train models on customer content. AssemblyAI's terms of service reserve a right to use customer data to develop their services and train their models, with an opt-out that depends on the plan; where our account stands on that opt-out is being confirmed with them, and this paragraph will carry the answer when it is. Their security page names Dublin as the European processing centre behind the EU endpoint we call.

Nothing is carried between accounts, or between one brief and the next. The platform keeps no learned house style: a plan is composed from the transcript and the brief in front of it, and a brand kit applies your fonts, colours, logo and end card at render because you attached it.

The things a procurement pack asks for that we do not have:

• SOC 2Neither Type I nor Type II.NOT HELD
• ISO 27001No certification.NOT HELD
• External penetration testNone has been carried out.NOT HELD

There are no trust badges on this site, because there is nothing to put on one. What does exist: a UK company you can look up, the ICO registration printed at the foot of this page, a sub-processor list with nothing left off it, and this document. If any of the three above changes, this page will say so, with the date.

Send a security questionnaire to legal@anjin.media and we will answer it directly.

Email security@anjin.media with what you found, how to reproduce it, and what it would let someone do. Include the account or key you tested with so we can trace it.

• Acknowledgement in two working days. A person replies to say we have it and who is looking. You hear from us again when it is fixed.
• Safe harbour. Test only against your own account; do not access, alter or delete anyone else's data; do not degrade the service for other people; give us a reasonable window before you publish. Report on those terms and we will treat the work as done in good faith and will not pursue a claim over it.
• No bounty programme. We do not pay for reports. We will credit you by name if you want that.

One honest note: the addresses this site publishes are new, and the mailboxes are being brought up ahead of launch. If a message bounces before then, that is the reason, and clearing it is our job.