That's a very valid concern. And yes, Charlie will be able to execute arbitrary JS on those pages. Reading/rewriting cookies, changing the whole DOM, forcefully redirecting people to other sites. Basically, a lot of things.

Therefore, Alice and Bob should be extremely careful when allowing third-party tag management systems. Well, no, they should not allow them at all.

This is done differently. Other ways to consider:

1. Give Charlie's devs access to Bob's and Alice's GTMs and give them write permissions. Here is info on how to do that: https://support.google.com/tagmanager/answer/6107011?hl=en and some info on permissions: https://support.google.com/tagmanager/answer/6107011?hl=en#container_permissions

2. Make a few new GTM containers for Charlie. Bill will make one and share the write access, Alice will make one and share the write access. It's similar to the previous but now all Charlie's logic is in a separate container.

In both cases, write access for Charlie's devs implies requirement for Bob's and Alice's devs to validate the changes by Charlie's devs. The second case, however, will require syncing two containers on a page. It may require advanced GTM knowledge. In particular, defining tracker names for all containers to avoid data intermingling. But there's a good reason GTM does not recommend defining trackers. When you define trackers, GTM starts behaving differently. If before you could expect from each tag to execute in its own context, now you won't be able to do that, so a lot of fields that were not explicitly set for this tag, but was set to the previous, will be inherited by this tag, so the context will start being persistent. That requires a bit different approach to tracking. A bit unusual. GTM allows all the tools necessary to accommodate it properly, but even senior GTM devs are often oblivious to those tools. And it leads to bugs that are rather harder to tackle.

3. Finally, arguably the best way, would be having Bill and Alice connect their implementators with Charlie's analysts and have them implementing whatever tracking the analysts require. It is usually not much for affiliates and that's exactly how enterprise analytics works in the world of big corp. Since Charlie is an affiliate, there's a reasonable expectation that there will be more affiliates. Which now allows Bill's and Alice's implementators to build some rules and semi-automated solutions for a complete affiliate onboarding analytics-wise. They will end up having a few look-up tables (or just a neat JS var) and a few pixel/GA tags using the LUT for account ids.

Done! Pretty solid ground to support virtually unlimited number of affiliates with no significant strain on the implementation side.

4. Letting Charlie and the others having their containers on pages is a sure way to chaos. It will likely end up taking more time and effort than any other option.

GTM by itself does not filter, you have to create the setup accordingly.

Allowing to load a complete GTM container sounds like overkill and is rather dangerous no matter what. But you can create allow-lists or deny-lists to restrict tag deployment, and allow only certain categories of tags.

A deny list needs to exclude custom HTML (javascript), else it is pointless (since Charlie could just implement prohibited pixels via Javascript). It might be difficult to set this up so that the allow/deny lists only affect Charlies container and not your own.

The better way is to have Charlie supply a custom template for his tracking tag. Custom templates in GTM use "sandboxed javascript", a subset of JS with access to some Google APIs that prevents dangerous operations (e.g. DOM access). You can set additional permissions of what Charlies tag is allowed to do or not (setting Cookies, sending pixels to certain urls, loading scripts etc).

To make this more explicitly, if you allow a third party to render a GTM container under their control into your site, you surrender control of your site to them and they can steal data, read cookies, deface your site and do anything else that is possible with Javascript.

You can mitigate this via deny-lists and template policies, but the much better idea is not to allow this in the first place and look for a less obtrusive solution.

Also if you are in the jurisdiction of the GDPR and the ePrivacy direction, you need to make sure that Charlie implements his tracking in a compliant fashion and there is no way you can do this.