Agent 365, Entra Agent ID, and Oasis: Completing the Picture for AI Agent Governance

Microsoft’s Agent 365 and Entra Agent ID have landed, and if you work in identity or security, you’re probably already hearing some version of the same question:
“Can we just use Agent 365 to fully manage all of our agents and their access? And if not, what’s still missing to safely roll out agents at scale?”

This post is meant to be a straight answer for practitioners:

• What Agent 365 and Entra Agent ID actually do
• Where they’re less focused today
• How Oasis completes the picture across your hybrid environment
• Why organizations will need both

Along the way, we’ll keep coming back to the core idea:

Agent 365 shows you who your agents are. Oasis governs them and controls how they act and what they can do — across Microsoft and every other platform.

‍

What Agent 365 and Entra Agent ID bring to the table

Microsoft’s positioning is clear: Agent 365 is “the control plane for AI agents,” built on top of Microsoft 365 and Entra. It’s how you register, observe, and put guardrails around agents in the Microsoft ecosystem.

Two pieces matter most for security and IAM teams.

‍

Entra Agent ID: agents as first-class identities

Entra Agent ID gives each AI agent its own identity object in Entra:

• Agents created in Copilot Studio and Azure AI Foundry are automatically assigned an Agent ID in Entra, with no extra work for developers.
• Those identities live alongside users, apps, and service principals, so you can apply familiar controls: Conditional Access, group/role assignments, and lifecycle operations.

That’s a big step up from agents reusing human accounts or generic app identities with unclear ownership.

‍

Agent 365: the management and observability layer

On top of Entra Agent ID, Agent 365 adds a management and observability layer:

• An agent registry that inventories agents, their owners, and relationships to people and data
• Dashboards and telemetry to track how agents behave and where they’re connected
• Policy hooks back into Entra and the broader Microsoft security stack to enforce guardrails and block misbehaving agents

As Microsoft weaves Agent 365 more tightly into the Microsoft 365 and Entra ecosystem (including E5-centric stories), most organizations will naturally want to turn it on where it’s available. And they should: for Microsoft-centric agents, it’s the right foundation.

The immediate following question that arises, especially in a hybrid, multi-cloud environment, is:

“What does Agent 365 handle well, and what do we still need to solve?”

‍

Where practitioners still need more than Agent 365

Agent 365 and Entra Agent ID are doing important work: bringing agent identity and governance into the same world you already use for people and apps.

At the same time, there are a few areas where practitioners are still looking for more depth and coverage.

‍

1. Lifecycle doesn’t fully extend to other identities and secrets

Agent 365 and Entra Agent ID give you a clean story inside Microsoft:

• Agents are backed by managed identities and Entra permissions.
• You can apply Conditional Access and lifecycle policies the same way you do for other Entra objects.

But an agent rarely lives entirely inside that boundary. In practice, an agent often sits “on top of” a set of other identities and access paths, especially once it starts integrating across your hybrid environment:

• API keys for internal services
• OAuth grants into SaaS tools
• Service accounts and roles in other clouds
• Credentials living in one or more vaults
  

Agent 365 and Entra Agent ID help you manage the agent identity itself. They don’t automatically discover, classify, or govern all of those downstream identities and secrets that agents rely on outside the Microsoft estate.

So you can end up with:

• A well-governed Entra Agent ID, plus
• A collection of long-lived keys, tokens, and accounts elsewhere that are still provisioned, rotated, and decommissioned by hand
  

Those are exactly the areas where non-human identity (NHI) sprawl and static secrets have already been causing problems — and they don’t go away just because the top-level agent now has an Agent ID.

‍

2. Usage mapping is still hard to make operational

Agent 365 takes a big step forward in agent observability:

• It shows which agents exist and who owns them.
• It visualizes connections between agents, people, and data inside Microsoft 365.
  

That’s valuable - but for teams that need to make decisions based on usage, there are a couple of practical challenges:

• Understanding where, exactly, an agent is used and what it can touch can still be complex, especially as agents chain together tools and workflows.
• Ownership and sponsorship assignments are encouraged, but today they still lean on fairly simple heuristics and manual admin configuration — which can lag behind reality when agents are new or heavily shared.
• Once an agent calls out into other platforms (cloud data, SaaS, internal APIs), you lose a lot of the detail about how that external usage ties back to identities and policies.
  

In other words: Agent 365 gives you a strong view of activity in and around Microsoft 365, but mapping usage all the way out into the rest of your hybrid environment — and tying that back to underlying identities and secrets — still takes additional tooling and effort.

‍

3. Cross-ecosystem coverage is uneven by design

Microsoft’s stated direction is encouraging: Agent 365 is open by design and supports agents from third-party ecosystems like Adobe, Nvidia, ServiceNow, and Workday.

But today, there’s an important nuance:

• Agents built on Copilot, Copilot Studio, Azure AI Foundry, and Microsoft 365 get the deepest, most automatic integration with Entra Agent ID and the Agent 365 registry.
• Agents anchored in other ecosystems — OpenAI / ChatGPT, Anthropic, AWS, GCP, Snowflake, Databricks, independent agent frameworks — typically show up through integrations and manual registration, not automatic discovery.
  

Microsoft is clearly investing in an integration ecosystem, and that will improve over time. But even in a world where every major platform exposes its agents to Agent 365, you’re still dealing with:

• Multiple control planes and identity providers
• Different ways of expressing policy and access
• Different patterns for secrets and non-human identities
  

That’s not a Microsoft problem; it’s just the reality of a hybrid environment. Agent 365 can be a central lens, but it can’t magically normalize everything across all providers on its own.

‍

4. Access is identity-level, not per-session and intent-aware

Finally, there’s the question of how tightly you can scope access for agents.

With Agent 365 and Entra Agent ID:

• Agents get Entra identities, roles, and app permissions.
• You can wrap those with Conditional Access and other policies.

That gives you better control than opaque tokens, but the model is still mostly identity-centric:

• If an agent has a given role or privilege, it effectively has that capability for as long as the grant exists.
• You can decide whether the agent should have Snowflake or Databricks access, for example, but not easily say:
  
  • “Only allow read-only queries for this specific project, during this specific workflow, and then remove the access immediately.”
    

Especially once you step out into non-Microsoft systems, this often becomes an all-or-nothing decision per integration: either wire up the agent to a tool with a broad credential, or don’t connect it at all.

What’s missing is a way to say:

“For this particular request, from this human, through this agent, in this context — here’s the minimum access we’re willing to grant as a short-lived session, and nothing more.”

That’s what we built Agentic Access Management (AAM™) to handle.

‍

How Oasis completes the picture across your hybrid environment

Oasis assumes you’re going to use Agent 365 and Entra Agent ID where you have Microsoft agents. That’s the right move.

We focus on going further:

• Ingesting context from Agent 365 and Entra Agent ID
• Layering context and non-human identity management and governance across your hybrid environment
• And layering Agentic Access Management on top, so every agent interaction becomes a controlled, just-in-time session rather than a standing grant

‍

1. Use Agent 365 as the “who” — Oasis brings the full context

In most environments, the pattern looks like:

• Agent 365 + Entra Agent ID act as the catalog and identity source for Microsoft-anchored agents.
• Oasis ingests that catalog and joins it with signals from the rest of your environment — cloud providers, SaaS, CI/CD, vaults, and other agent frameworks.

So when you look at an agent in Oasis, you don’t just see “Agent ID X in Entra.” You see:

• The human and team that own it
• The non-human identities and secrets it relies on across your hybrid environment
• The systems and data it actually touches
  

Agent 365 tells you who the agent is. Oasis shows you what that identity resolves to in terms of real access paths.

‍

2. Govern non-human identities and secrets end-to-end

Oasis’ core is NHI governance: discovering, provisioning, and managing non-human identities across clouds, SaaS, and on-prem from day one.  

That includes:

• Automatically discovering service accounts, roles, API keys, and tokens across providers
• Assigning ownership and purpose so identities aren’t orphaned
• Enforcing policies for rotation, decommissioning, and least privilege
• Supporting both credential-based and federated identities, depending on what a given system supports
  

When those identities sit under agents, you get a unified view:

• Which agents are using which NHIs and secrets
• Where static or long-lived credentials are still in play
• Where access is over-privileged relative to what the agent is supposed to do
  

That’s the governance layer Agent 365 doesn’t try to own — especially once you step beyond Microsoft.

‍

3. Add Agentic Access Management: per-session, intent-aware access

On top of that foundation, Oasis Agentic Access Management (AAM™) addresses the session-level gap:

• AAM is an intent-aware, policy-driven identity infrastructure that sits between your agents and the systems they touch across the hybrid environment.
  
• Every agent interaction becomes a short-lived, least-privilege session rather than a standing credential or broad role.
  

Concretely, AAM:

1. Understands intent: Translates prompts, tool calls, or plans into structured intent: resource, operation, scope, purpose.‍

2. Evaluates that intent against policy

• ‍‍Policies express what your organization is actually comfortable with, e.g.:
  
  • “Agents in this group can only read production data.”
  • “Write operations in CRMs require escalation.”
  • “Agents cannot move sensitive data into unsanctioned SaaS.”
    

3. Issues just-in-time, ephemeral identities‍

• If allowed, AAM provisions a short-lived identity scoped only to that specific action or workflow.
• These identities have no standing privileges, no long-lived secrets, and are automatically decommissioned when the task ends.
  

4. Provides full auditability: Every session produces a chain of custody: Human → Agent (including Entra Agent ID) → Prompt → Intent → Policy → Identity → Actions → Results.

The effect is that access decisions are no longer “all or nothing” at the identity or integration level. Instead, each agent request gets the minimum required access, for the shortest possible time, across your hybrid environment.

‍

Bottom line: why organizations need both

For most organizations, the path forward is “better together,” not either/or:

• Agent 365 + Entra Agent ID
  
  • Make agents first-class identities in Entra.
    
  • Give you a strong registry, observability, and policy surface for Microsoft-anchored agents.
    
  • Are already included in, or closely aligned with, investments you’re making in Microsoft 365 and Entra — so you should absolutely use them wherever you can.
    
    
• Oasis NHI governance + Oasis AAM™
  
  • Extend that picture across the entire hybrid environment — cloud, SaaS, and on-prem — by governing the non-human identities and secrets agents rely on.
    
  • Turn agent usage into something you can reason about end-to-end, not just inside Microsoft.
    
  • Add intent-aware, per-session access, so each agent action has a tightly scoped, short-lived session instead of a broad, long-lived grant.
    

Even if your initial AI deployment is “Microsoft-only” — Copilot Studio, Foundry, Microsoft 365 agents — you still face the same core challenges:

• Non-human identity lifecycle and secret governance
  
• Clear, operational usage mapping
  
• Per-session control over what agents can actually do
  

Agent 365 moves you closer to those goals inside Microsoft. Oasis is how you carry them through across your entire hybrid environment.

Or, in one line you can use with your stakeholders:

Agent 365 shows you who your agents are. Oasis governs them and controls how they act and what they can do — across Microsoft and every other platform.