Dynatrace synthetic access control: isolate monitors by team

Friday, five in the afternoon: someone on the payments team tidies the tenant’s monitor list and deletes a login scenario that looks abandoned. It belonged to the catalogue team. On Monday their availability SLI has a hole in it and nobody knows why. Dynatrace synthetic access control exists to make that story impossible, so that on a shared tenant each team sees and edits only its own monitors. I work from the « Access control » page of the Synthetic documentation (labelled « Latest Dynatrace », so SaaS), read on 8 November 2026.

A word on method: I have not replayed these settings on a tenant. The two policies shown below are the documentation’s, reproduced as they are. Dynatrace Managed is not mentioned on that page, so I say nothing about it.

The trap: classic rights open everything

Before writing any policy, it helps to see why isolation so often fails. Two permission systems sit side by side. Classic permissions (« View environment », « Manage monitoring settings ») apply to the entire tenant, and a security context does not bound them. The Synthetic platform permissions, handed out through IAM policies, are the only ones that accept a context condition. In practice, one classic right forgotten on a user’s profile undoes all the work. For the wider picture of both worlds, see Grail versus classic permissions.

What you need on hand: a Latest Dynatrace tenant, administrator access to the account (Account Management > Identity & access management > Policies), one user group per team, and, if monitors run from private locations, ActiveGate 1.331 or later. Below that, execution metrics and events do not carry the monitor’s context, so a scoped policy cannot reach them.

Dynatrace synthetic access control in three parts

The mechanism boils down to three ideas, easiest to remember through a badge analogy.

• The security context is a label put on the monitor. A monitor can carry up to ten. The documentation sees it as the successor of Dynatrace Classic management zones, with one big difference: you no longer organise entities into zones, you mark monitors and bound rights on the mark (the historical background is in management zones).
• The IAM policy states who may do what, in one line of syntax: ALLOW permissions WHERE conditions;. A permission may apply everywhere, or only to monitors with at least one context in the condition’s list. Two people holding the same synthetic:monitors:read permission then see different lists.
• The permissions themselves: synthetic:monitors:read, write and execute for configuration and on-demand runs; storage:metrics:read, storage:events:read and storage:user.events:read for results kept in Grail; storage:smartscape:read so the Synthetic app can list the monitors.

Rolling out the isolation, team by team

Name first, then label

Choose short values that will not change; the documentation uses team-a and team-b. One rule surprises people at creation time: a user bounded to a context must assign at least one context they hold, otherwise the monitor is refused. Only holders of platform permissions can set or change these values.

Is your environment older than January 2026? The page describes a one-off copy at the version 1.343 rollout: each monitor’s management zones became contexts of the same name. It is a snapshot, not a continuous sync: zones created afterwards do not follow, and nothing is switched on by itself.

The practical UI question remains: where do you enter the value on a monitor? The page I read does not say. That point is unverified and I will not make it up; check the Synthetic app or API documentation.

One policy per team, two families of rights

The recommended model is one policy per team, conditioning every Synthetic permission on the team’s value and adding the matching data reads. Here is the page’s example for team-a.

Notice there are two blocks. The first bounds configuration through synthetic:dt.security_context, the second bounds data through storage:dt.security_context. Skip the second and the team sees its monitors but empty result pages. For team-b, copy the policy and change the value.

Bind, then tighten

Create the policies under Policies and bind each to its team’s group. The page stresses granting only what is needed: a plain reader needs neither write nor execute.

One last watch point, the base rights. The default policies (Admin User, Pro User, Standard User) contain no Grail data reads, and the documentation names data policies to add, such as Storage Default Monitoring Read. They are broad: if isolation is the goal, keep the conditioned reads above and do not add an unconditional read for convenience.

When RUM and Synthetic share one permission

Here is a detail that can cost you: storage:user.events:read also covers RUM user events. Unconditioned, it opens Synthetic data and real visitors’ data alike. According to the documentation, events produced by monitors receive their security context; the storage:dt.security_context condition reaches them, while RUM session events, with no Synthetic context, stay out of reach. The page offers a « synthetic-only » policy:

If instead it is your sessions that are missing on the RUM side, that is another problem, covered in Synthetic sessions missing from RUM.

Acceptance test: two users, four checks

Do not call it done on the strength of the policy text. Create two test accounts, one in team-a, one in team-b, with no policy except their own, then walk through:

1. Visibility: A sees only team-a monitors in Synthetic; B sees only theirs.
2. Creation: A creates a monitor with team-a and it goes through. With no accessible context, the page says it is denied.
3. Results: A opens the executions of a monitor from their team. List visible but results missing? Look at the storage:* reads, then the ActiveGate version for a private location.
4. Classic leftovers: strip every classic permission from both accounts. If one keeps any, that user sees the whole tenant.

That expected behaviour is what the documentation describes, not the outcome of my own measurements.

What the isolation does not cover

• Private locations: the « Private locations » tab needs storage:smartscape:read and storage:metrics:read without a context condition, plus suitable location rights. Those rights are tenant-wide.
• Conditional DENY: on a Grail table permission it is not supported and behaves as an unconditional DENY (policy syntax page). Isolate with conditioned ALLOW statements.
• Early Adopter API: the Synthetic Platform API endpoints sit at that maturity level per the page, so they may change.
• Management zones: the monitor list relies on Smartscape nodes, which they do not support; old zone-based rights do not restrict it.
• Legacy monitors: a user limited to a zone in classic rights can create monitors in Synthetic Classic, but Latest Dynatrace does not display them.

Best practices

• Give a team’s context and policy the same name, so an audit reads at a glance.
• No classic permission for anyone you isolate.
• Validate with two real profiles before removing the old rights.
• Move automation from classic tokens to OAuth clients, as the page advises (OAuth module of the Monaco SaaS course).
• Cap rights with policy boundaries to slow privilege escalation.

And to design the monitors themselves: HTTP and browser synthetic monitoring.

Frequently asked questions

Does synthetic access control apply to Dynatrace Managed?

The page I read is labelled « Latest Dynatrace ». I verified nothing for Managed and claim nothing.

Can classic permissions be bounded to one monitor?

No: they always cover the whole tenant and security contexts do not restrict them. To reserve monitors for a team, use IAM policies bounded by context.

How many security contexts per monitor?

Ten at most. A bounded permission applies as soon as a monitor carries at least one of the values listed in the condition.

Conclusion

Back to that unlucky Friday deletion: with one context value per team, a policy bounding both configuration and data, and a two-account test, the scenario stops being possible. The enemy remains the forgotten classic permission, which reopens the whole tenant. For the exact grammar of conditions, the policy syntax page is authoritative.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Trademarks belong to their owners. Tools change fast: check permissions and syntax in the official documentation before applying them in production.

---

Originally published on span.observer. French version: https://span.observer/fr/controle-d-acces-synthetic-dynatrace/.