Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
147506 stories
·
33 followers

Microsoft Entra Agent ID explained

1 Share

See every agent in one place, understand what it can access, detect agent sprawl early, and apply least-privilege permissions using the same Microsoft Entra tools you already use for users — without introducing new governance models.

Approve and scope agent access with accountability, enforce agent-specific Conditional Access in real time, automatically block risky behavior, and ensure every agent always has an owner, even as people change roles or leave.

Leandro Iwase, Microsoft Entra Senior Product Manager shows how to keep agents operating securely, transparently, and predictably across their entire lifecycle.

AI agents get real identities.

See how to apply permissions, protections, and policies. Treat agents like human users with Microsoft Entra Agent ID.

Gain full visibility for each agent in your tenant.

See how many agents exist, which are active or unmanaged, and where sprawl is starting — before it becomes a risk. Check out Microsoft Entra Agent ID.

Control what agents can access in real time.

Apply Conditional Access policies directly to agents using Microsoft Entra Agent ID. Start here.

QUICK LINKS:

00:00 — Treat AI Agents Like Real Identities

00:42 — Stop Agent Sprawl

02:26 — Least Privilege with Agent Blueprints

03:39 — Scope Agent Access

05:10 — Create agent specific Conditional Access policies

06:12 — Protect against a sponsor account

07:01 — Agents flagged as risky

07:50 — Ownerless agents

09:00 — Wrap up

Link References

Check out https://aka.ms/EntraAgentID

Unfamiliar with Microsoft Mechanics?

As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.

Keep getting this insider knowledge, join us on social:


Video Transcript:

-As more AI agents become active in your environment, you need control over them and what they can access. That’s where Microsoft Entra Agent ID comes in. It lets you treat agents like you would treat human users with their own built-in identities. Agent ID lets you define permissions and extend new and existing protections to them. You stay in control across their entire life cycle, from initial creation to monitoring the day-to-day activities where we continuously check for risk and protect access to resources, to switching their ownership if their sponsors no longer around, and disabling them when they’re no longer needed. The good news is that you can use the same tools in Microsoft Entra that they use to manage human identities today. Let me show you. Here in the Entra Domain Center, you see a new type under Entra ID called Agent ID. In the overview, you’ll find a summary with key metrics. These insights highlight what you need to know about your agents.

-For example, how many agents are in your tenant, the number of agents recently created, how many are active or unmanaged and without identities. Each are starting point for understanding agent activity and spotting early signs of agent sprawl. Moving to the agent registry, you get visibility for each agent in your tenant and what platform they were built on and whether they have an Agent ID or not. The agents here are mixture of Microsoft-built agents, agents that you built in Microsoft Foundry, Copilot Studio, as well as Security Copilot. And no Microsoft agents using APIs and SDK supporting Agent ID. In fact, Agent Registry in Microsoft Entra is a shared center registry also used by the Agent 365 control plane. Next, in our agent identities, we can see all AI agents with an agent ID. Here, each agent automatically gets identity record, which is immutable object ID, just like a user or app registration would. It can quickly filter the list of the agents I want to manage. And by clicking into an agent like this one for HR self-service, we can see each details like the agent status, sponsor, permissions, roles, and associated policies.

-Then, agent blueprints are templates for how agent identities are created. They ensure that any agent created has the right controls and is aligned with organizational policies. In the blueprint, we can see that it has one linked agent identity, which is actually itself. That said, this blueprint could be used for other agents as they are created. In fact, let me show you how this works with a blueprint that has more linked agent IDs. Back in our agent identities view, I’ll take a look at this HR Test agent to verify its agent blueprint. Here’s one has two linked agent identities. One has been named an Actor agent and is active. I’ll click into its access details. Here, I can see the details for each permissions. It has Application.ReadWrite.All permissions in the Microsoft Graph, which means it’s over permission, so it’s potentially dangerous. If I go back to the agent page, I can disable this agent. And if I confirm, this will block the agent to improve security and prevent and authorize access to it. So as an administrator, you have full visibility into your agent details and their correspondent permissions for accessing your resources.

-Next, for scoping access to just what an agent needs to perform his tasks, we use access packages in Microsoft Entra. Let me show you. We start under Identity Governance, from Entitlement management and Access packages. You can see that I’ve already got one for a sponsor-initiated access package created. This includes the resources to help automate HR-related tasks for our agents. In Resource roles, you can see the specific Microsoft Graph API-related roles. Under Policies, that is just one initial policy. And clicking into it, we can see who can request access. I can choose from Admin, Self, Agent Sponsor, or Owner.

-Importantly, these access package requires agent sponsor to approve any agent requests for access and it requires a business justification as well. Let me show you how the access request process works. I’m logged in as a human agent sponsor with the My Access portal open. I’ll browse Available access package. And here, the Sponsor-Initiated Agent Access package that we saw before. Clicking to exposes which identity I’m requesting access for, and I’ll keep the Sponsor agent option, and I’ll choose our HR Actions Agent. Next, I just need to enter a business justification. I’ll enter Timebound access for HR agents, then submit the request. Once the request has been approved, the agent will work according to my policies. And now, I can even create specific conditional access policies that will assess this realtime as agents try to access resources.

-Here, I’ve created a Conditional Access policy to prevent agents from requesting sensitive information. In Assignments, there is now an option to apply the policy to agents. Under Grant, you see that this policy blocks all access requests by default, and you can see all agent identities are in scope. In my case, I want to make one exception. I want to make sure only approve HR agents can access HR information and stop our other agents. We can do that using an exclusion for HR-approved agents. Back in my policy, if I move over to Exclude, I can exclude one or more agent IDs from the policy. Using filter rules, this is how I can only allow the agents that were approved by HR to get access to dedicated HR resources, as you can see here. Under Target resources and in the filter, you also see that this policy covers all resources. So that was a very target Conditional Access policy.

-We can also apply broader policies for all agents at risk to protect against a sponsor accounting being compromised and giving the agent malicious instructions. I move over to another Conditional Access policy that I’ve started. Just notice the identities in scope are, again, all agents. Target resources are all resources. But under Conditions, there is a new one called Agent risk. And when I’m look at what’s configured, you see the now we have High, Medium, and Low risk level options. I’ve chosen High. And once that’s enabled, condition access, you assess agent risk in realtime based on its likelihood of compromise and automatically block access to any resource per this policy scope.

-Now, we’ve protected from risk agents when they request access to resources. And from Microsoft Entra, you can see which agents are currently flagged as risky in your tenant. Right from Identity Protection, you find your risky agents. So let’s take a look. We have three of them here. Our HR Actor agent from before shows high risk. By clicking in, you can see why. It looks like this agent tried to access resources that it does not usually access. Remember, this policy was a scoped to all agents without any exclusions, so if you block our HR agents too in case high risk is detected. So now our agents are running with their own identities and our resources are protected.

-Since agents have one or more human sponsor, let’s move on to what happens if a sponsor leaves or change roles and makes the agent ownerless. For that, using lifecycle workflows, we can automatically notify the right people when agents become ownerless. Work workflows are a great way to automate routine tasks like employee onboarding and offboarding, and they work for agents too. I will narrow my list down by searching for a sponsor. There’s my workflow for AI agents to configure their sponsor in the event of a job profile change. Drilling into the workflow and then into its tasks, you see that we have two tasks defined for the what happens when the job profile changes. The first is an email to notify the manager of the user move, and I’ll click into the second task, which sends an email to the manager to notify them about agent identity sponsorship change they will need to action.

-Let me show you an example when an agent sponsor leaves their role. Here, we’re seeing the manager’s mobile device. There’s a come in for an Outlook. And when we open it, in the mail, we can see that the manager needs to identify a sponsor for the two HR agents listed. This way, you can ensure the agents always have assigned sponsors.

-Microsoft Entra Agent ID provides comprehensive identity, access, and lifecycle management for agents, with the same familiar tools you leverage already for users. To learn more, checkout aka.ms/EntraAgentID. Keep checking back to Microsoft Mechanics for the latest tech updates, and thanks for watching.

 

Read the whole story
alvinashcraft
just a second ago
reply
Pennsylvania, USA
Share this story
Delete

Release Announcement of SQL Server Migration Assistant (SSMA) v10.5

1 Share

We’re pleased to announce the release of SQL Server Migration Assistant (SSMA) v10.5, delivering meaningful improvements across multiple flavours of SSMA to further simplify and de‑risk database modernization to Azure SQL and SQL Server.

This release focuses on expanding AI-assisted code conversion, improving conversion quality and reliability, and addressing key customer feedback from real-world large-scale modernization projects.

Here is a high-level overview of the features shipped as part of SSMA:

Introducing AI‑assisted Code Conversion with Microsoft Copilot in SSMA for SAP ASE

(SSMA for SAP ASE)

SSMA v10.5 introduces AI-assisted code conversion powered by Microsoft Copilot for SAP ASE (Sybase)—bringing the same modern Copilot experience already available in SSMA for Oracle to Sybase migrations.

With this capability, customers can now use Copilot to accelerate conversion of complex Sybase T‑SQL objects like procedures, functions, triggers, and other database objects to SQL Server and Azure SQL–compatible code.

Key highlights

  • AI-assisted modernization: Copilot helps generate higher-quality converted code, reducing manual remediation effort. The conversion efficiency improves by ~30% using Copilot.
  • Designed for complex workloads: Particularly useful for large, business-critical Sybase ASE applications. During migration, these complex workloads often face a huge number of errors which can be dealt using Copilot.
  • Consistent Copilot experience: The Sybase Copilot workflow mirrors the Oracle-to-SQL Copilot experience, ensuring a familiar and intuitive user flow.

Please find a link to the detailed blog covering supported scenarios, and best practices for using SSMA Sybase Copilot.

Improved Code Conversion Quality for Oracle with Support for Larger Source Scripts

(SSMA for Oracle)

In SSMA v10.5, the Oracle PL/SQL to T‑SQL Code Conversion Copilot has been enhanced to support larger source scripts, enabling customers to convert more complex and sizable PL/SQL packages with improved reliability. We have doubled the size of the input tokens to accommodate larger code. We have also significantly increased the limit of output tokens for accurate explanations.

These enhancements help reduce the need to manually split large scripts and improve end-to-end conversion efficiency for enterprise-scale Oracle workloads.

Improved Reliability of Oracle PL/SQL Conversions on Azure SQL Managed Instance

(SSMA for Oracle)

SSMA 10.5 improves the reliability of running Oracle PL/SQL–to–T‑SQL converted procedures on Azure SQL Managed Instance by updating the SSMA for Oracle extension components used to support Oracle compatibility behaviors (for example, autonomous transaction patterns).

These updates strengthen connection handling to align with newer security and encryption defaults in the target environment, helping reduce runtime connection interruptions during procedure execution.

The improvements are included as part of SSMA 10.5, so customers can benefit without requiring manual workarounds or additional configuration changes.

Additional Fixes and Improvements

SSMA v10.5 also includes several smaller but impactful fixes across flavors:

  • SSMA for Access: Improved reliability of Windows login resolution during migrations.
  • General stability and usability improvements across assessment and conversion workflows.

Download SSMA v10.5

Get the latest versions of SQL Server Migration Assistant v10.5:

Read the whole story
alvinashcraft
12 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

AI for Communicators celebrates SharePoint’s 25th

1 Share

We’re excited to bring a very special First Fridays on March 6th from 8-9 PT. SharePoint is celebrating its 25th anniversary and we are bringing some of the latest announcements for communicators. In March we’ll be joined by Sarah Mathurin, principal product manager and Nancy Handa sr. product manager in SharePoint engineering.

 

 

Join us for a forward‑looking conversation on how communications work is evolving, and how SharePoint is helping teams navigate what’s next.

Register at aka.ms/FirstFridaysMarch

This session is for communicators, marketers, and internal comms teams who are thinking about scale, clarity, and impact as work grows more complex and fast‑moving.

If you’re eager to hear the latest on announcement day, be sure to tune in on March 2nd for the SharePoint at 25 birthday event- and get a first look of what's next-aka.ms/SPat25

Read the whole story
alvinashcraft
37 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Handling Legacy User Settings in SharePoint Framework

1 Share

Introduction

The SharePoint Framework (SPFx) has undergone some important changes in how it handles Entra ID app registration and security models. Here you can find additional details about what was updated and about the new application IDs used by SPFx. These changes have important implications for developers who previously relied on legacy user settings stored through the old application registration model. This article explores the technical challenges and provides practical solutions for handling legacy user settings when transitioning to the new SharePoint Framework security architecture.

Understanding the SharePoint Framework Security Model Evolution

The Legacy Application Model

Previously, SharePoint Framework utilized an application called SharePoint Online Client Extensibility Web Application Principal. This application had several key characteristics:

  • Tenant-specific registration: The application was automatically created in each customer tenant when they began using SharePoint Framework with permission scopes.
  • Third-party application model: It was registered as a standard third-party application in every individual tenant.
  • Token management: It served as the foundation for client-side token acquisition in SharePoint Framework to access Microsoft Graph and other Entra ID-secured APIs.

The New Multi-Tenant Application Model

Starting from March 2025, Microsoft introduced a new application called SharePoint Online Web Client Extensibility with the following improvements:

  • First-party multi-tenant application: Provided and managed by Microsoft across all tenants.
  • Centralized management: Single application shared across all Microsoft 365 tenants.
  • Automatic permission migration: All previously granted permissions were automatically copied from the old application to the new one.

Benefits of the New Model

The transition to the new security model brings several advantages.

Performance Improvements

  • Faster token acquisition: Single application enables quicker token retrieval.
  • Shared token cache: Tokens are shared across first-party and third-party applications.
  • Reduced latency: Streamlined authentication flow.

Enhanced Reliability and Governance

  • Microsoft-managed infrastructure: Reduced dependency on tenant-specific configurations.
  • Pre-authorized permissions: Set of permissions pre-configured by Microsoft.
  • Administrative flexibility: Administrators can modify pre-authorized permissions based on organizational needs.
  • Risk management: Changes to pre-authorized permissions are at the administrator’s discretion.

Important Note: Modifying pre-authorized permissions may break out-of-the-box functionality. Administrators should carefully evaluate the impact before making changes.

Permission Scope Considerations

When transitioning to the new application, all previously granted permissions have been automatically copied over which means that the existing SharePoint Framework applications continue to work without any required changes.

Also .Selected permissions were copied. However, the specific resource assignments were not transferred. As such, the migration provides an excellent opportunity for:

  • Security audit: Review all existing SharePoint Framework permissions.
  • Permission cleanup: Remove unnecessary or outdated permission grants.
  • Compliance alignment: Ensure permissions align with current security policies.

The Challenge of Application ID Migration

Despite all the above benefits of the new security architecture, there is a fundamental challenge that arises from the changes. In fact, each application registration has a unique client ID and the legacy third-party has a client ID different from the one of the new first-party application:

  • Legacy Application: SharePoint Online Client Extensibility Web Application Principal (unique client ID for each different tenant).
  • New Application: SharePoint Online Web Client Extensibility (new client ID equal for all the tenants).

While most SharePoint Framework solutions rely on the platform’s built-in token management and won’t be affected, there is a specific scenario affected: the storage and retrieval of user settings using Microsoft Graph’s special folders functionality. In fact, the AppRoot special folder of the legacy application is different from the one of the new application and any existing files were not copied over.

Understanding Microsoft Graph Special Folders Challenge

When it comes to user’s settings stored in Microsoft Graph’s special folder, you can rely on specific techniques to mitigate the impact of the changes. In the remainder part of this article you can see the suggested options. There is also a companion sample available on the Community Sample Solution Gallery.

You can simply download the source code of the sample and then follow the remainder part of this article to understand how it works.

The AppRoot Special Folder

Microsoft Graph provides access to special folders, including the AppRoot special folder, which offers:

  • Per-user, per-application storage: Each user gets a dedicated folder for each application.
  • Application isolation: Settings stored by one application are isolated from others.
  • Client ID binding: The folder is uniquely identified by the application’s client ID.

API Endpoint Structure

The AppRoot special folder can be accessed through the following Microsoft Graph endpoint:

GET /me/drive/special/approot

To access specific application folders:

GET /me/drive/root/apps/{applicationName}

The Legacy Settings Challenge

Since the AppRoot folder is bound to the application client ID:

  • Legacy settings location: /me/drive/root/apps/SharePoint Online Client Extensibility Web Application Principal
  • New settings location: /me/drive/root/apps/SharePoint Online Web Client Extensibility

Settings stored in the old application folder are not automatically accessible through the new application context. Microsoft did not migrate those files from the legacy application AppRoot folder to the new one. Consequently, SharePoint Framework solutions relying on AppRoot folder need to handle both the legacy and the new folder and potentially migrate content from the legacy folder to the new one.

Technical Solution Implementation

Solution Architecture Overview

The recommended approach to handle legacy user settings involves:

  1. Direct Graph API access: Use Microsoft Graph to access the old AppRoot folder.
  2. User-context authentication: Leverage user permissions to access their legacy settings.
  3. Data migration or dual-access pattern: Choose between copying settings or maintaining dual access.

SharePoint Framework Implementation

Setting Up the Microsoft Graph Client

In the code of your SharePoint Framework web parts and extensions, you should initialize an instance of the Microsoft Graph client object.

// In the web part's onInit method
protected async onInit(): Promise<void> {
  await super.onInit();
  
  // Get the Microsoft Graph client
  this._graphClient = await this.context.msGraphClientFactory
    .getClient('3'); // Version 3 of the Graph client
}

Accessing Legacy Settings

Once you have a Microsoft Graph client object, you can access the legacy AppRoot folder using the following syntax:

// Function to browse legacy application files
private async handleBrowseLegacyFiles(): Promise<void> {
  try {
    // Access the old application folder
    const legacyFolder = await this._graphClient
      .api('/me/drive/root:/Apps/SharePoint Online Client Extensibility Web Application Principal:/children')
      .get();
    
    // Process the files in the legacy folder
    const files = legacyFolder.value;
    
    for (const file of files) {
      // Get file content if needed
      const fileContent = await this._graphClient
        .api(`/me/drive/items/${file.id}/content`)
        .get();
      
      // Process or migrate the file content
      // Implementation depends on your specific requirements
    }
  } catch (error) {
    console.error('Error accessing legacy files:', error);
  }
}

Migration Strategies and Best Practices

When it comes to migration strategies, you can copy the settings from the old storage over to the new one, or you can provide a fall back strategy. In the following paragraphs you can find an example of both the options.

One-Time Data Migration Approach

If you want to do one-time data migration, you can provide a specific functionality in your web parts or extensions. For example, you can create a button in the property pane, or a startup function that gets executed first time you run the component. In the migration code, you can simply read the setting files from the legacy AppRoot folder and write them to the new AppRoot folder, like it is illustrated in the following code excerpt.

private async migrateLegacySettings(): Promise<void> {
  try {
    // Read from legacy location
    const legacySettings = await this._graphClient
      .api('/me/drive/root:/Apps/SharePoint Online Client Extensibility Web Application Principal:/children')
      .get();
    
    // Write to new location
    for (const setting of legacySettings.value) {
      const content = await this._graphClient
        .api(`/me/drive/items/${setting.id}/content`)
        .get();
      
      await this._graphClient
        .api('/me/drive/special/approot:/' + setting.name + ':/content')
        .put(content);
    }
  } catch (error) {
    console.error('Migration failed:', error);
  }
}

Dual-Access Pattern

Another option you have, is to simply try to use the new AppRoot folder and, in case of missing settings, you fall back to the legacy AppRoot folder. Again, here you can find a sample code excerpt.

private async getSettings(settingName: string): Promise<any> {
  try {
    // Try new location first
    const newSettings = await this._graphClient
      .api(`/me/drive/special/approot:/${settingName}:/content`)
      .get();
    
    return newSettings;
  } catch (error) {
    // Fall back to legacy location
    try {
      const legacySettings = await this._graphClient
        .api(`/me/drive/root/apps/SharePoint Online Client Extensibility Web Application Principal:/${settingName}:/content`)
        .get();
      
      return legacySettings;
    } catch (legacyError) {
      console.error('Settings not found in either location:', legacyError);
      throw legacyError;
    }
  }
}

Advanced Scenarios and Architecture Patterns

Decoupled Architecture with Azure Functions

For more sophisticated or enterprise-ready scenarios, consider implementing a decoupled architecture using a back-end Azure Function that handles reading and writing the user’s settings via Microsoft Graph on-behalf-of the current user. You can find a comprehensive sample of this architectural pattern in the article Mastering User Settings in SharePoint Framework.

The main benefits of using an Azure Function are:

  • Server-side processing: Reduced client-side complexity.
  • Centralized logic: Single point of truth for settings management.
  • Enhanced security: Sensitive operations performed server-side.
  • Scalability: Better handling of large-scale migrations.

Conclusion

The transition from the legacy SharePoint Framework security model to the new multi-tenant application architecture represents a significant improvement in performance, reliability, and governance. However, it requires careful consideration of legacy user settings stored in the legacy AppRoot special folders.

By following the technical guidance and best practices outlined in this article, organizations can successfully navigate the transition while preserving user settings and maintaining a positive user experience.

Additional Resources

The post Handling Legacy User Settings in SharePoint Framework appeared first on Microsoft 365 Developer Blog.

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

0.0.408

1 Share

2026-02-12

  • Add /streamer-mode to hide preview model names and quota details for streaming
  • Makes shellId more flexible to not error when a number is passed
  • Background tasks hint updates when detached shells are killed or removed
  • Add mouse text selection in --alt-screen mode
  • ! commands with large output no longer crash the CLI
  • Fix duplicate/ghost lines appearing when resizing the terminal in alt-screen mode
  • MCP servers respect the cwd working directory property
  • Add substring matching to slash command autocomplete
  • Change run command shortcut from ctrl+p to ctrl+s
Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

Xbox Celebrates the Legacy of id Software

1 Share

The post Xbox Celebrates the Legacy of id Software appeared first on Xbox Wire.

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories