Microsoft Agent 365 and the cross-environment AI agent control gap

At a glance

What this is: This is an analysis of Microsoft Agent 365 as an identity control plane for AI agents, with the key finding that single-environment governance cannot cover enterprise agent sprawl.

Why it matters: IAM and NHI teams need cross-environment visibility because AI agents already operate across clouds, SaaS, code, and internal frameworks, which makes siloed controls incomplete.

👉 Read Entro Security's analysis of Microsoft Agent 365 and AI agent governance

Context

AI agent governance fails when teams treat agents like ordinary automations instead of non-human identities with permissions, secrets, and operational blast radius. In practice, the problem is not only access control inside one platform. It is the way agents move across Microsoft, AWS, GCP, SaaS tools, CI/CD systems, and internal frameworks, which turns fragmented identity handling into an NHI governance issue.

Microsoft Agent 365 reflects a broader shift toward identity-grade controls for agents, including lifecycle management, policy templates, and auditability. That is directionally useful for Microsoft-heavy environments, but the article’s core point is more important: enterprise AI risk is cross-environment by default, so any control plane that stops at one ecosystem leaves material blind spots. That starting position is common, and it matches the current shape of enterprise sprawl.

Key questions

Q: How should security teams govern AI agents that run across multiple environments?

A: Security teams should govern AI agents with a cross-environment inventory, consistent ownership, and revocation that reaches every cloud and SaaS dependency. A local control plane can reduce risk inside one stack, but it cannot replace enterprise discovery. The practical goal is to see every agent, its secrets, and its permissions in one operational model.

Q: Why do AI agents create a larger governance problem than normal service accounts?

A: AI agents are harder to govern because they act continuously, call multiple tools, and often inherit delegated access across systems. That expands identity blast radius and makes static IAM assumptions brittle. Teams need lifecycle controls, telemetry, and ownership mapping that follow the agent wherever it operates.

Q: What is the difference between local agent governance and enterprise agent governance?

A: Local agent governance controls identities and permissions inside one platform or cloud. Enterprise agent governance spans discovery, ownership, secrets, auditability, and revocation across all environments where the agent can run or call tools. The difference is scope, and scope determines whether the control is complete or partial.

Q: When does AI agent governance become an urgent security issue?

A: It becomes urgent when agents can access production systems, secrets, or customer data across more than one environment. At that point, a single missed permission or stale token can create broad blast radius. The safest approach is to treat agent governance as a live identity programme, not a one-time configuration.

Technical breakdown

Why agent IDs do not solve cross-environment identity sprawl

Agent IDs create a distinct identity record for an autonomous system, which is useful for lifecycle tracking, access assignment, and audit trails. The limitation is scope. If an agent authenticates in one cloud, reads secrets from another, invokes SaaS APIs, and triggers CI/CD workflows, then identity becomes a chain of trust across multiple control planes. The hard part is not issuing an ID. It is maintaining consistent ownership, entitlements, and revocation across every runtime and tool the agent can reach. That is why agent identity must be paired with discovery and lineage, not just registry functions.

Practical implication: inventory agent identities across all runtimes before treating any single registry as authoritative.

Policy templates and risk-adaptive access controls

Policy templates are prebuilt least-privilege patterns that constrain what an agent can do, while risk-adaptive controls change access decisions using behavioural or contextual signals. Together, they reduce static over-permissioning, but they do not remove the need to understand where credentials are stored, how tokens are reused, or which dependencies can silently expand access. For NHI governance, the important detail is that policy quality depends on visibility into the agent's real operating context. Without that, risk scoring can be accurate inside one platform and blind everywhere else.

Practical implication: tie policy templates to live entitlement data and secret inventory, not only to platform-local risk scores.

Unified auditability still depends on external telemetry

Full auditability means the organisation can reconstruct what an agent accessed, when it acted, and which decision path led to the action. That is stronger than basic logging, but only if the logs include interactions outside the host platform. If an agent's decisions are influenced by Slack, GitHub, a model endpoint, and a cloud API, then isolated audit trails miss the causal chain. The architectural lesson is simple: auditability for AI agents is a federation problem. Security teams need correlation across identity, secrets, data movement, and execution telemetry before they can trust the record.

Practical implication: build correlation across identity, secrets, and execution logs before relying on audit data for incident response.

Threat narrative

Attacker objective: The attacker seeks to abuse distributed agent trust to expand access beyond the original control plane and execute actions across multiple enterprise environments.

1. Entry occurs when an AI agent is granted access through a local identity model that does not account for its other cloud and SaaS dependencies.
2. Escalation follows when the agent's secrets, tokens, or delegated permissions are reused across multiple environments without central revocation control.
3. Impact emerges when the agent moves data or triggers actions across systems that the owning team cannot fully see or govern.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity controls for AI agents are necessary, but they are not sufficient when agents span multiple environments. The market is converging on the idea that agents need registries, lifecycle rules, and policy enforcement. That is useful, but NHI governance breaks down if ownership, revocation, and telemetry remain trapped inside a single platform. The practitioner conclusion is that agent identity must be governed as an enterprise fabric, not a cloud-local feature.

Cross-environment discovery is becoming the decisive control for agentic AI security. If teams cannot find every agent, they cannot explain its permissions, secrets, or behaviour. That is the same structural problem security teams faced with service accounts and secrets, only now the sprawl includes model endpoints, SaaS automations, and internal frameworks. The practitioner conclusion is that discovery must lead policy, not follow it.

Identity blast radius is the right lens for autonomous systems. Agents are not risky only because they exist. They are risky because each one can accumulate delegated power, reuse credentials, and act continuously without human supervision. A named control plane inside one ecosystem reduces local exposure, but it does not shrink the full blast radius unless the enterprise can correlate access across clouds and tools. The practitioner conclusion is to govern the blast radius, not the banner under which the agent runs.

Fragmented agent governance will repeat the secrets sprawl pattern. When every platform defines its own agent model, organisations inherit inconsistent policy, duplicate registries, and blind spots in revocation. That is a familiar failure mode in NHI management, and it becomes worse with AI agents because behaviour adds another layer of risk. The practitioner conclusion is to standardise ownership and lifecycle controls before the number of agent identities accelerates further.

Microsoft's direction validates identity-grade controls, but it also raises the bar for vendor-neutral governance. The category is moving away from treating agents as simple automations and toward treating them as accountable identities. That helps establish the right mental model, but it also means practitioners should re-evaluate whether their tooling can see beyond one ecosystem. The practitioner conclusion is to align governance architecture with enterprise reality, not platform boundaries.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That visibility gap is why teams should pair agent identity controls with NHI Lifecycle Management Guide discipline for discovery, rotation, and offboarding.

What this signals

The programme implication is straightforward. If agents can span clouds, SaaS, and internal automation, then a platform-local registry is only a partial control. The right operating model is to treat agent identity as an enterprise NHI problem and to align it with NIST Cybersecurity Framework 2.0 functions for identify, protect, detect, respond, and recover.

Identity blast radius: this is the control problem practitioners should track for autonomous systems. When an agent can accumulate delegated access across systems, the key question is not whether it has an ID, but how far that ID can reach before it is detected or revoked. Teams should measure blast radius as part of every agent review, not as an afterthought.

Because Top 10 NHI Issues includes visibility and lifecycle failures as recurring themes, the practical response is to unify discovery with offboarding and secret hygiene. Once agents exist in more than one environment, governance without correlation becomes an operational blind spot.

For practitioners

• Map every agent identity across environments Build a living inventory of agents in Microsoft, AWS, GCP, SaaS, CI/CD, and internal frameworks. Include owners, permissions, secrets, model endpoints, and runtime locations so the team can see where control is fragmented.
• Bind access policy to entitlement lineage Require each agent policy to reference the upstream human owner, the delegated workflow, and the credential chain that powers it. This prevents policy from becoming a local setting detached from real access paths.
• Correlate identity and secret telemetry Combine audit logs, token usage, and secret discovery into one monitoring view. That makes it possible to detect when an agent is acting outside its intended context or reusing credentials across systems.
• Standardise revocation and offboarding Define a single offboarding path for agent IDs, API keys, tokens, and certificates so disabling one platform does not leave another environment exposed. Treat revocation as a cross-system workflow, not a single click.

Key takeaways

• AI agents should be governed as non-human identities with real blast radius, not as background automation.
• Single-environment controls help, but they do not solve cross-cloud, SaaS, and CI/CD agent sprawl.
• Discovery, ownership, secrets, and revocation must be coordinated across the full enterprise stack.

Key terms

• Agent Identity: An agent identity is the distinct digital identity assigned to an autonomous software entity so it can authenticate, receive permissions, and be audited. In NHI programmes, it must be tied to ownership, lifecycle controls, and revocation across every environment the agent can reach.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is misused, compromised, or over-permissioned. For AI agents and other NHIs, the radius grows when credentials, tokens, and delegated access extend across clouds, SaaS tools, and internal systems.
• Cross-Environment Discovery: Cross-environment discovery is the process of finding NHIs, their credentials, and their access paths across multiple clouds, applications, and automation layers. It is the prerequisite for sane governance because teams cannot secure what they cannot see or connect to an owner.
• Agent Registry: An agent registry is a central catalog of sanctioned and shadow AI agents, including their identities, permissions, and lifecycle state. Its value depends on whether it feeds broader governance, because a registry without telemetry, ownership, and offboarding can become another silo.

What's in the full article

Entro Security's full blog post covers the operational detail this post intentionally leaves for the source:

• A closer breakdown of Microsoft Agent 365 capabilities such as Agent Registry, Agent ID, and policy templates.
• The vendor's recommended starting steps for mapping AI agents across Azure, AWS, GCP, SaaS, and internal frameworks.
• Its view of how cross-environment discovery, secrets visibility, and entitlement mapping fit together in practice.
• The specific platform framing Entro Security uses for unified agentic discovery and behavior monitoring.

👉 Entro Security's full post covers the cross-environment control gap and the operational details behind unified agent governance.

Deepen your knowledge

AI agent identity governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building controls across multiple clouds and SaaS platforms, this is a practical place to start.