Skip to main content

Permissions and Safety

Permissions and safety overview

Automation Agent for Adobe Premiere uses a permission system to control what a script is allowed to do before it runs. This applies to both major workflows:

  • scripts created or refined with the Custom GPT
  • tasks executed through the MCP workflow

What You Can Restrict​

Permissions can be limited separately for Adobe Premiere and the filesystem.

Adobe Premiere permissions​

  • premiere.readAllow
  • premiere.writeAllow

Use these to decide which parts of the Premiere project a script may inspect or modify.

Premiere allow entries are matched against canonical reference paths where possible. That means access should depend on the project object being referenced, not on whether the script used a short path, a project-qualified path, or a special reference such as ::SEQ\ACTIVE.

::SEQ\ACTIVE has stable permission semantics: when it appears in a Premiere allow list, it is resolved to the active sequence for that execution and cached. If a script later activates another sequence, that does not expand the permission to the newly active sequence.

Allow entries that cannot be resolved to existing Premiere objects do not grant access. Operations that create new bins still require write access to the existing parent bin where the new bin is created.

Use marker namespace prefixes to allow marker-only access without allowing broader sequence or clip edits. For example, writeAllow: ["::SEQ\\ACTIVE::MARKER"] allows marker changes on the sequence that was active for this execution, but does not allow moving clips, changing tracks, or editing sequence properties.

Filesystem permissions​

  • filesystem.readAllow
  • filesystem.writeAllow

Use these to decide which folders or files a script may read from or write to.

Practical Meaning​

This lets you decide whether a script should be able to:

  • only inspect project state
  • modify the Premiere project
  • read external files from disk
  • write files or save changed projects

In other words, you do not have to give every script full access. You can start narrow and open up only what is necessary.

When testing a new script or agent workflow:

  1. start with the smallest useful permission scope
  2. allow read access before write access whenever possible
  3. restrict filesystem access to specific folders instead of using broad wildcards
  4. expand permissions only after the workflow is behaving as expected

A Simple Mental Model​

Use the AI-assisted workflow when you want the easiest start.

Use MCP when you want the most capable agent workflow.

In both cases, use permissions to decide how much trust and reach the current script should have.

That combination is important: strong automation becomes much more practical when access is explicit and reviewable.

Permissions are only one part of the picture, though. If your production environment has limited or no internet access, the bigger question is whether the workflow needs a live agent during execution or only during script authoring.

For that distinction, see High-Security and Restricted-Network Environments.