Security and Data Processing

How CutKit handles sensitive project data.

Overview

CutKit stores and processes post-production coordination data: scripts, Source / Logging rows, Edit state, Tasks, montage cards, members, contacts, and related project materials.

Scripts and production documents can be high-value project materials. CutKit treats this data as sensitive operational content and keeps routine project workflow processing on the CutKit server.

External API processing is used only when a specific enabled function needs it. In those cases, the request is scoped to the context needed for that operation, such as selected fragments, pages, identifiers, or compact project metadata.

Data categories

Account and authentication data¹. Email, password hash, session and authentication state, confirmation and password-reset flow metadata.
Project metadata². Project title, type, settings, numbering profile, production dates, and workflow configuration.
Members and contacts³. Project users, roles, contact cards, responsibilities, access relationships, and external performer records.
Scripts⁴. Uploaded scripts, parsed scenes, scene codes, anchors, source quotes, extracted text, and scene links.
Source / Logging⁵. Shooting days, received dates, volume, materials, scene and material notes, comments, issues, and custom fields.
Edit⁶. Scene status, progress, edit metadata, script links, source links, and review state.
Tasks⁷. Tasks, comments, workflow state, assignment data, stop-frame images, package links, and share links.
Montage cards⁸. Uploaded XLSX, PDF, and image files; extracted candidates; review decisions; OCR text, evidence, and previews when OCR is enabled.
System and operations⁹. Backups, checksums, diagnostic status, redacted security configuration reports, logs, and usage accounting.

What happens to uploaded scripts

A script is uploaded into a project and processed to extract the structure needed for coordination: scene structure, scene codes, anchors, quotes or fragments, and links used by the project workflow.

Parsed script data is used inside the project workflow: Script Review, Edit, Scene AI when enabled, and related hints in other project functions.

Where configured and covered by the implemented script encryption fields, long script-derived text can be stored through encrypted protected fields¹⁰. Script metadata and stored script-derived text are treated as sensitive in permissions, backups, and operational handling.

Normal script upload is local-first¹¹. If an AI-assisted feature is enabled and triggered, CutKit may send selected script fragments and the project context needed for that request to an external LLM API¹².

LLM / AI processing

CutKit can use LLM or API processing for specific AI-assisted functions, such as analyzing ambiguous scene structure. Calls are gated by feature flags, project actions, user eligibility, and usage limits.

A request is intended to contain only the context needed for the function: selected scene text, script fragments, Source / Edit / Tasks metadata, candidate identifiers, and compact project context. External API processing is not the default path for ordinary project navigation or local parsing.

Usage accounting¹³ stores technical metadata about calls, such as provider, model, status, token counts, estimated cost, latency, request kind, and schema identifier.

OCR and montage cards

Structured XLSX montage-card files are parsed locally on the CutKit server.

PDF or image montage cards can be processed by an OCR provider¹⁴ only when OCR is enabled. In that case, the pages or images needed for recognition may be transferred to an external OCR provider.

The review UI shows bounded evidence and preview context. Initial Source HTML contains bounded review data rather than raw OCR text, raw OCR JSON, or full workbook dumps.

Recognized scene candidates are review evidence first. Applying recognized matches to Source is a separate explicit action and contract.

External processors¹⁵

VPS / hosting. Application runtime, database, uploaded files, and backups.
Email provider. Email confirmation, password reset, and service emails.
Google Cloud KMS¹⁶. Encryption and key operations when configured and enabled.
LLM provider / OpenAI. Selected context for AI-assisted functions when enabled and triggered.
Google Vision / OCR provider. Pages or images needed for montage-card OCR when OCR is enabled.
User browser. UI rendering, session handling, cookies, and static assets.

Security controls

HTTPS / TLS¹⁷. Production traffic is served over HTTPS/TLS.
Sessions, cookies, and CSRF¹⁸. The app uses Django sessions, CSRF protection, and secure-cookie settings controlled by production configuration.
Server-side permissions¹⁹. Project access and section access are enforced on the server through project membership, roles, and explicit permission flags.
Account flows. Email confirmation and password reset use tokenized flows, and authentication forms have local cache rate limiting.
Tasks share links. Share links use token-only URLs²⁰, hashed token storage, scoped task access, revocation, and a default expiry for newly created links.
Script field-level encryption²¹. Implemented script long-text fields can use field-level encryption and KMS-wrapped project keys where configured.
Import guards. Project JSON imports validate size, file type, UTF-8 JSON parsing, and expected top-level shape before reading the full payload.
Stop-frame upload guards. Tasks stop-frame uploads validate size, content type, image format, and dimensions before server-side JPEG preview normalization.
Backups and restore checks. Backup tooling supports scheduled backups, checksums, restore-drill verification, and retention operations.
Security contact metadata. security.txt²² is published with vulnerability contact metadata.
Redacted diagnostics. The security configuration status command reports derived pass, fail, warning, and unknown states without printing secrets or raw production configuration values.

Cookies and browser storage

CutKit currently uses only service cookies needed to run the application: sessionid keeps the signed-in or demo session active, csrftoken protects forms and API requests from CSRF, and django_language stores the interface language.

These cookies are not advertising, analytics, or cross-site tracking cookies. If CutKit later adds optional analytics, marketing, or tracking, those cookies will be separated from required service cookies and controlled before they are set where required.

The production session cookie is configured as HttpOnly. The CSRF cookie deliberately remains readable by browser JavaScript because current AJAX requests use it for safe POST requests.

Why data is processed

Account operation. CutKit processes account data for registration, email confirmation, sign-in, password reset, profile settings, notifications, and abuse prevention.
Project workflow. Project data is processed to provide collaboration, memberships, permissions, Source, Script Review, Edit, Tasks, comments, exports, shares, and related status views.
Document and evidence review. Scripts, montage cards, OCR evidence, scene links, and review decisions are processed to connect production material with the project structure.
Operations and security. Technical data is processed for backups, restore checks, diagnostics, rate limiting, security configuration checks, and usage accounting.
Email updates. If a user separately opts in, CutKit may send emails about product updates and important service news. This can be turned off in Account settings.
Optional AI/OCR functions. External AI or OCR processing is limited to enabled functions and the context needed for the specific user or project action.

Retention and deletion

Project and account data is generally retained while the relevant account, project, membership, share link, upload, task, or operational record is active.

Deleting a document, montage card, passive report, or share link removes the active working record and associated files through the server-side storage flow. Previous copies can remain in backups until the relevant backup retention period expires.

One-time phone upload links for montage cards are short-lived and scoped to a specific shooting day. Task share links have a token, access scope, revocation, and an expiry for newly created links.

Feedback and support messages are retained only for reply, diagnostics, security follow-up, and support history. They can be deleted or anonymized through support handling where this does not conflict with security, legal, or operational obligations.

Backups are retained according to operational backup and restore requirements. CutKit does not state one universal retention window for every data type in this public document.

Account deletion may anonymize the account while preserving project history, task history, comments, events, or references needed for project integrity and collaboration.

User choices and access control

Project admins manage membership and project access through CutKit roles and permissions.
Authorized project members manage exports, shares, uploads, and project content according to the project workflow and their permissions.
Project admins and authorized members can delete uploads, revoke share links, change project access, and request support for account or data questions.
Users should not use optional AI/OCR functions for material they are not allowed to process through external providers.
Eligible users can request account deletion or anonymization through the Account page, subject to server-side eligibility rules for active project obligations.

Incidents and vulnerability reports

Vulnerability reports are accepted through the contact published in security.txt. A report should describe the affected function, expected risk, and reproduction steps without publishing another project's data.

When a suspected incident is found, CutKit first limits the issue, preserves the technical evidence needed for investigation, revokes or rotates tokens and keys where required, assesses affected data and users, and then communicates or notifies where required by applicable rules, contracts, or service obligations.

Service contact context

If no separate legal entity is identified in the service or a contract, CutKit in this public document means the service and its operator.

For vulnerability or security reports, use the public security.txt metadata and this Security and Data Processing page.

Terms and explanations

1 Account and authentication data: information CutKit uses to identify the account holder, authenticate sign-in, keep a browser session active, confirm email ownership, and run password-reset flows. This includes operational authentication metadata, not project creative material.
2 Project metadata: project-level settings and descriptors used to organize work, such as project type, numbering rules, dates, permissions, and workflow configuration. Metadata helps structure the project but does not by itself contain the full script, task discussion, or uploaded production files.
3 Members and contacts: records for people connected to a project. Some records correspond to users with CutKit account access; others are project contacts or external performers used for assignment and coordination without granting account access.
4 Scripts: uploaded screenplays and the structured data derived from them, including scene codes, anchors, source quotes, extracted text, and scene links. Scripts can contain valuable creative and production information, so CutKit treats script data as sensitive project material and uses it to connect Source, Edit, Tasks, and review workflows to the same project structure.
5 Source / Logging: the production-material intake log for shooting days and received material. It records what arrived, dates, volume, scene and material notes, issues, comments, and readiness signals used by downstream Edit and Tasks workflows.
6 Edit: the project area that tracks scene editing state and review progress. It may reference script context, Source material, scene status, edit metadata, and links that help coordinators understand what is ready, in progress, or blocked.
7 Tasks: the project area for finishing and coordination work. It can include task descriptions, comments, assignees, workflow state, package references, stop-frame images, scoped share links, and related project context.
8 Montage cards: production paperwork attached to shooting days and reviewed as evidence before recognized scene matches are applied to Source. Files may be XLSX, PDF, or images; OCR-derived text and previews exist only where OCR processing is enabled.
9 System and operations data: technical records used to run, diagnose, back up, and verify the service. This includes checksums, diagnostic status, redacted security reports, logs, and usage accounting, and should not intentionally expose secrets or raw production configuration values.
10 Encrypted protected fields: database fields that store selected long script-derived text in encrypted form when the configured encryption path is available. This is field-level protection for implemented fields and is separate from ordinary database storage; surrounding metadata, permissions, backups, and operational controls still matter.
11 Local-first: the normal processing path runs on the CutKit server first. External API processing is not used as the default path for ordinary project navigation, table work, or local parsing; an external request is limited to a specific enabled feature that requires it and is triggered by a user or project action.
12 LLM API: an external large-language-model service used for specific AI-assisted functions. When used, CutKit scopes the request to the context needed for that function, such as selected script fragments, scene text, project metadata, or candidate identifiers, instead of treating the external API as general project storage.
13 Usage accounting: technical accounting records for API calls. These records support cost control, limits, troubleshooting, and auditability by storing metadata such as provider, model, status, token counts, estimated cost, latency, request kind, and schema identifier.
14 OCR provider: a service that recognizes text in images or PDF pages. In CutKit this applies to montage-card review only when OCR is enabled and the relevant upload path triggers OCR processing. Structured spreadsheet files are handled locally where possible; scanned or image-only pages may require external recognition.
15 External processor: an infrastructure or service provider that may receive limited project or technical data for an enabled function. Examples include hosting, email delivery, key management, OCR, and AI-assisted processing. CutKit uses these processors for defined service functions, not as an unrestricted destination for all project data.
16 Google Cloud KMS: a key-management service used for encryption and key operations where the CutKit encryption configuration enables it. It is used for key wrapping and related cryptographic operations, not as a general project-file storage location.
17 HTTPS / TLS: transport encryption used by browsers and servers to protect network traffic in transit. It helps protect data while it moves between the user browser and the service, but it is separate from storage encryption and application-level permissions.
18 CSRF: cross-site request forgery protection. It helps prevent another site from submitting unwanted authenticated requests from a user's browser to CutKit, especially for state-changing actions.
19 Server-side permissions: access checks performed by the backend before returning or changing project data. UI hiding is treated as presentation only; the server-side check is the security boundary.
20 Token-only URL: a URL where access depends on a high-entropy token rather than a visible username or password. CutKit stores share-link tokens as hashes and supports scoping, revocation, and default expiry for newly created links.
21 Field-level encryption: encryption applied to selected database fields rather than only to the storage device or database file as a whole. It is useful for specific sensitive fields, but the surrounding metadata, permissions, backups, and operational controls still matter.
22 security.txt: a standard public metadata file for vulnerability reporting. It lists the approved security contact and policy URL so researchers and customers can find the correct channel without relying on informal contact paths.