Vidmoat for Enterprise

Video your organisation
can account for.

Vidmoat turns a prompt into a finished video. Inside an organisation the interesting questions are different ones: who made this, on whose brand, through which credential, and can you prove any of it six months from now. This site answers those — and states plainly where the answer is “not yet”.

Talk to us ↗Read the security page

Four capabilities below. Every one is in production today and linked to the place you can go and use it.

Signed on the way out
VM1-clx3f9q2b0001-1755216000-9a41c0d7f2b6e83c
job  ·  signed-at  ·  HMAC-SHA256

That string is in the container metadata of every video Vidmoat renders for you. Anyone — a client, a broadcaster, a court, your own comms team — can paste it into the public checker and get back a yes or a no, plus the time it was signed. No Vidmoat account required.

Check a tag at vidmoat.com/verify
What is shipped

Four things you can use this afternoon

ProvenanceLive

Every export is signed, and anyone can check it

Each render leaves Vidmoat with a tag written into the file's container metadata — VM1-<job>-<timestamp>-<signature>, signed with HMAC-SHA256. Paste the tag, or drop the file itself, into the public checker and it answers whether this is a genuine Vidmoat export and when it was made.

  • The tag carries no user information at all — the job → project → account trace stays server-side and is visible only to Vidmoat staff.
  • Checking is public and needs no account: paste a tag or upload the file.
  • Verification reads the file header only, so it is cheap even on a 4K master.
Try the verifier
TeamsLive

Organisations, four roles, and invites that cannot be forwarded

A team is a real object with real membership. Owner, admin, member and viewer are ordered, and every permission is re-checked on the server on every request — the role gates in the UI decide what you are shown, never what you are allowed.

  • Invites are addressed to a person: accepting requires the signed-in account to hold the invited email, so a leaked link is useless to anyone else.
  • An invite can grant admin at most. Ownership is a transfer, never something a link hands out.
  • The org always has at least one owner — checked immediately before every demotion, removal and deletion.
  • Assets can belong to the team rather than the uploader, sharing who can see and use a file without moving the storage bill.
Teams in the dashboard
Brand controlLive

A brand kit the AI is bound by, not merely aware of

Colours, heading and body fonts, logo files, the caption and title treatment, a default grade, and your rules in your own words. It is compiled into the system prompt of every agent run — the editor chat, the MCP tools, the API agent, the chat bots — from one definition.

  • Mark a kit enforced and the wording the model receives changes from "apply this by default" to "this is a constraint; if a request cannot be satisfied on brand, say so".
  • Logo fields accept your own uploaded files only — a brand kit cannot be pointed at a third-party URL that the renderer would then go and fetch.
  • Seed a kit from a project you already approved instead of filling in a form.
Brand kit
AutomationLive

The same engine as a REST API, an MCP server and a plugin host

The editor is a command reducer, and the API is that reducer over HTTP: create a project, apply edit commands, render, read the result. The MCP server exposes the same engine to Claude, Cursor and anything else that speaks MCP, so an agent your team already uses can produce finished video.

  • API keys are scoped — sixteen coarse permissions like projects.write, render.write and ai.agent — so a leaked key is not account compromise.
  • A scope is necessary but never sufficient: plan entitlements and credit checks still run behind it, so a scope cannot be used to buy a feature the plan does not include.
  • OAuth apps with a consent screen, for products that act on your customers’ behalf rather than your own.
  • Third-party plugins are proxied through the platform rather than given your credentials.
Developer platform
The fine print, up front

What the signature does not prove

Provenance is the most sellable thing on this page, which is exactly why its limits belong next to it rather than in a footnote somebody finds after signing.

The tag signs the job, not the pixels. It proves this file was produced by a specific Vidmoat render at a specific time. It is not a content hash, so it cannot by itself tell you that the frames inside were never touched afterwards.
Container metadata does not survive a re-encode. The tag rides through downloads, re-shares and ordinary file transfers. Upload the file to TikTok or YouTube and their ingestion pipeline re-encodes it, which strips the tag along with everything else in the container. Verify the master you hold, not the copy the platform served back to you.
The pixel-domain layer is not on.Surviving a re-encode needs a watermark in the image itself. That code exists and is disabled by default, because the first version left a faint stationary artefact on flat areas of finished video — shipping a visible blemish on somebody’s work is worse than not fingerprinting it. In development

Verification lives at www.vidmoat.com/verifyand answers only “genuine Vidmoat export, signed at this time”. The trace from a tag back to a project and an account is deliberately not public.

What we do not have

The list your security reviewer is about to ask for

Publishing this costs us some deals and saves everyone the two weeks it takes to discover the same facts through a questionnaire. If any of these are hard requirements, we would rather you know now.

SOC 2 / ISO 27001Not yet

No audit has been performed and no report exists. We will not send you a "SOC 2 in progress" letter, because there is no engagement to be in progress.

Third-party penetration testNot yet

None commissioned to date. The controls we do have are described, and checkable, on the security page.

SSO / SAML / SCIMNot yet

Sign-in today is email or Google, per user. There is no identity-provider integration and no automated deprovisioning.

High availabilityNot yet

Vidmoat runs as a single application server. Deploys are atomic and the process is crash-guarded, but there is no multi-region failover and no contractual uptime target.

Invisible forensic watermarkingOn request

A keyed pixel-domain watermark that survives a platform re-encode exists in the codebase but is disabled by default, because the first version left a visible artefact on finished video. Treat it as in development; talk to us if you need it.

Custom contracts, DPA, invoicingOn request

Not self-serve. Ask and a human will work through it with you — including what we can and cannot commit to in writing.

The controls we do have — scoped credentials, server-side authorisation, rate limiting, transport security, data deletion — are set out one by one on the security page, each with what it actually covers.

Next step

Tell us what you need it to do

A short form, a real reply. If Vidmoat is the wrong tool for what you are describing, we will say so rather than book a call to find out slowly.