We’re excited to announce the general availability of unified manifest support for Word, Excel, PowerPoint Add-ins, in addition to Outlook Add-ins. Unified manifest support first launched for Outlook Add-ins. Now, it extends across Word, Excel, and PowerPoint, making it possible to build a single app that works across Microsoft 365 apps. This update helps developers deliver a more consistent experience for users and gives IT admins a simpler deployment model.

Why it matters

The unified manifest brings Microsoft 365 extensibility closer to a single, consistent model for Teams apps, Office Add-ins, and Copilot agents. Developers have already used the unified manifest in Outlook Add-ins to simplify distribution, reduce customer friction, and increase adoption. A common request was to bring these same benefits to Word, Excel, and PowerPoint Add-ins. Over the last two years, teams across Microsoft have invested in making this possible. You can now bring existing add-ins forward with less effort and take advantage of a more streamlined path to support additional Microsoft 365 apps.

What you can do with the unified manifest

• Build once, distribute everywhere — Use one manifest to power experiences across Office Add-ins, Teams apps, and Microsoft 365 Copilot.
• Simplify deployment — Manage app access centrally through the Integrated Apps page in the Microsoft 365 admin center.
• Deliver a consistent experience — Help users find and use your app more consistently across supported Microsoft 365 surfaces.

A great example of what this makes possible is Script Lab Unity. Previously, developers needed separate Script Lab add-ins for Outlook and for Word, Excel, and PowerPoint. Using the manifest converter tool, the team combined those experiences into a single app with minimal rework. The result is Script Lab Unity — one app that’s easier to acquire and use across Microsoft 365.

What’s available

Developers can now publish unified manifest add-ins for:

Another example of this model is the Tableau Cloud app developed by one of our partners.

Get started

Ready to get started? Begin with the unified manifest overview, then choose the path that fits your scenario:

• Overview of the unified manifest
• Create a new add-in from scratch
• Convert an existing Office Add-in

We’d love to hear from you!

We value your feedback and suggestions. You can submit feedback directly within Office apps such as Excel by clicking the Feedback button in the upper-right corner, or by going to Help > Feedback. You can also connect with us through the Office Add-ins developer community.

Happy coding!

The post Build Once, Run Everywhere: Unified Manifest for Office Add-Ins now Generally Available appeared first on Microsoft 365 Developer Blog.

Why we’ve stopped noticing the real improvement opportunity

Since AI arrived, many people have mentioned that the bottleneck has shifted from coding to code review. This isn’t quite right, as coding wasn’t the bottleneck in the first place, and it’s not code review now. The reason we think either of these things is constraining the flow of value is that mossy hill we all stare past when we look at the mountains.

Here’s a simple test. For the application or service you work on, how many changes have passed code review but haven’t yet been deployed and enabled for users? If the answer is none or one, accept my apologies: in your specific case, I’m wrong. But I rarely get that answer. It’s usually more than one, and that tells you the bottleneck is elsewhere.

We’re conducting original research in this area right now, and half of all teams have between 2 and 10 changes sitting in a batch, and a quarter have 11-50. Overall, more than 90% of teams ship in batches rather than one change at a time.

“Coding wasn’t the bottleneck in the first place, and it’s not code review now.”

This number reveals an industry-wide visibility gap. People believe Claude Code, Cursor, and GitHub Copilot have shifted the bottleneck from coding to code review, but that ignores everything that happens after the review, and that’s not a personal failing; it’s an industry-wide misperception.

We’ve grown so used to working in batches that the practice looks like it belongs. It’s overgrown with moss, indistinguishable from the surrounding hills. When you search for ways to speed up software delivery, you won’t see it, because it doesn’t look like a problem. It looks just as things have always been.

What happens when AI floods a batch

Writing code is a small part of a longer value stream that starts with an opportunity and ends when a user gets the value they need. The impact across this whole value stream is lumpy. AI will help more in some areas than others, and the end-to-end benefit depends on you noticing the areas where work accumulates.

GitLab’s 2026 AI Accountability Report found that 85% of respondents agree AI has shifted the bottleneck from writing code to reviewing it. Yet we can see from deployment batches that 92% of these people are likely wrong, because if there’s accumulation after the code review, it means code review isn’t the bottleneck. It also means speeding up the reviews will make the real bottleneck worse.

This isn’t to say increased coding speed doesn’t put pressure on code review. Faros AI’s research across 10,000 developers found that teams with high AI adoption merge 98% more pull requests, but review time for those changes increases by 91%, and the average pull request size increases by 154%. Cursor’s own study, run with a University of Chicago economist, found companies merge 39% more pull requests once its coding agent becomes the default.

However, approving changes faster only works if the change then flows smoothly into production. In the majority of cases, it simply moves into the queue of changes awaiting further handling, such as testing and deployment. If you up the rate and size of changes passing through the review stage, pressure is simply transferred to the real bottleneck.

“If you up the rate and size of changes passing through the review stage, pressure is simply transferred to the real bottleneck.”

Code review looks like a constraint only because it has a visible queue, while the downstream queues are hidden by their general acceptance across the industry. The job of your pipeline is to get changes to production, where they can be used, not to gather them in a “pending deployment” queue.

And as all those unreleased changes accumulate, risk increases with them.

Batches are signposts

Ask the batch-size question, and you’ll find what’s really constraining your value stream: a manual verification step, a cumbersome change approval or release train process, or no easy way to deploy changes. Not coding. Not code review.

You were likely working in batches before you started your AI initiative. The introduction of AI will increase your batch sizes, which can cause problems. Increasing code review throughput doesn’t solve the problem; it simply moves changes to the bottleneck faster.

Using the true constraint to set the pace of your whole value stream will help you invest in solving the right problem. If your retrospectives keep failing to produce noticeable improvements, you’re likely missing the batch problem. It’s why some AI initiatives pay off while others flop.

The studies miss it, too

Research on the impact of AI is useful, but, like many studies on this topic, it stops at the point where code is merged. It looks at open pull requests, merged pull requests, and hours spent reviewing. None of it asks how long changes wait after the review, or how many are bundled together before anyone sees them in production. Without that number, you can’t find the real constraint.

Having invested in AI to speed up coding, you’ll be tempted to fix code review next, or give up on code reviews altogether. If you’re shipping in batches, neither will make much difference to how quickly you remove risk or deliver value to the people using the software.

The reason your organization resists fixing the batch problem is the real problem you need to solve.

The post AI hasn’t shifted the bottleneck from coding to code review appeared first on The New Stack.

A few years ago, getting a user signed in to an application or multiple applications with Single Sign-On (SSO) was enough; OpenID Connect (OIDC) handled the login, JWTs carried the claims, and Proof Key for Code Exchange (PKCE) made it secure. Today, with evolving AI, agents act on behalf of users and seek multiple accesses across different resources to execute a task. And that is when you’ll hit the gap.

The user has an identity, but the downstream service—like a Model Context Protocol (MCP) server, an API, or an agent tool has no way to trust it: the ID Token that proves the user’s identity for your app, not for that service. You need a way to take that identity and have it trusted further down the chain, in line with the org’s policy, without asking the user to log in again.

Cross App Access (XAA) solves exactly that. The user authenticates once. The Identity Provider (IdP) evaluates the enterprise policy and issues a signed Identity Assertion. The downstream service exchanges that assertion for a scoped Bearer token.

In this post, we’ll explore how Cross App Access (XAA) closes the trust gap, test the flow using an XAA playground, and implement a secure MCP client in just a few lines of C# using our dedicated SDK.

Table of Contents

• What is Cross App Access (XAA)?
• Implementing XAA with the C# MCP SDK
  • Building the OIDC flow
  • Automate XAA token exchange with C# SDK
  • Connect the MCP client to the server
• Testing your C# MCP app with xaa.dev
• Run your C# MCP app with xaa.dev
• Learn More About Secure AI Agent Development with C# and MCP

What is Cross App Access (XAA)?

Before we start implementing and building the application, it is important to understand the mechanics of Cross App Access (XAA). At its core, XAA is an open standard that securely enables AI agents to act on behalf of a user and communicate with downstream applications without requiring constant, manual user consent.

While the flow is sophisticated, it relies on two standard interactions:

1. RFC 8693 (Token Exchange): The requesting app exchanges an OIDC ID token for a JWT Authorization Grant (JAG) at the enterprise Identity Provider.
2. RFC 7523 (JWT Bearer Grant): The app presents this JAG to the MCP authorization server to receive a scoped access token for the resource.

The diagram below gives a complete flow for XAA and token exchanges.

You can find a complete flow diagram and explanation of XAA in the “Integrate Your Enterprise AI Tools with Cross App Access” blog.

In the next steps, let us understand how to implement the 4 steps of XAA using the MCP software development kit (SDK).

Implementing XAA with the C# MCP SDK

Building this manually would require you to manage complex cryptographic handshakes. Instead, we’ll use the C# MCP SDK; more details are available in the official GitHub repository. The C# MCP SDK’s IdentityAssertionGrantProvider handles all the heavy lifting, abstracting these RFCs into a clean, developer-friendly interface that lets you focus on your agent logic rather than the authentication plumbing. Let us implement that step by step.

Building the OIDC flow

ASP.NET Core has a built-in OIDC middleware that handles the full authentication flow, including PKCE. Since the package handles the implementation, all we have to do is configure our values.

builder.Services
    .AddAuthentication()
    .AddCookie(o => { o.Cookie.Name = "xaa.auth"; })
    .AddOpenIdConnect(o =>
    {
        o.Authority    = config["Xaa:IdpBaseUrl"];
        o.ClientId     = config["Xaa:ClientId"];
        o.ResponseType = "code";
        o.UsePkce      = true;
        o.SaveTokens   = true; // ID Token persisted into the auth cookie
        o.MapInboundClaims = false;
        o.Scope.Add("openid");
        o.Scope.Add("email");
    });

An important thing to note here is that MapInboundClaims = false, which stops ASP.NET Core from remapping standard OIDC claim names to legacy WS-Federation names, keeping the token payload clean and predictable downstream.

Automate XAA token exchange with C# SDK

This step marks the start of the XAA flow. With the SDK, instead of the user directly authorizing the MCP client, the app performs a two-hop token upgrade on the user’s behalf, and the MCP C# SDK’s IdentityAssertionGrantProvider encapsulates both exchanges.

The application presents the user’s ID token to the IdP and represents the user’s identity to the MCP server. The IdP responds with an ID-JAG, a short-lived token that grants access to the resource server. You then exchange this ID-JAG for an access token to access the server.

var provider = new IdentityAssertionGrantProvider(
    new IdentityAssertionGrantProviderOptions
    {
        ClientId         = config["Xaa:McpClientId"]!,
        ClientSecret     = config["Xaa:McpClientSecret"],
        IdpTokenEndpoint = $"{config["Xaa:IdpBaseUrl"]}/token",
        IdpClientId      = config["Xaa:ClientId"]!,
        IdpClientSecret  = config["Xaa:ClientSecret"],
        Scope            = "todos.read mcp.access",

        // Called by the SDK when it needs the current user's ID Token
        IdTokenCallback = (_, _) => Task.FromResult(idToken)
    },
    httpClient);

var result = await provider.GetAccessTokenAsync(
    resourceUrl:           new Uri(config["Xaa:McpServerUrl"]!),
    authorizationServerUrl: new Uri(config["Xaa:AuthServerUrl"]!));

var accessToken = result.AccessToken;

With the IdTokenCallback, the provider retrieves the user’s ID Token from the session.

Connect the MCP client to the server

After the exchanges, this is the final part, where the client can now access the MCP server and use the resource data. The HTTP-based servers handle session negotiation and message framing.

//Set up the transport with the exchanged access token
var transport = new HttpClientTransport(new HttpClientTransportOptions
{
    Endpoint          = new Uri(config["Xaa:McpServerUrl"]!),
    TransportMode     = HttpTransportMode.StreamableHttp,
    AdditionalHeaders = new Dictionary<string, string>
    {
        ["Authorization"] = $"Bearer {accessToken}"
    }
});

// Initialize the MCP client
await using var client = await McpClient.CreateAsync(transport);

McpClient.CreateAsync performs the MCP initialization handshake, exchanging the protocol version and capabilities with the server before making any resource request. From here on, interacting with the server is straightforward.

var resources = await client.ListResourcesAsync(); //lists all the available URIs
var result    = await client.ReadResourceAsync("todo0://todos");

var raw = string.Join("",
    result.Contents
          .OfType<TextResourceContents>()
          .Select(c => c.Text ?? ""));

This app uses todo0://todos to fetch from the xaa.dev resource server. The complete sample code for the app is available in the linked GitHub repository.

Testing your C# MCP app with xaa.dev

Now that we’ve stepped through the XAA flow, it’s time to test it. xaa.dev is a testing playground. It provides a standardized, functional environment that lets you verify your end-to-end flow immediately and serves as the bridge between your app and the downstream resource.

To test out the application using the xaa.dev platform, follow the steps below to get the app registered as the requester app:

1. Go to xaa.dev and select the Register, test, and manage your requesting app tab, then select Continue with your app.
2. Enter your email and click on Continue and Register New App.
3. Enter the Redirect URI and Post-logout URI as below.
4. Click on the Add Resource section and select ToDo MCP Server.
5. Click on Register App, and your app is now registered as a requester app in the XAA flow.

You should have your connections set up like in the screenshot below.

In this example, the C# app is a requester app that fetches the to-do list from the Todo app and analyzes the tasks fetched.

Run your C# MCP app with xaa.dev

At this point, you should have your application ready, running on port 5000, and connected to the XAA sample resource app. If not, you can clone the repo from the GitHub repository and add the following environment variables to the appsettings.json file:

git clone https://github.com/oktadev/csharp-mcp-sdk-example.git
cd xaa-csharp-mcp-sdk-example

{
  "Xaa": {
    "ClientId":        "<your-client-id>",
    "ClientSecret":    "<your-client-secret>",
    "IdpBaseUrl":      "https://idp.xaa.dev",

    "McpClientId":     "<your-mcp-client-id>",
    "McpClientSecret": "<your-mcp-client-secret>",

    "AuthServerUrl":   "https://auth.resource.xaa.dev",
    "McpServerUrl":    "https://mcp.xaa.dev/mcp",

    "RedirectUri":     "http://localhost:5000/callback"
  },
  "Logging": {
    "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" }
  },
  "AllowedHosts": "*"
}

Make sure to copy the correct client ID and secrets from xaa.dev. Once done, run the app.

dotnet run

Go to http://localhost:5000/, and you should see the app.

Sign in to the app using a test email and provide a random verification code as below. Once you sign in, the XAA playground handles the login request; you can verify this by checking the URL on your screen.

Once done, you should see the analyzer app running the XAA flow, displaying all details and analyzing all To-Do tasks.

The MCP SDK and XAA simplify building and testing cross app access.

Learn More About Secure AI Agent Development with C# and MCP

What you’ve seen here is the full XAA flow, starting from a user signing in with SSO to an AI agent securely fetching data from an MCP server running end-to-end in under 50 lines of C#.

The XAA playground (xaa.dev) makes this tangible without any infrastructure overhead. The IdP, the Auth Server, the MCP resource server — it’s all there, ready for you to register your app, drop in the credentials, and watch the token exchanges happen in real time. That’s the fastest path from concept to a working implementation.

If you wish to read further:

• Test the full source for this demo in the GitHub repository
• Register your own app and explore the XAA playground at xaa.dev
• Read the deep dive on how XAA closes the enterprise trust gap in Integrate Your Enterprise AI Tools with Cross App Access

As AI agents take on more complex, multi-step tasks across organizational boundaries, XAA is the secure solution that enables this without compromising security or user experience. Now you have the tools to build it.

Remember to follow us on X and subscribe to our YouTube channel for more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!