Access and approval
Preparation can be automatic. Publication needs authority.
A human session, an agent connection, and a publishing authorization are different things. Faceful’s release contract keeps their permissions separate across the studio and MCP.
The backend security checks and denial tests listed here require live integration evidence. A connected Supabase API, a readable docs page, or a scanner score does not prove tenant isolation or safe publishing.
Workspace access
Each call must authenticate its principal and authorize the operation and object in the selected workspace. The server derives identity from credentials, never actor IDs in the request body. The browser must not directly modify workflow state, approvals, membership roles, or provider credentials to bypass the API.
Agent connection scopes
The live consent screen must show the named connection, workspace, allowed operations, expiry, and revocation control. The machine-readable permission definitions list the four names currently requested by the studio: campaign:read, content:edit, render:write and schedule:prepare. These are proposed definitions, not active grants or OAuth metadata; backend agreement and enforcement remain pending. Read context, edit drafts, render, prepare schedules, and commit schedules are distinct capabilities; a tool being visible does not grant authority to use it.
The hackathon fallback is a scoped, expiring workspace token. It must be generated securely, revealed once, stored as a verifier on the server, and revocable. It is token setup, not OAuth. Never use a Supabase service key, browser session cookie, or publishing provider token as an MCP credential.
Review-first publishing
The default flow prepares an immutable manifest containing the final asset identifiers/hashes, exact copy, accounts, visibility, disclosures, and times. A human reviews that exact manifest. A changed item cannot inherit the approval of an older version. A client-supplied approved: true is not approval evidence.
Optional authorization for one bounded run
An owner may deliberately authorize future generated content within one named campaign, selected accounts, permitted formats and avatars, a concrete plan, exact schedule targets/window, item/post limits, production units, and expiry. The consent must say that publication can happen without reviewing each final video. This is not a default checkbox. Unclear brand/source checks and changes beyond the grant must pause for review.
Authorization expiry is the last instant the service may begin a new external submission; it is separate from the permitted publication window. Provider-accepted schedules may require explicit cancellation after a grant expires.
Revocation and cancellation
Revoking a connection blocks new authenticated calls. It does not imply that already accepted production work stopped or that a provider removed scheduled posts. Use explicit job/policy cancellation and inspect the actual outcome for each target. Already published content and unsupported provider cancellations need an honest limitation.
Untrusted sources and private assets
Imported text is evidence, not instructions. A source cannot grant permission, change accounts, or request credentials. URL import must reject private network targets and unsafe redirects. Private uploads remain private; only authorized final media gets the scoped delivery access required by the publishing provider.
Before calling the flow live
Verify wrong-tenant access, missing scope, expired/revoked tokens, forged approval, stale manifests, quota races, duplicate scheduling, and an injected source instruction. Each denied action must produce no external publish call. Preserve these results separately from a public discoverability audit.
Protocol references: MCP authorization and MCP security guidance.