Scale Synthetic monitoring with granular and team-scoped access control

Scaling up your observability practice often creates access control challenges. Synthetic monitoring is no exception. As more teams rely on synthetic tests to validate releases, automate operational workflows, and monitor the availability of AI or web services, more users and automated systems need the ability to create and execute synthetic monitors. For example, QA teams may run validation checks before a release, while cloud and platform teams test APIs, services, and dependencies during deployments or failovers. Application teams may monitor critical journeys, while operations teams need broader visibility into availability and SLOs across the applications they support.

Giving teams this autonomy allows them to respond quickly to changing requirements and manage monitoring for the applications and services they know best. At the same time, organizations need a straightforward way to support this self-service model without requiring broader administrative permissions or extending access to monitors and data managed by other teams.

With the general availability of access controls for Synthetic, organizations can now manage Synthetic through the same Identity and Access Management (IAM) model used across the Dynatrace platform. Permissions, security contexts, APIs, and data access work together as part of a single access model, making it easier to align Synthetic ownership with team structures and operational workflows.

Empower teams with Synthetic access tailored to every role

Dedicated IAM permissions are now available for Synthetic, allowing organizations to grant access to specific monitoring tasks without requiring broad “Manage monitoring settings” permissions. These permissions are granular and independent, so they can be combined to match the responsibilities of each user or service account:

• synthetic:monitors:read — view monitor definitions
• synthetic:monitors:write — create, edit, and delete monitors
• synthetic:monitors:execute — trigger on-demand executions
• synthetic:locations:read/write — manage private locations
• storage:metrics:read, storage:events:read — access execution results and performance data

In practice, these permissions can be tailored to meet a range of common access needs. A developer who needs to create and manage monitors gets synthetic:monitors:read/write plus the storage permissions to see results — without requiring broader administrative permissions. A QA engineer who only triggers on-demand runs gets synthetic:monitors:read and execute. A team consuming availability data in Dashboards gets the relevant storage:metrics:read and storage:events:read. No one gets access to integration settings, API tokens, or tenant configuration just because they needed to work with Synthetic.

For the complete permissions reference including storage, credential, and entity scopes, see Synthetic access control.

Build team ownership into Synthetic monitoring with security contexts

Dedicated IAM permissions allow organizations to tailor what each role can do in Synthetic. Once you have the right permissions in place, security contexts let you go one level deeper — scoping access not just to Synthetic in general, but to a specific set of monitors. Authorized team members can share access to the monitors within their area of responsibility without extending that access to every team in the environment. These team-level boundaries support several important access patterns:

• Multi-team environments — each team sees and manages only their own monitors.
• Contractors and external users — scoped access without tenant-wide exposure.
• Automated pipelines — service accounts with minimum required permissions, locked to specific monitors.
• Regulatory or compliance requirements — IAM policies can help organizations establish auditable access boundaries and support governance requirements.

A security context establishes these boundaries by assigning a value to a monitor, representing ownership or organizational scope (for example, team-payments, team-onboarding, region-emea). IAM policies can then use those values as conditions:

ALLOW synthetic:monitors:read 
WHERE synthetic:dt.security_context IN ("team-payments") 

A user with this policy sees only the monitors tagged team-payments. A different team gets a different boundary. Same platform, same app — with visibility and management scope separated through IAM policy and security-context assignments.

The enforcement goes both ways. A user whose access is scoped to specific security contexts can create new monitors — but only if they assign at least one security context they have access to. Teams can self-serve and create their own monitors, subject to IAM policies designed to restrict monitor creation to authorized security contexts.

The same boundary extends to data. Storage permissions — storage:metrics:read, storage:events:read, storage:user.events:read, and storage:smartscape:read — support the same dt.security_context condition, so a team’s access to execution results, metrics, and events is scoped to exactly the monitors they own.

Monitors can carry up to 10 security context values, so a monitor can be visible to multiple overlapping teams simultaneously.

One platform, multiple entry points

Because Synthetic is now integrated into the Dynatrace platform, the same monitors, data, and access controls are available wherever you work:

There’s no longer a separate “Synthetic view” and a “platform view.” The permissions you set in IAM apply consistently across all of these surfaces.

Strengthen the foundation for AI-powered insights

AI-powered agents can be incorporated into software delivery, operational, and reliability workflows to analyze monitor results, assess readiness, support failure investigations, and, when authorized, trigger on-demand executions. As these workflows become more automated, agents need access to the monitoring data and actions relevant to their task without requiring visibility across the entire environment.

This creates another reason to get security contexts and team ownership right. Teams can independently manage their monitors and access the data those monitors produce, providing AI agents with scoped, team-relevant context for analysis.

When a team’s IAM policy is scoped to team-payments, they see their monitors, execution results, metrics, and events — nothing from other teams’ systems. An AI agent operating on behalf of that team works within the same boundary: focused on the payments monitoring perimeter, not distracted by unrelated signals from across the platform. The more precisely you define ownership, the more focused and relevant AI-driven insights become.

If you want to see this in practice, check out R.E.A.D.Y. — Reliability Evidence Assessment for Dynatrace Readiness, a Dynatrace-native app built for the MCP Server Challenge. It uses Dynatrace Remote MCP and DQL to assess whether a fleet of services or applications is operationally ready — not just “is there telemetry?” but “does this service have an owner, a runbook, a dashboard, team tags, and governance metadata?” The ownership structure you put in place with security contexts and IAM is exactly the evidence R.E.A.D.Y. collects and scores, scoped to whatever subset you define.

That’s the full progression: precise access control → self-service team ownership → scoped data access → AI agents focused on the right part of the system → more targeted AI-assisted analysis.

Getting started

If you’re managing Synthetic, the recommended path is:

• Audit your current user groups — who needs read access, who needs write, who runs automations.
• Assign IAM policies in Account Management > Identity & access management > Policies. Start with the built-in defaults (Admin User, Pro User) and layer in data access policies (Storage Default Monitoring Read) for users who need results visibility.
• Use security contexts to scope access where you need it — either by inheriting the one-time management zone sync or by setting values manually through the Synthetic app or Platform API.
• Replace classic access tokens in your automation pipelines with OAuth clients scoped to the exact permissions those pipelines need.

The new access model is more work to set up than “assign everyone viewer” — but it gives you control you never had before, and it holds up as your organization grows.

Dynatrace Synthetic with advanced access permissions is available starting with Dynatrace SaaS 1.343. To set up permissions, configure security contexts, and migrate from classic roles, start with the Synthetic access control documentation.