Only a small, named group should hold Publish on a production Tag Manager container. Most marketers need Edit. A reviewer needs Approve. Publish pushes code to every visitor's browser, so treat it like a production deploy right, and review each change as application code.
What each permission level allows
Google's Tag Manager help describes container permissions in five levels. The table restates them.
| Level | What the user can do |
|---|---|
| No access | The container is hidden from them |
| Read | See tags, triggers and variables, but change nothing |
| Edit | Create workspaces and make edits, but not create versions or publish |
| Approve | Create versions, workspaces and edits, but not publish |
| Publish | Create versions and workspaces, edit, and publish |
There is a second layer at the account level. An Admin can create containers and change user permissions. A plain User gets basic account visibility and inherits no container permissions, so an Admin has to assign access container by container.
Why Publish deserves a short list
A tag manager container can run custom JavaScript and HTML in the browser. OWASP's third party JavaScript guidance says so directly and recommends restricting tag manager publishing access and reviewing changes as application code. If one person with Publish has their account taken over, the attacker can add a script that runs on every page the container is on. That includes login and checkout pages if the container is there.
Two roles are enough for many teams: people who build changes (Edit) and a small group who release them (Publish), with Approve for the reviewers in between.
Steps to tighten access
- Export the current user list for every container, including agencies and former staff.
- Remove anyone who has not edited the container in the last quarter.
- Move everyday builders to Edit. Move reviewers to Approve.
- Name two or three Publish holders per container and write them down with a backup.
- Limit the Admin role to one or two people, since Admins can change everyone else's permissions.
- Require sign in protections on the Google accounts that hold Publish, such as multi factor authentication, enforced at the identity level.
- Put a quarterly reminder on the calendar to repeat the review.
Edge cases
Agencies often ask for Publish so they can move quickly. A better pattern is Edit for the agency and Publish for an internal owner who reads the version diff before release. For urgent fixes, agree in advance who can publish and how you will log it afterwards.
Shared accounts defeat all of this. If three people log in as one Google user, you cannot tell who published what. Use named accounts only.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a gate separates writing a change from releasing it, which is the same idea as Edit versus Publish.
Where Safeguard fits
Safeguard's policies and gates can hold code changes behind review in your repositories, and its SBOM and dependency scanning cover the packages you bundle into pages. Scripts a tag manager loads at run time sit outside a lockfile, so the permission review above still has to be done in the tag manager itself. You can try a free scan on a repository.
Quick check
Can someone with Edit publish a container?
No. Per Google's help page, Edit lets a user create workspaces and make edits, but not create versions or publish.
Should an agency have Publish?
Usually not. Give the agency Edit and let an internal owner review the version changes and publish.
Is the Admin account role the same as Publish?
No. Account Admin controls containers and permissions. Publish is a container level right. Keep both lists short.
Sources
Last reviewed: 19 October 2026.
