Blog

The sGTM access control model nobody documents

Workspace permissions, container permissions, and the runtime auth token each control different things.

sGTM has three independent layers of access control: workspace permissions in the GTM web UI, container permissions on the parent container, and the runtime auth token that the running tagging server uses to fetch its config. Each one controls something different, and conflating them is how access bugs slip in.

Layer 1: workspace permissions

In the GTM web UI, each workspace has user permissions: Read, Edit, Approve, Publish. Set per-user. These permissions control who can see and modify the workspace contents.

A user with Read can view tags but not change them. Edit can modify. Approve can submit changes. Publish can push live.

Layer 2: container permissions

At the container level (one level above workspaces), there are User and Admin roles. Admins can add and remove users from the container. Users can only do what their workspace permissions allow.

A common mistake: granting workspace Edit to a user without granting them container User access. The result: they can edit but cannot save, and the error message is opaque.

Layer 3: runtime auth token

The running tagging server fetches its config from Google's GTM service using an auth token embedded in the container config URL. The URL looks like:

aHR0cHM6Ly93d3cuZ29vZ2xldGFnbWFuYWdlci5jb20vZ3RtL3NlcnZlci9jb250YWluZXJzL...

The base64 blob contains the container ID, workspace ID, and a token. Anyone with this URL can run a tagging server that serves your config.

If the URL leaks (committed to a public repo, posted in a chat that gets archived publicly, etc.), regenerate it. In the GTM admin, container settings > "Generate new container config." Update your runtime to use the new URL.

Where each layer matters

  • Day-to-day editing: layer 1 (workspace permissions).
  • Adding a new team member: layer 2 (container permissions) plus layer 1 for specific workspaces.
  • Migrating to a new tagging server provider: layer 3 (runtime auth token).

Auditing access

In the container settings, the User Management page lists everyone with access at any layer. Run this audit quarterly. Most teams discover at least one stale account: a contractor who left, an analyst who switched roles, a former agency partner whose engagement ended. Remove them.

For the runtime token, check your secrets management system to see who has access to the container config URL. If it is in a shared password manager, restrict to only the operations team. The general tag audit covers the wider housekeeping.