What we actually protect,
and what we don’t claim.

1.Scope

This page describes how the Vgent site and its generation routes handle security as of September 6, 2026. It covers the anonymous creation flow, how generation tasks are recorded and retrieved, and the credentials that make those calls possible.

It does not cover the platforms you publish finished videos to, the model provider’s own infrastructure beyond what its API exposes to us, or any account, billing or team capability — none of those exist in the product yet.

• In scope: the marketing site, the anonymous workbench, and the same-origin generation routes under /api/v1.
• Out of scope: third-party publishing platforms, provider-side infrastructure, and features that are not connected.
• Where a control is missing, it is written down in section 8 rather than left unsaid.

2.Infrastructure and deployment

Vgent is a Next.js App Router application. Anything that touches a credential runs inside a server-side route handler; the browser bundle carries page code and the generation client only, and never the provider adapter.

Server-side state is kept deliberately small. A generation record — the submitting session, the model, the resolution and the resulting task id — lives in a Redis-compatible REST store for 24 hours and then expires on its own. Rate counters use a rolling ten-minute window, and the shared daily budget counter is held for 48 hours so a day boundary cannot be played against us.

• Request bodies are rejected above 100,000 bytes, before parsing.
• Outbound provider calls time out after 30 seconds; state-store calls after 5 seconds.
• No prompt, reference image or finished video is stored in a database of ours.

3.Data handling and the model provider

Rendering happens at our model provider, aivideoapi.ai. Your prompt and generation settings are sent there over HTTPS, and the finished clip comes back as a provider-hosted link with a limited lifetime. Their handling of that data is governed by their own terms, which we cannot extend on their behalf.

We keep the round trip as narrow as we can. Prompt text is never written to a log line — only its length is. Because uploads are not connected, the only media a request can reference today is a clip or frame from one of your own completed tasks, proved by a signed token rather than by a URL you supply.

• Sent to the provider: prompt text, generation settings, and a resolved source reference when you extend or continue a clip.
• Not sent: your session cookie, your network address, or anything else that identifies you.
• Kept by us: task id, model, resolution and owning session — for 24 hours, then gone.

4.Keys and credential management

Three secrets make the product work: the provider API key, the signing secret for continuation tokens, and the credentials for the state store. All three are read from server environment variables at request time, and all three are absent from the client bundle by construction — the modules that read them are imported only by route handlers.

None of them appear in logs, error responses or analytics. A secret is rotated by replacing the environment value and redeploying; rotating the token signing secret immediately invalidates every continuation token already issued, which is the intended effect rather than a side effect.

• With no signing secret configured, no continuation token is issued at all — the feature switches off instead of falling back to something weaker.
• With no provider key configured, the generation routes answer 503 rather than failing halfway through a request.
• Network addresses are hashed with SHA-256 before they become a rate-limit key, so the raw address is never stored.

5.Access control and sessions

There are no accounts, so there is nothing to log into and no password to steal. Continuity comes from one cookie, vv_anon, holding a random identifier: HttpOnly, SameSite=Lax, marked Secure in production, expiring after a year. It is a continuity anchor, not an identity, and it carries no balance or entitlement.

Every generation is written down against the session that submitted it. When the browser polls a task, the server looks the record up and compares the owner; a mismatch is answered with “not found”. Repeat submissions are de-duplicated through an Idempotency-Key stored under a hash of the session and that key, so two visitors cannot collide, and a replayed key with different settings is refused instead of quietly creating a second render.

• Continuation tokens are HMAC-SHA256 signed, compared in constant time, length-limited, and expire 24 hours after the source task completed.
• A token also pins the model, resolution and owner, so one minted for another session or another model is rejected everywhere else.
• The language cookie, vgent-locale, stores a locale code and nothing else.

6.Vulnerability disclosure

Found something? Email security@vgent.com with the affected URL, the steps to reproduce, and what an attacker could achieve. A short proof of concept is worth far more to us than a scanner export.

We will not pursue legal action, and will not ask anyone else to, over good-faith research that follows the rules below. Please give us a reasonable window to ship a fix before you publish — we ask for 90 days, and will happily agree a shorter one for an issue already being exploited. We aim to acknowledge a report within five business days.

• Use your own session and your own test content; never access, alter or delete anything belonging to another visitor.
• No denial-of-service or load testing, no spam, phishing or social engineering against us, our visitors or our provider.
• Report what you found and stop there — please do not pivot deeper into the system to demonstrate impact.
• There is no bug bounty yet, so we cannot offer payment; we will credit you on this page if you would like that.

7.Incident response

Reports and alerts land in one place, security@vgent.com, and containment comes before analysis. Depending on what is affected, containment means rotating the provider key, rotating the token signing secret, dropping stored task records, or switching off the route in question — each is a single environment or deployment change, which is one of the dividends of holding so little state.

Because we hold no email addresses, we cannot notify you individually. A material incident is written up on this page with a dated note and linked from the changelog, so the disclosure is public rather than selective.

• Contain, confirm the scope, fix, then write up what happened and what changed.
• Every outstanding continuation token can be invalidated globally by rotating one secret.
• Notification is published here; there is no mailing list to fall back on.

8.Current limitations

The honest list. These are the gaps we know about, stated here rather than buried, and this section is revised as they close.

• Uploads are not connected. Object storage has not been provisioned, the upload route answers 503, and a generation request that references an uploaded file is refused — a file you pick in the browser never leaves your device.
• There is no account system, and therefore no password, no multi-factor authentication, no single sign-on and no per-user audit trail. Anything that needs a verified identity is not available yet.
• In production the anonymous limits require a Redis-compatible REST store. Without it, a submission that would spend credits is refused rather than quietly let through; the development fallback lives in one process and does not survive a restart.
• There is no third-party audit. We have not completed SOC 2, ISO 27001 or any equivalent assessment, and we claim no certification anywhere on this site.
• Response headers are not hardened yet: no Content-Security-Policy, HSTS or permissions policy is set at the application level.
• The public API and webhooks are not open. The /api/v1 routes serve same-origin calls from this site only, so there are no third-party keys in circulation to protect.