SwiftyClip Security Whitepaper

1. Executive Summary

SwiftyClip is a professional-grade video workstation built exclusively for macOS, leveraging Apple Silicon to provide high-performance video analysis, hook detection, and automated clipping. In an era where most video editing tools have migrated to cloud-based SaaS models—requiring massive data uploads and introducing significant third-party risk—SwiftyClip pivots back to a local-first, privacy-centric architecture. This whitepaper serves as a comprehensive technical reference for enterprise security teams, legal counsel, and procurement officers evaluating the risk profile of SwiftyClip within a corporate environment.

Our core mission is to provide creators and enterprise teams with the tools they need to scale their content output without compromising the security of their raw assets. We operate under a strict "local-only" default, ensuring that the most sensitive parts of the creative workflow—the raw footage, the audio transcripts, and the AI-generated analysis—never leave the user's hardware. This design philosophy eliminates the "data gravity" problem, where large media files become difficult to secure once moved into third-party cloud environments.

By utilizing on-device machine learning and native system frameworks, SwiftyClip provides the intelligence of modern AI with the security of an offline tool. We operate on three foundational security guarantees:

• Zero Content Uploads: Your raw media assets and derived transcripts are never transmitted to our servers or stored in any cloud environment by default.
• Hardened On-Device Processing: All machine learning operations, from speech-to-text to visual scene analysis, are executed locally using native macOS frameworks and Apple Silicon's Neural Engine.
• Minimal Surface Area: The application is strictly confined by the macOS App Sandbox, requesting only the specific entitlements required for local file operations and secure licensing.

2. On-Device Data Flow

The lifecycle of data within SwiftyClip is designed to minimize exposure and maximize performance. When a user imports a video file, the application utilizes AVFoundationto establish a scoped access link via the macOS Security-Scoped Bookmark system. SwiftyClip does not create secondary copies of your original files; instead, it processes them in-place, reading frames and audio buffers directly into memory for transient analysis.

The analysis pipeline follows a strictly linear and local path, utilizing a "pull-based" architecture where data is only read as needed by the various analysis modules:

1. Ingestion & Demuxing: The video file is accessed via AVAsset. Audio tracks are demuxed in real-time, and video frames are decoded using hardware acceleration (VideoToolbox).
2. Transcription: Audio tracks are routed to WhisperKit or the system SpeechAnalyzer for local transcription. This involves converting audio to 16kHz mono PCM buffers, which are then processed by the Neural Engine.
3. Visual Analysis: Frames are sampled at specific intervals and passed toVision (for face and object tracking) and MLX models (for composition and hook identification).
4. Metadata Persistence: Transcription and timing data are saved to a localSwiftData store. This database is located within the app's private Application Support directory, which is encrypted by FileVault at the OS level.

At no point in this pipeline is a network request initiated for the purpose of offloading computation. Intermediate data structures are kept in memory as much as possible, and any temporary files generated during the clipping process—such as proxy files or cache buffers—are stored within the app's sandbox container. These temporary files are subject to automatic cleanup routines and are never indexed by system-wide search or shared with other applications. This ensures that your creative IP remains entirely under your control, mitigating the risk of data breaches common in centralized cloud editors.

3. Network Connections

While SwiftyClip is a local-first application, certain business functions require outbound connectivity. We maintain an exhaustive "deny-by-default" policy, only permitting connections to verified endpoints for specific, user-disclosed purposes. This is enforced both at the application level and via the macOS App Sandbox.

The application maintains exactly three categories of outbound connections:

• Authentication & Database: We use Supabase for user account management. This connection handles login, logout, and the synchronization of high-level metadata (such as project names, workspace settings, or subscription status). This communication is conducted over TLS 1.3 with pinned certificates where possible. No video content or transcripts are ever stored in Supabase.
• Billing & Licensing: Payments and subscription verification are facilitated via Stripe. This communication is handled through Stripe's official SDKs, ensuring that SwiftyClip never sees or stores sensitive credit card data. License verification is performed using cryptographically signed tokens.
• Transactional Communication: System-generated emails, such as password resets, receipt delivery, or critical security alerts, are sent via Resend.

We reiterate that there are ZERO uploads of video, audio, or transcript content for the purpose of processing or storage. For users who opt into our multi-platform scheduling feature, a specific rendered clip is uploaded to our secure bridge at the moment of publication. These payloads are encrypted using AES-256 in transit and at rest. To further minimize risk, these payloads are automatically purged from our systems within 24 hours of the scheduled post time, regardless of delivery status.

4. Model Provenance

Transparency in machine learning is a core component of our security posture. SwiftyClip utilizes industry-standard, open-source models that have been optimized for the macOS ecosystem. This allows for rigorous auditing of the "intelligence" layer of the application and ensures that our AI behavior is predictable and safe.

Our current model stack includes:

• WhisperKit: An implementation of OpenAI’s Whisper models, optimized by Argmax for Core ML. These models are utilized for high-accuracy, multi-lingual transcription. (Licensed under CC BY 4.0).
• MLX: Apple’s open-source machine learning framework, designed for high-performance model execution on Apple Silicon. We use MLX for local Large Language Model (LLM) operations, including caption reformatting, viral hook scoring, and content summarization. (Licensed under Apache 2.0).
• Vision & Speech: Standard Apple system frameworks for scene re-framing, face tracking, and legacy speech recognition. These are proprietary but benefit from the security hardening of the macOS operating system.

To ensure model integrity and protect against supply-chain attacks, all model weights are downloaded directly from official, authenticated sources (such as the Apple CDN or Hugging Face repositories). During the application's first launch, SwiftyClip performs a mandatory integrity check, verifying each model file against a hardcoded SHA-256 checksum. If a checksum mismatch is detected—indicating possible tampering or file corruption—the application will refuse to load the model and alert the user. This ensures that the AI logic running on your machine is exactly what was intended by the SwiftyClip engineering team.

5. Sandbox Entitlements

SwiftyClip is a fully sandboxed macOS application, adhering to the strict security guidelines required for Mac App Store distribution. This means that the app operates in an isolated environment, with no access to your files, camera, or network unless specifically granted by the user via system-level permission prompts.

Our SwiftyClip.entitlements file contains the following permissions:

• com.apple.security.app-sandbox: Enables the core security container, restricting the app's access to the filesystem and system resources.
• com.apple.security.files.user-selected.read-write: Grants access only to the specific videos you choose to import and the folders where you save exports, mediated by the macOS Powerbox.
• com.apple.security.network.client: Required for licensing checks, update notifications, and the optional scheduling feature.
• com.apple.security.device.audio-input & camera: Required only for the "Live Capture" feature. These permissions are inactive unless the user starts a live recording session.
• com.apple.security.files.bookmarks.app-scope: Allows the app to maintain persistent access to your project files across restarts, ensuring a seamless workflow without repeated permission requests.

Furthermore, SwiftyClip is compiled with the Hardened Runtime enabled. This provides additional layers of protection against common exploits, such as code injection, dynamic library hijacking, and memory tampering. It also enforces signed code requirements for all loaded libraries. These combined measures ensure the binary remains tamper-proof throughout its execution lifecycle, providing a secure foundation for sensitive creative work.

6. Secrets Management

Security is baked into our development and build pipelines. SwiftyClip employs a multi-layered approach to secrets management to ensure that no sensitive credentials, API keys, or internal configuration details are ever exposed in the source code or the final binary.

We utilize an .xcconfig based pattern where all API keys and environment variables are stored in a Secrets.xcconfig file. This file is explicitly excluded from version control. During Continuous Integration (CI) and local builds, secrets are fetched at build-time from a secure 1Password vault or GitHub Actions' encrypted secret store. We use build-time preprocessing to ensure that these keys are only accessible to the relevant components.

The application binary itself does not contain hardcoded, high-privilege secrets. Most external service interactions are mediated through our backend, which uses short-lived, scoped tokens. This architecture allows us to rotate credentials instantly without requiring users to update the application. This approach minimizes the impact of a potential client-side compromise, as any exposed tokens have a limited scope and a short TTL (Time To Live).

7. Compliance Posture

SwiftyClip’s "on-device by default" architecture simplifies compliance with global data protection regulations. Because we do not store, scan, or analyze user media on our servers, we significantly reduce the privacy risk and the compliance burden for our enterprise partners.

GDPR & CCPA: We are fully operational under GDPR and CCPA guidelines. We act as a Data Controller for account-level metadata (email, billing info) and a Data Processor for the optional scheduling service. Because processing happens locally, the user maintains "Right to Access" and "Right to Erasure" over their media assets simply by managing their local files. For account data, users can request a full export or deletion directly from the application settings.

SOC 2 & Enterprise Compliance: While SwiftyClip does not currently claim SOC 2, HIPAA, or FedRAMP certification, we have begun the formal readiness phase for a SOC 2 Type II audit. This involves implementing rigorous internal controls over our development lifecycle, vendor management, and incident response procedures. We anticipate completing this audit in Q4 2026. In the interim, we provide detailed architectural reviews, security questionnaires, and can sign Data Processing Agreements (DPAs) for enterprise customers.

8. Incident Response

We take a proactive stance toward security incidents. Our team maintains a 24/7 internal monitoring posture for our infrastructure and a formalized incident response runbook designed to contain and neutralize threats within hours of discovery.

Our response process consists of four defined phases:

1. Verification & Triage: All reports are acknowledged within 2 hours. Our security engineers attempt to reproduce the issue in a staging environment and determine the potential impact on user data.
2. Containment & Mitigation: If a vulnerability is confirmed, we implement server-side blocks or use feature flags to disable the affected component immediately. This stops the "bleeding" while a permanent fix is developed.
3. Remediation & Patching: We develop and test a hotfix, which is then deployed via our Sparkle-based auto-update system or the Mac App Store. We prioritize security patches over all other development tasks.
4. Disclosure & Post-Mortem: We publish a transparent technical report for all significant incidents, detailing the root cause, the scope of the impact, and the long-term steps taken to prevent a recurrence.

9. Responsible Disclosure

We believe in the power of the security community and welcome reports from independent researchers. We are committed to working with the community to resolve security issues quickly and transparently. If you believe you have found a security vulnerability in SwiftyClip, please contact us immediately at hello@swiftyclip.com.

To facilitate secure communication and protect sensitive findings in transit, you may use our PGP key:
Key ID: [PLACEHOLDER_KEY_ID]
Fingerprint: [PLACEHOLDER_FINGERPRINT]

We commit to acknowledging your report within 72 hours and providing a primary fix or mitigation for critical issues within 30 days. We ask that you practice responsible disclosure and refrain from sharing the details of the vulnerability until a fix has been verified and deployed to the public. In return, we provide public attribution (if desired) and a prioritized response for all valid security reports.

10. Vendor List

To provide our service, we partner with a limited number of high-trust infrastructure providers. We vet each vendor for their security standards and data handling practices. For more details, please see our main Security and Privacy pages.