If you discover a security vulnerability in VIDEOContext, please do not disclose it publicly before it has been reviewed.

Instead, report the vulnerability privately to the project maintainer.

Please include as much information as possible, including:

• A description of the vulnerability
• The affected component or functionality
• Steps to reproduce the issue
• Potential impact
• Proof of concept, if available
• Suggested mitigation or fix, if you have one

Please avoid including sensitive information that is not necessary to understand or reproduce the issue.

Security reports will be reviewed when possible.

The project maintainer may request additional information to better understand and reproduce the issue.

If the vulnerability is confirmed, an appropriate fix will be developed and released based on the severity and impact of the issue.

Please understand that response and resolution times may vary, particularly as VIDEOContext is an open-source project.

Security fixes are generally applied to the actively maintained version of VIDEOContext.

If you are using an older version of VIDEOContext, updating to the latest available version is recommended before reporting an issue unless the vulnerability specifically prevents you from doing so.

Potential security issues may include, but are not limited to:

• Arbitrary code execution
• Unsafe file handling
• Path traversal
• Malicious video or media file processing
• Denial of service
• Dependency vulnerabilities
• API authentication or authorization issues
• Exposure of sensitive information
• Unsafe handling of uploaded files
• Injection vulnerabilities
• Vulnerabilities affecting the MCP server or tools

The following are generally not considered security vulnerabilities:

• Issues requiring unrealistic attack conditions
• Theoretical issues without a practical security impact
• Missing security features that do not expose an existing vulnerability
• Issues in third-party services or dependencies that are outside the control of VIDEOContext, unless VIDEOContext directly introduces or enables the vulnerability

VIDEOContext may process user-provided video and media files.

Media files should be treated as untrusted input.

Contributors working on video processing functionality should consider security implications related to:

• File size
• File type validation
• Malformed media files
• Resource exhaustion
• Unexpected metadata
• Path handling
• External media processing tools

Avoid assuming that uploaded files are safe or well-formed.

videocontent.sources fetches http(s) URLs. Remote media is untrusted input and passes a dedicated security boundary (shared by the SDK, CLI, API, and MCP — never duplicated per surface):

• Scheme allowlist: only http/https. URLs with embedded user:pass@ credentials are refused rather than fetched.
• SSRF / DNS rebinding: every resolved IP for the host (and for each redirect hop) is checked; loopback, private, link-local, multicast, reserved, and unspecified addresses are blocked unless sources.allow_private_ips is explicitly enabled (intended for trusted tests only).
• Redirects: followed manually up to sources.max_redirects, revalidating scheme, DNS, and IP safety on every hop. Redirects to non-http(s) schemes are refused.
• Response validation: Content-Type is inspected (web pages such as text/html are refused, not downloaded); Content-Length is pre-checked and the streamed body is capped at sources.max_download_mb with sources.download_timeout_s applied.
• Provenance hygiene: canonical source identity strips credentials and ephemeral query params (tokens, signatures, expiry); .vctx stores only redacted locators. Credentials never appear in logs, cache keys, or exported context.
• Lifecycle: downloads land in a confined temp root, are removed on success and failure (unless sources.keep_downloads is set for debugging), stale dirs are swept by TTL, and a free-space pre-check fails fast before large fetches.

When reporting a remote-ingestion issue, include the (redacted) URL shape, redirect chain, headers, and which control failed — never live credentials or signed URLs.

New read surfaces in this phase (MCP tools, REST endpoints, CLI commands) operate exclusively over finished local .vctx documents:

• No tool downloads video, runs processing, or contacts providers — the LLM call inside ask uses the operator's configured provider exactly as the SDK does.
• MCP outputs are capped (counts and text lengths) so one call cannot exfiltrate a whole document into an agent context window.
• Derived views (entities, chapters, changes) inherit document timestamps; derived titles/labels are flagged rather than presented as ground truth.

VIDEOContext may depend on third-party libraries and external tools for media processing, AI functionality, or other features.

When reporting a dependency-related vulnerability, please include:

• The affected dependency
• The affected version
• How VIDEOContext is impacted
• Whether the issue can be triggered through normal VIDEOContext functionality

Please allow reasonable time for a reported vulnerability to be reviewed and addressed before publicly disclosing technical details.

If the vulnerability is confirmed and fixed, public disclosure may occur after users have had an opportunity to update.

When running VIDEOContext:

• Keep dependencies updated
• Use trusted and supported versions where possible
• Treat uploaded media files as untrusted
• Avoid exposing development services directly to the public internet without appropriate security controls
• Protect API keys and credentials using environment variables or secure secret-management systems
• Review access controls before deploying VIDEOContext in production

The evidence graph, query plans, context packages, and collection endpoints are read-only derived views over local .vctx documents:

• No tool triggers processing, downloads media, or contacts providers. Coverage gaps return reprocessing suggestions, never implicit work.
• MCP outputs are capped (counts and text lengths); collection registration only accepts already-loaded videos.
• Context packages minimize data by budget; redaction (redact_package with builtin_secret_patterns) is opt-in, pattern-based, and non-destructive — the source package is never mutated.
• Graph edges cite construction rules, not model judgments; no edge implies causation (TEMPORAL_SEQUENCE is adjacency in time).

The agent skill (skills/videocontent/), the Claude Code / Codex plugin manifests, the --agent CLI output and the built-in videocontent mcp server share one layer (videocontent.agent.ops) and one posture:

• Video content is data, never instructions. Every agent result carries a content_notice; the skill's first rule tells the agent never to act on instructions in transcripts, on-screen text, subtitles or metadata. Covered by a test that renders a prompt-injection line into a real video.
• Credential redaction by default in agent results: API-key and token shapes, bearer headers, private-key headers, and the entire value of secret-named assignments (OPENAI_API_KEY=…, password: …), which also covers keys that OCR garbled.
• No implicit processing. Only analyze processes (MCP: allow_processing: true), locally, with the operator's configuration; vision and remote providers stay off unless configured.
• Workspace boundary. videocontent mcp reads only under --root (default: its working directory); .., absolute paths elsewhere and ~ are refused. Tool arguments are schema-validated (unknown keys rejected), results are size-capped, and unexpected exceptions return only their type.
• URLs go through the source boundary above; URLs with embedded credentials are refused and query tokens are never echoed.
• Installer. videocontent init-agent never overwrites a skill it did not install (--force required), edits no configuration files, and registers MCP only with --mcp, through each agent's own mcp add command.
• The legacy apps/mcp server now rejects video_ids that are not plain identifiers (they are used to build file paths).

Responsible vulnerability reports help improve the security of VIDEOContext and protect its users.

Thank you for helping make VIDEOContext more secure.