Introduction

Traffic Manager linked records creates a direct, managed link between an Azure DNS record set and a Traffic Manager profile. When a query arrives, Azure DNS evaluates the linked Traffic Manager profile internally and returns the appropriate endpoint response directly. For A and AAAA records, this means the client receives endpoint IP addresses without an intermediate CNAME response to trafficmanager.net.

This practical guide uses a small multi-region Contoso scenario to explain the architecture, configure the feature in the Azure portal, validate the DNS response, and demonstrate endpoint failover. The feature is currently in public preview, so the walkthrough should be tested in a non-production environment before broader adoption.

Note: DNS-based global routing is powerful, but the traditional integration between a custom domain and Traffic Manager adds an intermediate name that customers must understand, resolve, and govern.

The scenario and the problem

Contoso operates a public application across North America, Europe, and Asia. Users browse to contoso.com. Azure Traffic Manager monitors the regional endpoints and selects the preferred healthy destination according to the profile routing method.

• Traditional CNAME integration can expose the intermediate trafficmanager.net name in the DNS response.
• A CNAME cannot be placed at the zone of apex, which makes root-domain routing harder.
• An unsigned intermediate DNS hop can interrupt end-to-end DNSSEC validation.
• Operations teams must understand which system is authoritative for the customer zone, and which system makes the routing decision.

Design objective

Preserve Traffic Manager routing methods, endpoint health monitoring, and automatic failover while returning the effective endpoint answer directly from Azure DNS.

The solution: Traffic Manager linked records

Figure 1. Traditional CNAME resolution compared with Traffic Manager linked record.

As you see in figure 1 above, the left side shows the traditional path. The client queries the application name in Azure DNS, receives a CNAME that points to a trafficmanager.net profile name, and then performs another lookup before receiving the selected endpoint address. The right side shows the linked-record path. Azure DNS remains authoritative for the Contoso zone, consults the linked Traffic Manager profile internally, and returns the selected endpoint directly.

The key point is that the Traffic Manager still performs the routing decision and health evaluation. Linked records change the DNS integration and the answer returned to the client; they do not turn Traffic Manager into a reverse proxy or place it in the application's data path.

Reference architecture

Figure 2. Practical multi-region architecture for testing direct resolution and failover.

Reference architecture in figure 2 above shows the client queries contoso.com. Azure Public DNS hosts the authoritative zone and contains a record set linked to the tm-profile Traffic Manager profile. The profile uses a configured routing method and continuously evaluates the health of the regional endpoints. Azure DNS uses the Traffic Manager decision and returns the effective endpoint answer to the client.

For a simple lab, two endpoints are enough. Configure the first endpoint with priority 1 and the second with priority 2. The third regional endpoint in the diagram illustrates how the same design scales to additional regions. The record set can be created at the zone apex by leaving the record name empty, or for a subdomain such as www.

Note: Traffic Manager is DNS based. After name resolution, the client connects directly to the selected public endpoint. Application traffic does not pass through the Traffic Manager.

Prerequisites

• An Azure subscription and permissions to create or update Azure DNS and Traffic Manager resources.
• A public domain hosted in Azure DNS and delegated to the Azure DNS name servers.
• Two public application endpoints that can return visibly different responses for failover testing.
• The Microsoft.Network resource provider is registered in every subscription that contains the DNS zone or Traffic Manager profile.

Implementation in the Azure portal

The portal workflow has two main parts: create a strictly typed Traffic Manager profile, then create an Azure DNS record set that links to that profile.

Create the Traffic Manager profile

Step1: Open Traffic Manager profiles, select create.

Step 2: Configure the profile and instance details, fill out the subscription, resource group, name(tm-profile), routing method: priority, record type: A, and resource group location.

Step 3: Add endpoints (Add tmendpoint-1 as the public IP address and external endpoint type with priority 1.

Step 4: Repeat Step 3 to add the secondary endpoint (Add tmendpoint-2 as the public IP address and external endpoint type with priority 2)

Step 5: Confirm endpoint health (Wait until both endpoints report online before testing DNS behavior.)

Note: The record type selection creates a strictly typed profile. Select A for IPv4 answers, AAAA for IPv6 answers, or CNAME for canonical-name answers. The type is used to validate compatibility between the Traffic Manager profile and the linked DNS record.

Create the linked record in Azure DNS

Step 1: Open the Azure DNS zone, select the zone that hosts the application domain, for example contoso.com.

Step 2: Add DNS record sets, select + record set.

Step 3: Choose the record name, leave name empty for the zone apex or enter www for a subdomain.

Step 4: Choose the type, select the record type that matches the Traffic Manager profile, for example, A.

Step 5: Enable Traffic Management, select Enable Traffic Management (Preview).

Step 6: Select the profile, choose the profile subscription and tm-profile, then save the record set.

Note: The record set contains a managed association to the Traffic Manager profile. The linked record inherits its TTL from the Traffic Manager profile.

In the Azure DNS record list, the new record should appear as a linked record associated with the Traffic Manager profile. For an apex A record, the conceptual result is:

Validate the DNS response

Use both the Azure portal and direct DNS query. The portal confirms the resource association; the DNS query confirms the serving behavior.

Portal validation

• The record exists in the expected Azure DNS zone.
• The record type matches the strictly typed Traffic Manager profile.
• The linked profile is tm-profile.
• The Traffic Manager endpoints show their expected health state.

Command-line validation

 

A successful A-record test returns the selected healthy endpoint IP address and does not include a trafficmanager.net CNAME in the answer. Querying for an Azure DNS authoritative name server directly is useful during testing because it reduces ambiguity from local recursive resolver caches.

The specific endpoint returned depends on the routing method, endpoint health, source resolver location, and cached TTL behavior. Validate the result against the profile configuration rather than expecting one universal IP address.

Prove automatic failover

A practical demonstration should show that the linked record is not static. The returned answer continues to reflect Traffic Manager health decisions.

Why this matters for real architecture

Preview and operational considerations

• Treat the feature as preview and review the Microsoft Azure preview supplemental terms before production use.
• Confirm that the DNS zone and Traffic Manager profile subscriptions have the required resource provider registration.
• Plan the record type before creating the Traffic Manager profile because the strictly typed profile value cannot be changed after creation.
• Remember that the record TTL is inherited from the Traffic Manager profile.
• Test routing, endpoint health, DNSSEC behavior, zone-apex resolution, and rollback in a controlled environment.
• Document the previous DNS record so the change can be reversed if the validation plan fails.

Conclusion

Traffic Manager linked records is a focused DNS improvement with meaningful architectural impact.

The feature keeps Azure DNS authoritative for the customer domain, preserves Traffic Manager health-aware routing, and removes the need for the client to follow an intermediate trafficmanager.net hop. That creates a cleaner DNS response path and enables scenarios that were difficult with a traditional CNAME, especially zone-apex routing and DNSSEC-protected domains.

The strongest way to evaluate the feature is through a small, observable lab: create a strictly typed profile, link an Azure DNS record, query the authoritative DNS server, and deliberately fail the primary endpoint. When the DNS response changes to the secondary healthy destination without exposing an intermediate Traffic Manager name, the value becomes immediately clear.

Final takeaway

A small change in DNS integration can simplify the client experience without giving up Traffic Manager routing intelligence, monitoring, or failover.

I hope you enjoyed it!

References

• Traffic Manager linked records overview - Azure DNS
• Tutorial: Create a Traffic Manager linked record - Azure portal - Azure DNS
• Create a Traffic Manager linked record using Azure CLI
• Azure Traffic Manager overview
• How Azure Traffic Manager works
• Azure DNS FAQ

                                            Visual note: Figures in this document were generated with Microsoft Copilot for explanatory use.

Thanks to visagarwal​ for co-authoring this post. Cross-posted from: https://commandline.microsoft.com/azure-sre-agent-restricting-environment-ai-safety/

Azure SRE Agent gives an LLM tools, a code execution environment, and access to production resources. The first question most people ask is: “How is that safe?”

The instinctive answer is to restrict the agent. Least-privileged scopes. Short-lived credentials. A human approval gate in front of anything that mutates state. All of that helps, and we do all of it.

But after a year in production, we learned that restriction is only half the answer. A useful agent needs the capability to reason, the authority to act, and the agency to carry work through to completion. It must gather evidence, choose between tools, and act on what it finds. The same authority that makes an agent useful is also what makes it risky.

Human review is the obvious mitigation, and it remains the right boundary for irreversible, high-consequence actions. But if every meaningful action requires approval, the human is still operating the system one click at a time. The agent hasn’t removed the operational burden; it has only changed the interface. Rather than simply restricting the agent, the design problem is figuring out how to make a much larger class of actions safe enough to execute autonomously.

So, we start from a harder assumption: the agent will eventually do the wrong thing—whether it’s talked into it by a poisoned log line or simply going wrong on its own. A prompt can tell the agent what it should do, but it can't guarantee what the agent will do. The same is true of controls implemented inside the environment the agent can inspect or influence. To the agent, a control within reach is just one tool call away from being bypassed.

The enterprise version of this problem is harder, because a shared agent serves readers, operators, and admins at once. “Can the agent do this?” splits into multiple questions: Who is asking? What authority do they carry? What can the execution environment reach? Where do the credentials live while it runs?

But the safer platform isn’t the one with the most approval gates. To maximize safety, you need to move the controls outside the agent’s reach. Inside its execution environment, the agent stays fully capable. Outside it, the enforcement layer decides what the environment can reach, what authority each operation carries, and when a human enters the loop. Authority is issued per task and expires with it. Prohibited behavior isn’t discouraged; it fails to execute.

We rebuilt Azure SRE Agent around this model. What follows traces each boundary we introduced, the gap it exposed, and how moving enforcement out of the agent let us increase autonomy without treating safety as a matter of trust. 

Right intentions, unsafe outcomes

Let’s start with where we got it wrong. The failures that changed our architecture weren’t clever attacks. They were normal agent behavior pointed at an environment that allowed the wrong outcome.

• The agent issued itself a credential, bypassing its harness. During an early test of PR-creation flow, the agent’s short-lived GitHub token expired. It inspected its own source, reconstructed the OAuth device-code flow, and prompted a researcher to complete the login, then wrote the new access and refresh tokens to its filesystem for reuse. The harness was supposed to fetch credentials and determine what authority the agent received. Instead, the agent rebuilt that machinery from inside its runtime and replaced the system-provided credential with one it had acquired itself.
• It exfiltrated an image by trying to read it. Asked to interpret a screenshot in an alert payload, and lacking a vision tool, the agent found a free OCR service on the public internet, POSTed our test image to it, and read back the text. That’s a perfectly reasonable chain of thought—and it showed the possibility for customer data could be shipped to an unvetted third party and logged onto someone else’s server.
• It found a customer’s secret and memorized it. A credential was committed in a customer repo. The agent found it during an investigation, quoted it in its findings, and saved it to memory with a note never to use it. This was well-intentioned, but now the secret lived in an investigation summary and a memory store, neither of which is in anyone’s rotation playbook.
• It deallocated a VM on a pattern match. The agent was instructed to deallocate VMs after five safety checks. During one run, the logging service became unavailable after the third check. Instead of stopping, the agent matched the situation to a past memory where deallocation had been safe and deallocated anyway. Right authority, wrong action.

None of these needed an adversary—that’s the point. An adversary just makes it all worse for free: every channel the agent reads can be written to by someone you don’t trust, and at the execution layer, a hallucinated command and an injected one are the same command. The recent public disclosure of a coding agent steered into reading `/proc/self/environ` and finding a live API key is just the OCR story with malice added.

If you strip away the good intentions, there are three classes of attacks:

• Bypassing the harness itself
• Exfiltrating sensitive information or secrets
• Taking disruptive actions against production resources

Underneath all four incidents is the same interaction pattern: the agent sits between things it reads and things it can act on. Every inbound channel can carry untrusted instructions. Every outbound channel can leak sensitive data or change production.

That forced the shift:

If the environment permits it, the agent will eventually do it—intentionally, maliciously, or by accident. The environment is the policy.

So, we moved the policy boundary outside the agent’s reach, converging on four enforcement layers that close the gaps.

1. Sandboxing: Get execution out of the trust boundary

Like many agents, our first design ran the harness itself, model-authored code, tools, and credentials together on the same machine—a pattern inherited from coding assistants. The harness is the control plane: it drives the loop, enforces policy, registers tools, and fetches credentials. Every path from the agent to the rest of the platform runs through it. That works better when there’s a human in the loop. Autonomous agents keep the layout but lose that immediate oversight, leaving model-authored code with the host’s network, filesystem, and identity.

The GitHub incident was possible because the harness sat on a filesystem the agent could read: when the agent’s token expired, it pulled the OAuth flow out of the harness’s own source and ran it itself. Better in-process checks wouldn’t have closed the gap: a policy hook can inspect a command before it runs, but the agent can inspect the hook right back - modify it, kill it, route around it. The code being governed can interfere with the machinery governing it.

Co-residency cut the other way, too: model-authored code had the host’s network. The OCR incident was possible because nothing stood between the agent deciding to send customer data and the request leaving the machine. The prompt said not to. The network still allowed it. The same co-residency also puts platform secrets within reach, often one file read away in places like /proc/self/environ from model-authored code, injected or not.

So, we split the system into two. Agent reasoning and orchestration stay in a trusted runtime. Model-authored code and tools run in a per-agent microVM, connected back to the runtime over a narrow API surface. Inside the VM, the agent keeps full control: inspect files, launch processes, install packages. The agent can’t touch the machinery governing it—provisioning, tool mounting, policy, credential flows—none of which shares its filesystem. Platform secrets stay outside it, and egress is default-deny at a boundary the model can’t modify. The agent may still attempt the OCR call; it simply can’t leave.

We chose microVMs—built on ACA Sandboxes—over containers because containers share the host kernel. For arbitrary model-authored code, we wanted each agent to have its own kernel behind a hardware-virtualized boundary without sacrificing interactive startup times.

But isolation leaves a gap: tools still need to authenticate. Put credentials inside a microVM, and they become accessible to everything running there, including model-authored code, dependencies, and local MCP servers.

The sandbox needs to use credentials without possessing them.

2. Nothing worth stealing

Isolation moved platform secrets out of the runtime into the tool execution sandbox. But tools still need to authenticate. az needs an Azure token. git needs repository access. kubectl, MCP servers, and package registries need credentials of their own.

Put those credentials inside the microVM, and it’s still a credential-bearing environment. Every tool, generated script, dependency, and local MCP server runs beside the agent’s working identity.

Egress allowlists aren’t enough. The destinations a stolen credential would be sent to are often the same ones the agent must reach. GitHub, Azure, Kubernetes, and registries must all remain accessible.

So we adopted a stronger rule:

The sandbox can use credentials, but it can’t possess them.

We did not rewrite git, az, kubectl, or existing SDKs. They still request authentication through their normal paths but receive an opaque handle instead of a real credential. The handle is useless outside the egress proxy that transforms it.

The proxy does the real exchange at the boundary. Each handle is valid for exactly one tool call, one destination, one operation, and one use:

• Call-bound: Valid only for the active tool call—the git push that requested it, not the rest of the session.
• Destination-locked: Usable only for the endpoint authorized for that call. A handle for github.com/organizationA/repoB does not get filled for repoC, a public gist, or any other GitHub path.
• Scope-limited: Restricted to the approved operation. A handle for pushing one branch is not repo-admin auth.
• Single use: Dead once the request is completed. Replay doesn’t produce another credential.

Only after those checks pass does the proxy inject a short-lived credential into the outbound request. The credential never enters the VM’s filesystem, environment, process memory, tool output, model context, logs, or memory.

This closes the failure mode from our GitHub incident. An expired token no longer gives the agent an opportunity to reconstruct OAuth, capture refresh credentials, and turn its sandbox into a credential store. Credential issuance and refresh terminate outside the VM.

But authentication credentials are only one class of sensitive data. A legitimate tool call can return secrets as data: az command can retrieve a key or connection string, just as a repository, configuration file, or log can contain passwords, tokens, or keys as ordinary text. In those cases, the secret can still enter the sandbox as part of the requested operation.

That was our memorized secret incident. The agent found a customer credential during an investigation, quoted it in its findings, and saved it to memory with a note never to use it. But the ordering was already wrong: once the value had entered model context, a note not to use it couldn't undo the exposure. The secret had already propagated into memory, sub-agents, and investigation notes.

This requires a second boundary, which we are piloting internally: inspecting and scrubbing sensitive tool output before it enters model context.

The rules are simple:

Real credentials never enter the sandbox. Raw secrets never enter the model.

At this point, the agent can authenticate without acquiring durable credentials and investigate without ingesting recognized secrets. But neither guarantee prevents an authorized action from being wrong.

3. Authority without blanket approval

Secretless authentication determines how the agent reaches production systems—but not which production effects may proceed unattended.

The VM incident exposed that gap. The agent didn’t steal a token, bypass egress, or leak data. It used a valid path to take a production action, but the action was wrong. When its safety checks became unavailable mid-run, it should have stopped and escalated. Instead, it matched the situation to a past trajectory and deallocated the VM—through a path the approval policy never intercepted.

That’s the other half of agent safety: not whether the agent can perform an operation, but whether it should perform this operation, now, against this target, given this evidence.

Our current production boundary is simple: every mutation requires human approval. Reads stay autonomous, writes wait for approval, deletes are blocked. It’s safe, but it treats every change alike. The hard cases sit in between - restart this instance, scale this service, drain this node, deallocate this VM. No policy can classify these from the command alone. The same operation is routine or catastrophic depending on three inputs:

• The operation: Restart vs. deallocate.
• The target: A disposable test VM vs. a critical production dependency.
• The evidence: A proven-unresponsive host vs. a missing or hallucinated check.

Anthropic’s Claude Code auto mode and Meta’s agent guardrails point in the same direction: classify each action before letting it run unattended. So, we treat approval as a risk-classification problem rather than a permission check. Before execution, an independent guard - outside the agent's reasoning loop - scores the proposed action against all three inputs: what it does, what it touches, and whether the evidence behind it is current and corroborated. Low-risk actions with current evidence proceed. Critical targets, or actions with insufficient evidence, stop for review.

We’re still building this layer out, and it’s where our design is least settled. But it already unlocks event-driven operation: an incident, a failed deployment, or a scheduled task can start an investigation with no human in the chat. The agent gathers evidence, takes the actions classified as low-risk, and pauses exactly where the remaining authority requires a person.

The unit of approval is not the command. It’s the operation, its target, and its evidence.

Everything above assumes the agent is acting autonomously. But when a human enters the loop, it acts on behalf of that person—and with the agent being a shared team resource, the question shifts from, “Is this action safe?” to, “Is this user allowed to cause this action?” That’s the next boundary.

4. Nothing to borrow

The previous layer decides whether an action is safe enough for the agent to perform unattended. A shared agent can’t answer that question with one sandbox, one tool set, one memory, and one identity for everyone. Doing so creates a confused deputy: a low-privilege user can borrow capabilities they don’t hold directly or modify shared state that influences a more privileged session later.

Shared memory makes the problem concrete. A user can teach the agent behavior that persists beyond that user’s authority. The same path exists through connectors, skills, hooks, and other shared configurations. The agent can’t be expected to remember which parts each user may influence.

The caller’s role must shape the environment before reasoning begins. Readers can observe but not drive the agent. Users can chat without modifying shared behavior. Operators can manage shared surfaces without approving high-privilege actions. Administrators can explicitly approve or delegate that authority.

These roles aren’t prompt instructions. They determine which tools and MCP servers are mounted, which resources the sandbox can reach, which memory is visible or writable, which credentials may be injected, and which actions require approval.

The rule is monotonic: the caller’s authority may be narrowed by the environment, but it must never be widened by the agent. A low-privilege request can’t be laundered through shared memory, a shared connector, an alternate tool path, or a high-privilege service identity.

The agent has nothing to borrow because there is no ambient authority outside the caller’s delegation chain. Rather than something the model remembers, policy is the environment instant for that user.

Autonomy through constraint

Model guardrails matter, but production safety can’t depend on them working every time. We already accept this with people: no one hands an operator root and promises to be careful. We give them scoped identities, just-in-time access, network boundaries, change control, and audit trails. Judgment is the first line of defense—never the only one.

Agents need the same backstops at a different cadence. An agent can make hundreds of tools calls in a single incident, replan between any two of them, and reach the same effect through three different tools. Approve every step and autonomy disappears; approve only the plan and everything after it runs unchecked. So, the question was never whether to keep policy gates. Instead, the question was where to put them: at runtime, as close as possible to each production effect, with human review reserved for the consequences the system can’t bound on its own.

That's what the four layers are: one move, repeated. We opened with the questions a shared agent forces: Who is asking? What authority do they carry? What can the environment reach? Where do the credentials live? Each layer answers one of those questions in the runtime instead of the prompt.

Across the four layers, the design principles are the same:

• Enforce constraints outside the agent’s access
• Prefer deterministic enforcement over model judgment
• Define invariants that hold even as architecture evolves

Where it still breaks

The system isn't complete, and we still discover gaps in our enforcement layers. Examples of gaps we closed recently: an action blocked through one tool could still be reached through a different execution channel that bypassed hooks. In another case, an MCP server could silently widen its contract after onboarding, and the protocol had no mechanism to detect the change.

As these gaps surface, we improve our implementation. But our security principles stay invariant:

Better models will make mistakes rarer. They won’t shrink the blast radius when a mistake still happens. A smarter model shifts where the line falls between autonomous action and human review—more actions cleared as low-risk, more investigations that run start to finish without a human in the chat. But that line is drawn by the controls, not by the model. What microVM can reach, where credentials live, whose authority a session carries.

Five questions for agent platform builders

The four incidents ultimately changed the questions we asked in review:

• Can the agent inspect, modify, or bypass the machinery that provisions its tools, identity, policy, or credentials?
• Can the same effect be reached through another tool or execution path that avoids the intended control?
• Through which paths can sensitive data enter the agent-controlled environment or leave the system?
• For every consequential effect, can the platform identify who asked, what it did, what it touched, what data it carried, what evidence supported it, and whose authority it ran under?
• When evidence is missing, stale, or ambiguous, does the operation reliably leave the autonomous path?

If the answer to any of those questions was “no,” we weren’t running a guarded agent. These are questions worth asking of any agent platform, including our own.

That’s what we mean when we say: The environment is the policy.

We also thank Zhenquan Xu, Hong Wang, Yefu Wang, and Eben Carek for their contributions to this work.