Purpose & scope
This document describes the security and access controls for the Vidmob MCP — the interface through which a partner's agents and applications connect to Vidmob's creative intelligence (creative scoring, AI-detected creative attributes, asset metadata, and in-flight performance). It is written to support an AI-tooling / vendor security review.
The integration is read-and-submit: partners submit creative for analysis and read back scores, attributes, metadata, and performance. It is not a general-purpose data export and exposes no administrative capability to external integrations. Every interaction is bound to a single Vidmob organization.
Maturity note. Several controls below are live today; a few are rolling out or are planned hardening items. Each control is tagged accordingly, and the Controls summary table at the end gives the at-a-glance status. We've flagged status honestly so your review reflects the actual posture, not an aspirational one.
1. Authentication & identity
OAuth with SSO support (live in production). Interactive access uses standards-based OAuth designed for hosted agent platforms:
User authentication. Both password and SSO users authenticate through Vidmob's own login — password or SSO, including 2FA — which then issues the OAuth tokens. Identity and SSO policy are governed by the Vidmob login.
Client identity (Dynamic Client Registration). MCP hosts (e.g. Claude.ai, MCP Inspector) self-register against the authorization server via Dynamic Client Registration (DCR, RFC 7591) after the standard 401 → discovery handshake. A Client ID Metadata Document (CIMD) model is deferred to a later phase.
Standards used. Authorization Code flow with PKCE and audience-bound tokens. Discovery: the authorization server hosts
/.well-known/oauth-authorization-server, and the MCP server exposes/.well-known/oauth-protected-resourceplus aWWW-Authenticate: Bearerchallenge on a 401. Some hosts (e.g. Claude.ai, ChatGPT) consume this discovery metadata automatically; others (e.g. Gemini Enterprise) have an administrator enter the endpoints manually.Organization binding (chosen at authorization). The user signs in and selects the organization for the session: if they belong to one organization it is used automatically; if several, they choose from an organization picker. The chosen organization is stamped into the issued access token as an
organization_idclaim (re-stamped on refresh). Tools never accept an organization ID as a parameter, so a request cannot be redirected at another tenant.
API-key (Bearer) access (implemented). For automated, non-interactive integrations that cannot complete an interactive sign-in (server-to-server pipelines, custom-built agents), API-key access is available. Keys are issued per organization and carry scopes that map to capability domains.
In both models, the credential resolves to exactly one organization, and that organization binding governs every downstream call.
2. Authorization & access control
Scope-based access (implemented). Access is granted per capability domain. The domains relevant to external partners are:
Domain | Access | Covers |
organization | read | Workspace and ad-account reference data |
scoring | read / read-write | Submit media, reserve uploads, retrieve scores, attributes, asset details, guidelines |
analytics | read | Media performance, KPI discovery |
Administrative capabilities are gated behind an internal-only admin scope that is never granted to external partner credentials.
Scope-gated tool visibility (implemented). A connection only sees the tools its scopes permit — unauthorized tools are filtered out of capability discovery entirely. This prevents information leakage about platform capabilities a partner isn't entitled to.
No organization ID as input. Tools never accept an organization identifier as a parameter. The organization is derived from the authenticated credential, so a request cannot be redirected to another tenant by manipulating inputs.
3. Organization isolation (tenancy)
This is the control most relevant to a multi-tenant data review.
Every request is bound to one organization via the authenticated credential, and that binding is enforced at the backend service layer (the same enforcement the existing platform relies on), not only at the MCP layer.
Cross-organization access is denied. A request for a resource belonging to another organization returns an authorization error (HTTP 403) rather than any data. (Verified: a media identifier belonging to a different organization returns a clean 403.)
No token passthrough. The MCP server validates the issued access token against the authorization server's published keys (JWKS), resolves it to the Vidmob organization, and uses Vidmob-internal credentials keyed to that organization for downstream calls. A partner's OAuth token is never forwarded to backend services, so the trust boundary is enforced server-side.
One organization per authorized session. The organization is selected by the user at authorization — used automatically when they belong to one, chosen from an organization picker when they belong to several — and carried as an
organization_idclaim on the issued token (re-stamped on refresh). An agent operates within exactly one organization for the life of that authorization, and tools never take an organization ID as input, so there is no way to mix data across organizations. This matters most for any write/submit operation, where context from one organization must not influence an action in another.
4. Input validation & injection defense
Schema validation on every input (implemented). Every tool input is validated against a strict schema before execution; invalid inputs are rejected with structured errors.
Strict typing & constrained inputs. Parameters are typed and length-bounded (enums, typed IDs, URLs, bounded arrays), and string inputs are sanitized.
Structured, not free-text. Tools accept structured parameters rather than free-text prompts, and all backend calls are parameterized — there is no string interpolation into queries.
Output encoding & response bounds. Results are JSON-serialized; oversized responses are bounded (with pagination or download-link patterns), and each tool execution carries a timeout, limiting resource-exhaustion exposure.
5. Rate limiting, concurrency & abuse prevention
Rate limiting (rolling out). Per-organization and per-tool-class limits are designed to protect against runaway automated request loops, with rate-limit status surfaced to well-behaved clients and structured back-pressure on limit. (Being rolled out alongside the broader analytics tooling.)
Concurrency limits (planned). Caps on concurrent executions per organization to prevent resource exhaustion from parallel calls.
Anomaly detection (planned). Monitoring for misuse patterns (e.g. abnormal call volume or rapid tool-switching) with alerting.
Credential revocation (implemented, with hardening planned). Credentials can be revoked through the organization service; immediate-revocation hardening (a fast blocklist) is planned as an enhancement.
6. Auditability & logging
Request logging (rolling out). Tool calls are logged with timestamp, tool name, organization, input parameters (with sensitive fields redacted), result status, and execution duration — to support forensic analysis and compliance reporting. A consolidated audit trail and operational monitoring dashboard are being rolled out alongside the analytics tooling.
Sensitive-field redaction reuses the platform's existing redaction handling.
7. Data handling
Scope of data. The integration returns creative metadata, AI-detected creative attributes, guideline scores, and in-flight performance metrics for the partner's own organization. It does not expose other organizations' data, user PII beyond what's needed for the authenticated session, or administrative data.
Read-oriented analytics. Performance queries run against a reporting dataset in a read-only fashion.
Signed download URLs are short-lived. Asset metadata can include a pre-signed download URL; these are time-limited and should be treated as ephemeral.
Organization-scoped throughout. All returned data is constrained to the caller's organization per Section 3.
8. Transport security
TLS in transit (implemented). All traffic is encrypted in transit; TLS terminates at the load balancer.
HSTS (planned). Strict-Transport-Security header enforcement is a planned addition.
Transports. Streamable HTTP (recommended) and SSE.
9. Controls summary
Control | Status | Notes |
API-key authentication (per-org, scoped) | Implemented | For headless/programmatic integrations |
OAuth + SSO (user auth, PKCE, audience-bound) | Implemented | Live in production |
Dynamic client registration (DCR) | Implemented | Live; hosts self-register; client-governance controls planned |
Scope-based tool visibility | Implemented | Unauthorized tools hidden from discovery |
Organization isolation (request bound to one org, backend-enforced) | Implemented | Cross-org returns 403 (verified) |
No token passthrough (internal creds keyed to resolved org) | Implemented | OAuth path |
Authorization-time organization binding (org picker → organization_id token claim) | Implemented | User selects org at sign-in; one org per authorization |
Input schema validation & sanitization | Implemented | Rejects invalid input pre-execution |
Parameterized backend calls / no free-text queries | Implemented | By design |
Response size bounds & per-tool timeouts | Implemented | Resource-exhaustion control |
Credential revocation | Implemented | Fast-revocation blocklist planned |
TLS in transit | Implemented | — |
This overview is provided for security review. For specific control evidence or configuration detail, contact support@vidmob.com.