If an agent should create review drafts but never post them, enforce that boundary in its credentials as well as its prompt. Instructions such as “do not publish” are useful, but a creation-only integration should not need a key that can create public posts.
Prolifik's paid-plan API keys support separate read, creation and publishing scopes. The correct scope set depends on the work. Read scopes are not automatically included in write scopes, so an agent that creates a video and retrieves the result needs both relevant permissions.
This guide focuses on that access decision. It does not claim that a restricted key creates a complete approval system, that write access is harmless or that every OAuth connection exposes the same configurable scope choices.
Define the job before choosing the scopes
Consider a fictional agency assistant that turns approved copy into Text Story drafts. It needs to find the right brand, check usage, submit a content job and retrieve the pieces. It does not need to select social destinations or create a publication record.
A reasonable starting point for this task is content:read and content:write, without publish:write. Verify the current endpoint requirements against the actual operations you intend to call.
Be precise about the source of approval. An accepted script is permission to create that draft only when the user has authorized it. It is not blanket permission to change brands, delete pieces or run an unlimited stream of jobs.
Know what creation access still permits
The name content write is broader than generate one video. In the current API, this scope covers several content mutations, including editing and deleting resources. Excluding publication reduces one risk; it does not make the rest of the key read-only.
For a reviewer who only needs to inspect output, use read permission instead of reusing the creator's key. Keep destructive operations behind suitable client controls and human authorization. Do not describe a broad content-write scope as a narrowly delegated single-render capability.
The content-approval workflow explains who should make editorial decisions. Scopes enforce service access, while the team still needs a clear review owner and a record of the media version they accepted.
Use the smallest relevant capability group
| Intended integration task | Scope boundary to inspect |
|---|---|
| Read brands and existing content | content:read |
| Create and retrieve Content Studio drafts | content:write plus content:read |
| Create and retrieve clip jobs | clipper:write plus clipper:read |
| Read Studio models or results | studio:read, subject to plan availability |
| Generate Studio media | studio:write plus the reads needed for follow-up |
| Publish content | Requires publish:write and the endpoint's other conditions |
Posting a clip currently requires both clipper:write and publish:write. A key that can create clips but lacks publishing permission cannot simply reuse that operation to post them.
Do not add Studio scopes because the workflow contains the word video. Content Studio, AI Studio and the Clipper have different inputs, usage meters and tool groups.
Separate API-key controls from OAuth setup
Prolifik API keys require a paid plan. Trial users can connect supported MCP clients through OAuth, within trial and client limitations. Do not tell a trial user to create a paid-only key to follow this scoped-key design.
The documented OAuth connection and an API key do not present the same access configuration. Consult the current authentication documentation before promising that a person can select precisely these scopes during an OAuth consent flow.
Client restrictions also matter. The supported Prolifik Claude OAuth connection does not expose AI Studio or cloning tools. Giving an agent a broader prompt does not make those tools appear, and a missing tool should not trigger an attempt to bypass the intended client boundary.
Verify the boundary without testing a real public post
Start by inspecting the key's selected scopes and the tools or endpoints available to that authenticated integration. Confirm read access with a harmless operation such as listing owned brands. Keep the secret out of screenshots, command output and source control.
For automated testing, use fixtures or a dedicated authorized test setup to verify that a request lacking publication scope is rejected. Do not use a real customer's ready video as a speculative publishing probe. If the key were configured incorrectly, such a probe could succeed.
Test both expected success and expected denial. A creation-only workflow that cannot retrieve its own result may be missing the read scope, not need publication access. Adding every available scope to fix a generic error defeats the design.
Give the publisher a separate handoff
After review, pass the accepted piece identifier, media version, caption, destination and timing to the authorized publishing workflow. Keep the creation key out of that handoff; the publisher uses its own appropriate access.
If the piece changes after approval, invalidate the old approval and inspect the new render. Permissions do not know whether the current words are the ones a reviewer accepted.
For the broader state model, see the video-agent design guide. For this access boundary, review Prolifik's API scopes and choose only the operations the specific integration needs. The useful result is a creation workflow whose credentials agree with its stated job.
Match the key to the integration's real task
Review the exact read, content, clipping, Studio and publication scopes before giving the agent access.
Review API scopesFacts checked 2026-10-24. Worked examples are illustrative unless a real source is identified.
- Prolifik API authentication and scope reference Checked 2026-10-24
- Prolifik MCP authentication and client tool availability Checked 2026-10-24