Agent 365: Air Traffic Control for Your Runaway AI Agents

When Agents Start Behaving Badly

This was a tech talk with a heavy emphasis on live demos. The presenter opened with "agents behaving badly" as his hook — exposing a truth many organizations have yet to confront: as AI agents proliferate inside enterprises, governance is becoming a harder problem than building the agents themselves.

He set the stage with a real-world story from the Power Platform era: after a large automotive manufacturer enabled the COE Toolkit, they discovered roughly 250,000 unmanaged automation flows. Everyone's reaction was a single expletive. But agents carry even greater risk than automation did back then, for one critical reason: agents are generative. Apps and automations don't spontaneously produce large volumes of new data — agents do. And once bad data enters the ecosystem, they generate more bad data and misinformation, spreading it through the organization like a swarm of digital minions.

From Single Cells to "Agent Mesh": How Risk Compounds

The presenter walked through the evolution of agent architectures — a genuinely valuable piece of analysis.

Single-Cell Ecosystem: Easy to Test, Risk Contained

In the early days, it was Bob in Accounting and Susan in Customer Service each building their own standalone RAG (Retrieval-Augmented Generation) agents connected to SharePoint to return information. Testing was simple — give it a prompt, see if the output is good. Memory capabilities came next; Copilot Studio allows agents to be enabled with memory so they can learn from a user's behavior patterns.

RAG (Retrieval-Augmented Generation) is the most common underlying architecture for enterprise agents today. The core idea: before querying a large language model (LLM), first retrieve relevant content from an external knowledge base (such as SharePoint, a database, or a document library), then send both the retrieved content and the original question to the model to generate an answer. This approach sidesteps the LLM's knowledge cutoff problem, allowing the model to "access" real-time or proprietary data without the prohibitive cost of baking all enterprise data into model training. In low-code platforms like Copilot Studio, RAG capabilities are typically surfaced as "knowledge sources" or "connectors," so developers can use them without needing to understand vector databases or embedding models. But that ease of use introduces a hidden risk — builders often overlook the foundational assumption that the retrieved data source must itself be trustworthy. If a knowledge source is poisoned, the RAG mechanism will output misinformation dressed up as an authoritative answer.

Child Agents and Hierarchical Structures

Next came the concept of "child agents" forming an agent hierarchy — analogous to sub-flows in the automation era, with a primary orchestrator agent directing a fleet of digital minions. Testing complexity increased, but risk remained localized: the only real point of failure was the orchestrator, and bad data couldn't spread widely.

Agent Mesh: A Breeding Ground for Chaos

The real inflection point is the agent mesh — multiple agents interconnected with one another. The presenter offered a vivid analogy: you high-five the person in front of you, and they might pass it along to two more people, or they might decide they'd rather go hug someone instead. Agents behave the same way — their actions depend entirely on their instructions and the data they rely on. If you build a rogue agent and release it into a larger ecosystem, it can silently infect other systems without you ever knowing.

Live Demo Gone Wrong: The Hidden Permissions of a "Beer Pong" Agent

The most striking moment of the entire talk was a live demo where the presenter invited audience members to cause havoc from their phones in real time.

He had set up a seemingly harmless "beer pong agent" that appeared to only offer party-planning advice. But when an audience member — without authenticating — asked it to "email me the list of contacts and accounts from Dataverse," the agent dutifully returned 22 records, with the option to export as CSV or Excel.

The key mechanism: the presenter had enabled maker-provided credentials in the agent. This meant every anonymous user's actions were actually executed under his own identity. The audience thought they were accessing the agent anonymously — in reality, they were implicitly connected to the organization's core data.

The demo went even further: an audience member named "Joe," who had no affiliation with the company, used the anonymous agent to create random calendar appointments directly in the presenter's Outlook. Even more alarming, this was underpinned by three interconnected agents:

• Beer Pong Agent: The public-facing front end, connected to weather forecast skills and the open internet
• Meeting Agent: Manages and modifies calendar meetings, connected to Calendar MCP
• Dataverse "God Mode" Agent: Has permissions to create tables, delete records, and access arbitrary data

In other words, a single toggle — maker-provided credentials — was all it took to give anonymous visitors access to core enterprise data (Dataverse, Fabric, SQL, and more). The presenter repeated the point: in most cases, people aren't malicious — they simply have no idea what they're doing. This is an education problem, not a bad-actor problem.

Maker-provided credentials is an authentication mode option for connectors in Copilot Studio. Within Power Platform's connector framework, calling external services (such as Microsoft Graph, Dataverse, or Exchange) requires a pre-authenticated "connection." There are typically three authentication modes: requiring each end user to log in with their own account (User credentials), having the agent builder supply a fixed service account whose credentials are shared by all users (Maker-provided credentials), or allowing fully anonymous access. When "Maker-provided credentials" is selected, all API calls made through that agent appear to originate from the same account — the person who built the agent. This mode is genuinely convenient for quickly delivering services to anonymous users, but the cost is significant: every permission the builder's account holds is silently extended to every anonymous visitor, with none of this being visible to users through the chat interface.

Agent 365: The Control Plane for Your Agents

To address this chaos, the presenter introduced Microsoft's answer: Agent 365, positioned as the enterprise "control plane" for managing AI agents.

He described it as a cake made from multiple ingredients in the Microsoft stack:

• Defender: Provides the threat management layer, preventing agents from performing dangerous operations like a malicious actor
• Entra: Every agent gets its own digital identity and unique ID in Entra, enabling conditional access policies and security controls
• Purview: Handles compliance and policy management, data governance, and insider threat detection

He named a real pain point: compliance staff won't go into Defender, security staff won't touch Purview, but almost everyone ends up in Entra. What's needed is a unified control plane that layers all these capabilities together — and that's what Agent 365 is for. It revolves around three things: observation, governance, and security.

Control Plane is a concept borrowed from cloud computing and network engineering, contrasted with the "Data Plane." The data plane handles the actual transmission and processing of traffic; the control plane defines rules, pushes policies, monitors state, and coordinates scheduling. In container orchestration systems like Kubernetes, the control plane decides where workloads run and how they scale; in SD-WAN, the control plane centrally manages routing policy. Applying this concept to Agent 365 is intentional: the distributed agents scattered across an enterprise (the data plane) need a separate management layer that centrally defines what agents can and cannot do — rather than leaving each builder to configure permissions and behavior locally. The benefit of this architectural separation is that when governance policies change, you don't need to modify every agent individually; an update to the control plane takes effect globally.

Agent Governance in a Single Portal

Agent 365's core value is consolidating governance work that was previously scattered across the Power Platform Admin Center, Foundry control plane, Entra, and other locations — all into a single portal.

Its agent registry is a single pane of glass for viewing all agents across the ecosystem. The presenter specifically noted that it can even connect to agents on third-party platforms like Amazon Bedrock and Google — making it one of the few control planes with genuine cross-ecosystem reach.

Key metrics to watch on the dashboard:

• Agents at risk: The "bad kids" misbehaving in production
• Anomalous agents: Those that have had incidents but went unobserved
• Agents without owners: A classic governance red flag
• Cost estimates: Tracking the value and spend associated with agents
• Pending requests: Agent publishing requires going through an approval workflow

Going deeper is the agentic map, which gives you a visual representation of how agents interconnect with each other and with tools. The presenter highlighted a key concept here — blast radius: a "case enrichment agent" flagged with a high blast radius means that if it goes wrong, it will cascade into other agents and data structures. Orchestrator agents with privileged data access are similarly highlighted.

Circling back to the live demo: once real-time threat detection synced up, all three agents the audience had accessed were flagged as high-risk by Defender and surfaced through the Agent 365 layer. As the "agent operations manager," the presenter could manually block them — or pre-configure rules to automatically intercept them.

Blast Radius originates from security engineering and failure analysis, describing the scope of systems that can be affected if a single point fails or is compromised. In microservices and cloud architecture design, minimizing blast radius is a core resilience principle — achieved through least-privilege access, network isolation, rate limiting, and circuit breakers, ensuring that even if one component fails, the impact stays localized. In an agent mesh context, a high-blast-radius agent is one that has call relationships with many other agents and holds write access to a wide range of data or services. If such an agent is hit with a prompt injection attack or misconfigured to behave abnormally, errors propagate rapidly along the call chain, potentially triggering cascading data corruption, privilege abuse, or service outages. Nodes with high blast radius in the agentic map should therefore be prioritized for manual review and automatic interception policies.

Closing: Governance Is Non-Negotiable in the Agent Era

The central argument of this talk was clear and compelling: in a world where generative agents are being deployed at scale, the consequences of ungoverned chaos can be catastrophic. A single forgotten credential toggle, one "god mode" agent exposed to the public internet — that's all it takes to throw the doors open to core enterprise data.

The presenter's practical advice: engage with the Agent 365 learning path early, start a trial, and understand how it operates across the entire ecosystem. Just as the COE Toolkit once revealed 250,000 out-of-control automations, the agent era needs a control plane that can "illuminate everything" — because without one, you'll never know how many digital minions are out there acting in your name.