Slicer security

You trust Slicer with personal videos, your voice and your texts. This page describes in detail, without marketing, how we protect them: what is encrypted and how, who can get access and under what conditions, and what happens when you sign in, pay and delete your account. We deliberately don't publish details that would make an attack easier — key names, internal addresses and detection thresholds.

Found a vulnerability? Write to security@slicer.media — how to do it is described at the end of this page, in "Reporting a vulnerability".

1. Principles#

• Minimal data. We collect only what the service can't work without: montage materials, an email for signing in, the history of token transactions. We don't receive card details at all.
• Encryption by default. User files and sensitive database fields are stored only in encrypted form. A disk copy, a backup or a database dump is useless without the server key.
• Owner-only access. Every request checks that the object belongs to you. Someone else's project doesn't exist for you — even knowing its id gives nothing. A file is additionally checked against the owner recorded in its encrypted header.
• A log for every access. Sign-ins, sign-outs, deletions, staff actions and any access to user data are written to a security log that can't be altered unnoticed.

What this protects against#

Honest limitations#

• The server decrypts data while it works. Montage, AI analysis and serving your video require the plain content. Encryption protects data "at rest" — on disks, in backups and dumps — but not from someone who has fully taken over a running server. That's why keys are stored separately from data and access to servers is restricted.
• AI providers receive fragments of materials — exactly as much as the montage needs (section 12). End-to-end encryption "only on the user's side" is impossible with server-side AI montage.
• Your device. A browser may cache videos, and the app keeps the sign-in token in the system's secure storage (Keychain). Protect your device with a passcode.

2. File encryption#

All user files — sources, your own photos, videos and music, finished videos, covers — and project working directories are stored encrypted.

• Algorithm — AES-256-GCM. A file is encrypted in blocks, and each block is authenticated: the block number and the "last block" flag are part of the authentication, so blocks can't be reordered and a file can't be truncated or swapped unnoticed. Seeking in a video decrypts only the blocks it needs.
• A key per file. A file key is random (256 bits) and is kept in the file header only in wrapped form: with the server master key and with the escrow public key (section 4). The master key lives in the server's environment secrets — not in code, not in the database and not in file storage.
• The owner is authenticated. The file header contains the owner and the kind of object, and they're authenticated too. When serving a file, the server checks the owner: if a user's record somehow ended up pointing to someone else's file key, the file isn't served and the attempt goes to the log.
• Key rotation re-encrypts only file headers; the content doesn't need rewriting.

Where a file is ever decrypted#

A working directory is decrypted only under a job's lease. If a process crashes, the lease expires and a regular check finds abandoned directories and encrypts them again. Files are replaced atomically: a reader never sees a half-written file.

3. Database encryption#

Sensitive database fields are encrypted separately, with a key derived from the master key:

• personal data — email, name, login, sign-in provider tokens;
• texts and documents — project and file titles, edit documents, speech transcripts, frame descriptions, director plans, wishes for the director, AI effect prompts;
• devices and logs — IP addresses and browser details of sessions, details of security log entries;
• social accounts — platform access tokens, account names, publication titles and descriptions;
• API — API token names, the last IPs they were used from, webhook signing secrets;
• descriptions of token transactions.

Service values — ids, statuses, sizes, durations, amounts, style settings — aren't encrypted: search, sorting and accounting rely on them. Search over encrypted fields (for example, by project title) runs in server memory, not in the database.

• Email is looked up by a blind index — a keyed cryptographic hash. It finds the account at sign-in but can't be turned back into the address.
• Passwords are stored as an argon2id hash with parameters at or above OWASP recommendations, and the hash itself is also encrypted. A password can't match the email and mustn't be on the list of common passwords; there are no "digit and capital letter" rules — following NIST, length matters more.

4. Staff access#

Sometimes access to a material is genuinely needed — for example, at the user's own support request or under a lawful demand. There's a single way to do it, and it's designed so it can't be used secretly.

• Escrow key. Each file key is additionally wrapped with an RSA-OAEP public key (SHA-256, at least 3072 bits). The private part of this key is kept offline by one responsible person — the super administrator — on encrypted media and never reaches the server.
• The server doesn't decrypt files for staff. It hands out only ciphertext; decryption is possible only on the super administrator's computer with their private key.
• Every access has a reason. To get ciphertext, the super administrator signs in to the admin panel with a password and a one-time code (TOTP), recently re-confirms with a code, and states the reason — a ticket or request number. The log entry is written first, then the file is handed out; no entry, no file. Even viewing the list of a user's objects is logged.
• The log can't be rewritten. The security log is append-only: changing and deleting entries is forbidden at the database level, and each entry contains the hash of the previous one. A deleted or altered entry breaks the chain, and verification shows it.
• The admin panel is a separate application at its own address, with its own session and a strict content security policy. A regular user session doesn't work there, and modifying actions require a fresh code confirmation and are logged.

5. Sign-in and sessions#

• Server-side sessions. A session is stored on the server; the token in the browser or app is just its reference. Signing out revokes the session immediately. Profile → Sign-in and security lists every device; you can sign out of one or of all others. A session lasts up to 30 days and ends after 14 days of inactivity.
• Browser cookies use the __Host- prefix, Secure, HttpOnly and SameSite=Strict: page scripts can't see the cookie and other sites can't send it.
• Cross-site request forgery (CSRF) protection. A modifying request with a cookie is accepted only from Slicer app origins — by the Origin header. The API accepts only JSON.
• Sign-in in the app for iPhone, iPad and Mac goes through the system browser. The app receives a one-time code that lives for minutes and can be exchanged for a session only together with a secret issued to that app at the start of sign-in — on the PKCE principle. Another app that intercepts the code won't get a session. The session token is kept in the system's secure storage.
• Email and password. Sign-up and password recovery use a code sent by email. Responses to sign-up and "Forgot your password?" are the same for a taken and a free address, and sign-in response time is equalized — they can't reveal whether someone has an account. Sign-in and code attempts are rate-limited.
• Google, Apple, VK ID. A provider account is linked to an existing Slicer account only by an email the provider has verified. An unverified email gives no access to someone else's account.
• Confirmation for important actions. Changing email or password, deleting the account and creating an API token require a recent sign-in — otherwise Slicer asks you to confirm it's you.

6. API and MCP#

• API tokens. A token is 256 random bits with the recognizable slc_ prefix and a checksum: leak scanners find it in repositories, and the server rejects forgeries before even looking it up. The database stores only an HMAC of the token — the token itself is shown once and can't be recovered. A token has scopes, an expiry and a monthly spend limit; it can be revoked instantly in your profile and is revoked automatically when the account is deleted or blocked. You get an email when a token is created.
• Header only. The public API and MCP accept a token only in the Authorization header and don't accept cookies — a website open in your browser can't act on your behalf.
• OAuth 2.1 for AI agents. PKCE (S256) is required, the token is bound to a resource — the Slicer MCP server (RFC 8707), and the authorization response includes the issuer (RFC 9207), which protects against server mix-up. Redirect addresses are checked and dangerous schemes are forbidden. An authorization code is single-use and lives 10 minutes, an access token lives an hour. Refresh tokens are replaced on every use, and reusing an old one — or reusing an authorization code — revokes the whole connection; this is how theft is detected.
• The consent screen shows which app is asking for access, where the response will return, which permissions and what spend limit you are granting. Dynamically registered apps are marked as unverified.
• Price confirmation. No paid API or MCP operation spends tokens without an explicitly confirmed price, and the spend limit keeps the budget from being exceeded even if there's a bug in a program or in a model's reasoning.
• Frames for your AI assistant — only on request. When the assistant edits by itself (Your own director), frames of the sources go to the AI you chose — only with your token with the projects:read scope, only the frames the assistant asked for (up to 16 per call, 512 pixels), and only in the tool result: no links to files appear. Frames are extracted under the same working-directory protection as rendering and deleted right away.
• The director's rules stay on the server. The assistant gets only your material — speech by words, pauses, retakes, wishes — and general tips: the rules and lessons of the Slicer AI director are not in the brief, the MCP prompts or tool results. The rules are applied to the assistant's plan on the server, and the answer brings fixes and issues. For the same reason the Chat doesn't show the director's task (The director’s brief) by default.
• The assistant's plan is data. A video plan and observations from the frames sent by the assistant execute nothing: Slicer checks them with the schema, applies its rules to them, and only then saves the video as a new revision.
• MCP protection against address spoofing. Browser requests to the MCP server are accepted only from trusted origins — this protects against DNS rebinding attacks.
• Rate limits are counted per token and per connection; idempotency keys rule out double charges on retries.

7. Webhooks#

• Every event is signed with HMAC-SHA256 with a timestamp in the Slicer-Signature header. The receiver verifies the signature and rejects requests older than 5 minutes — so an intercepted event can't be replayed (how to verify).
• The signing secret is shown once and stored encrypted.
• A webhook address must be a public https URL; it's checked on creation and before every delivery, and redirects aren't followed — so a webhook can't be pointed into Slicer's internal network.
• Event bodies contain no secrets or tokens — only the same data the API returns to the owner.

8. Server protection#

• Outgoing requests (SSRF). When the server downloads a file by link — an AI result, a URL import, an upload to a social network — it connects only over https and only to public addresses, checking every redirect and limiting the size. Internal networks, cloud metadata addresses and local addresses are unreachable.
• Video processing without network access. The video processor runs without a command shell, with a timeout and with network protocols disabled; user files are opened only from an allowlist of formats for their kind. Playlists and lists inside a "video" that could be used to read server files are never opened.
• Upload checks — by extension and by the file's actual content, with limits on size, duration and frame resolution. File names are cleaned of paths, control and invisible characters. Upload quotas protect against filling up the disk.
• Rate limits — by address and by token, separately for sign-in, paid operations and uploads.
• Security headers: a strict content security policy (CSP), HSTS, Referrer-Policy: no-referrer, Cross-Origin-Resource-Policy, no caching of API responses with personal data, timeouts for slow requests.
• Configuration check at startup. In production mode the server won't start with unsafe settings: weak or default secrets, missing encryption keys, addresses without https.
• Errors without details. Clients get a clear error code and message, but not internal messages, paths or responses from third-party services.

9. Links that work without signing in#

Files are served only to their owner — after signing in or with an API token. There are three exceptions, all narrow and temporary:

There are no public download links for finished videos.

AI access to project files#

Normally Slicer hands AI services the pieces they need directly, without links. But some models only take a file by address — right now that's object removal. For them these rules apply:

• Only with permission. Without it no file leaves: before the operation Slicer shows the AI access to a file window — Allow once, Allow for this project or Don’t allow. A project permission works only in that project and is turned off in its Settings; it's off by default.
• Only the piece that's needed. For object removal — a piece of the fragment up to 5 seconds long and the object mask, each with its own link. Not the whole source, the project or the account.
• Briefly. A link is valid for an hour at most and is revoked right after the model responds; the copy of the piece is deleted. Links that couldn't be revoked right away (for example, during a server restart) are killed by a regular cleanup when they expire.
• Encrypted. The copy of the piece is stored encrypted, like all user files, and is served only through the link, with caching disabled. The link itself is 256 random bits; it isn't written to the log.
• Log. Every issued link is visible to you in the project's Settings, in the Issued links list: what for, what was opened (the source number and the seconds of the piece, with no text or file names), when it was issued, how many times it was downloaded and whether it's revoked. Revoke all links kills active links immediately, and so does turning the toggle off. Issuing a link and every download are also written to the server log.

For users — AI access to files.

10. Payments#

• Packs are paid for on a YooKassa page — card details are entered there; Slicer neither receives nor stores them.
• Tokens are credited only after the server itself has requested the payment status from the YooKassa API. We don't trust the content of an incoming notification: it's only a reason to check.
• The YooKassa response is matched against our record: the payment id, the amount and the link to the purchase. A mismatch isn't credited and is logged.
• Crediting is idempotent: a repeated notification or check won't credit tokens twice. Unconfirmed payments are regularly reconciled with YooKassa.
• Every token movement is an append-only record; the balance is computed from them, never edited by hand.

11. Retention and deletion#

Deleting your account (Profile → Sign-in and security) is irreversible: all sessions, API tokens and connected apps are revoked, running operations are stopped, projects, files and templates are deleted, Sign in with Apple access is revoked, and the user record is anonymized — email, name, password and codes are erased.

What remains after deletion:

• anonymized payments and token transactions — required for accounting;
• the security log — it's append-only, and entry details are encrypted;
• a "free video used" marker — as a blind index of the email that can't be turned back into the address. It's needed so the free first video can't be claimed again by re-creating the account.

12. AI providers#

The montage is performed by AI models from external providers. Each receives only what its task needs:

• We use providers' API plans under which customer data isn't used to train models.
• Provider results are temporary links; the server downloads them immediately (with the same SSRF checks) and saves them to encrypted storage.
• Your text — wishes for the director, assistant commands — is passed to the model as a separate block explicitly marked as user data rather than instructions, with a note that the response format must not change. The model's response is always validated against a strict schema, and cut timings by a deterministic validator.
• Passing data to providers is described in the terms of service.

Reporting a vulnerability#

If you've found a vulnerability in Slicer — in the apps, the API, the MCP server or the websites — write to security@slicer.media. Contacts for researchers are also published in the /.well-known/security.txt file.

What to include:

• where the vulnerability is: an address, endpoint, screen or app version;
• steps to reproduce and what you were able to obtain;
• how to reach you for follow-up questions.

We ask researchers to:

• test only on your own accounts and data, and not access or modify other people's data;
• not load the service (no DoS or mass brute-forcing) and not use social engineering against users or the team;
• not disclose the vulnerability publicly until we've fixed it.

We'll confirm receipt, keep you posted on the fix and, with your consent, credit you in our acknowledgments.

What's next#