Want to use Claude for coding? Stop changing your billing implementation & use your Github Copilot subscription to access any model including Opus 4.8, Sonnet 4.6, GPT-5.4-Codex, Gemini 3.1 Pro. All are now available as coding agents for GitHub Copilot Business, GitHub Copilot Pro, GitHub Copilot Enterprise and GitHub Copilot Pro+ customers.

You can also run Claude, Codex, and Copilot directly inside github.com, GitHub Mobile, and VS Code, all within your existing GitHub workflows. Whether you’re reviewing code on the web, triaging issues on your phone, or iterating in the editor, you can stay within GitHub and use the same agents across surfaces with shared history and context. And most importantly:

No additional subscriptions are required.
Access to Claude and Codex is fully included with your existing GitHub Copilot subscription.

Read more at:
Claude and Codex now available for Copilot Business & Pro users – GitHub Changelog

For a quick review from Microsoft Build 2026, watch Tyler Leonhardt’s demo:

• LIVE168: Claude Is in Copilot. Here’s What That Actually Means
  Claude runs as a coding agent inside GitHub Copilot in VS Code. But what does that actually look like at the code level? How is context assembled? What tools does Claude have access to? What happens when you pick Claude in the model picker versus letting Copilot run? Tyler Leonhardt goes inside the integration so you know exactly what you are working with.
  http://aka.ms/githubcopilotclaude
  Third-party agents in Visual Studio Code

Hello Folks!

This week's updates all focus on something we hear from IT pros and platform engineers all the time:

How do we make our environments more secure, more manageable, and easier to modernize without adding more complexity?

Whether you're running PostgreSQL workloads in Azure, securing Kubernetes storage, or planning your next wave of SQL Server migrations, this week's announcements bring practical improvements that can help reduce operational overhead while strengthening your overall platform strategy.

We'll look at three newly available capabilities:

1. Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server
2. Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)
3. Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines

As always, I'm approaching these updates from an infrastructure and operations perspective. I'll cover why each capability matters, what to watch out for before production deployment, and some practical steps you can take to start evaluating them in your own environment.

Let's dig in.

Update #1 - Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server

Why ITPros should care

This release brings automated security posture assessment directly into managed PostgreSQL environments. For ITPros, this matters because database security is often treated separately from infrastructure security tooling, creating blind spots and silos.

What changed is that Defender now runs native vulnerability scanning and compliance checks against PostgreSQL configurations, patches, and the ways a database could be exposed to security risks or attack opportunities. Instead of relying on external scanners or manual audits, you get platform-native assessments integrated with your existing Defender workflows.

The operational impact is significant: you can now enforce security baselines at the database layer with the same consistency you apply to VMs and network resources, reducing the gap between infrastructure and data security accountability.

Operational value

Operationally, this improves your security baseline enforcement and reduces the need for separate database security assessment tools. It also strengthens how well you can demonstrate and prove that security controls are in place and working for compliance reviews where regulators expect consistent, documented security controls.

Before production rollout, validate that Defender cost models fit your budget, that assessment frequency aligns with your change windows, and that remediation guidance maps to your patch and maintenance processes.

Prerequisites include enabling Microsoft Defender for Cloud, registering the PostgreSQL Flexible Server provider, and ensuring network connectivity so assessments can reach the database endpoint.

Real-world example with step-by-step guidance

1. Enable Microsoft Defender for Cloud if not already active, and ensure PostgreSQL Flexible Server subscription coverage.
2. Register the target PostgreSQL Flexible Server instances and confirm Defender has network visibility to the database endpoints.
3. Run a baseline assessment and review initial findings to understand current security posture and common remediation patterns.
4. Prioritise findings by severity and business impact, then schedule patches and configuration changes in maintenance windows.
5. Monitor ongoing assessments and track remediation progress through Defender dashboards, validating that fixes reduce exposure scores.

Technical details including code examples

This example validates that Defender is actively assessing your PostgreSQL estate. The sequence checks Defender status, confirms PostgreSQL registration, and retrieves current assessment scores.

Run these queries in a pilot subscription first to understand data structure and expected output before scaling to production databases.

Expected behaviour: Defender status shows active, PostgreSQL instances are registered with the provider, and pricing tier reflects your coverage level. If assessments do not run, check network rules, managed identity permissions, and Defender plan activation. If baseline data is missing, trigger a manual scan and wait for completion.

Comprehensive Resources

1. Azure update: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server
2. Microsoft Defender for Cloud overview
3. Azure Database for PostgreSQL security
4. SQL vulnerability assessments in Defender for Cloud
5. Enable Defender for Cloud

Update #2 - Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)

Why ITPros should care

This release closes a significant gap in data protection for Kubernetes workloads consuming NFS shares from Azure Files. Previously, NFS traffic between AKS nodes and Azure Files was unencrypted, creating compliance and security risks for sensitive workloads.

What changed is that you can now enforce encryption for NFS communication at the Azure Files layer, not just at the application layer. This is important because traditional NFS lacks built-in encryption, and relying on network isolation alone is increasingly insufficient.

For ITPros managing regulated workloads (healthcare, finance, PII-sensitive data), this removes a control gap. Encryption in transit now becomes a platform-native feature instead of a workaround, reducing architecture complexity and improving auditability.

Operational value

The operational value is stronger compliance posture and reduced attack surface for data in motion between containers and storage. It also simplifies the security story when auditors ask about data protection controls.

Before enabling in production, validate that NFS-over-TLS introduces acceptable latency overhead for your workload patterns, test failover and reconnection behaviour under encryption, and confirm that monitoring and logging still work correctly.

Prerequisites include running AKS with Azure CNI or Kubenet networking, having Azure Files with NFS 4.1 enabled, and ensuring the NFS client libraries on container images support TLS.

Real-world example with step-by-step guidance

1. Create an Azure Files NFS share with encryption in transit enabled and confirm TLS version alignment with your security standards.
2. Deploy a test AKS workload that mounts the NFS share and validate that pods mount successfully with encrypted traffic.
3. Run performance baselines (throughput, latency, CPU overhead) before and after enabling encryption to document operational expectations.
4. Monitor pod logs and Azure Files metrics during the test to confirm no silent failures or unexpected throttling occurs.
5. Roll out to production workloads in stages, with clear rollback criteria tied to application latency and error rates.

Technical details including code examples

This example validates that your AKS cluster can successfully mount NFS shares with encryption enabled. The sequence checks cluster networking, confirms NFS connectivity, and tests mount success.

Run these commands in a non-production cluster first to validate environment readiness before touching production storage.

Expected behaviour: cluster networking is properly configured, storage account kind supports NFS, and PVC/PV resources show NFS mount points. If mounts fail, check network security group rules, storage account firewall allowances, and subnet delegation. If latency increases, monitor resource utilisation and adjust workload placement if needed.

Comprehensive Resources

1. Azure update: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS)
2. Azure Files NFS support
3. Mount Azure Files with NFS in AKS
4. Azure storage security
5. AKS networking concepts

Update #3 - Generally Available: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines

Why ITPros should care

This capability brings SQL Server migration into the Azure Arc operational footprint, creating a unified migration and inventory experience. For ITPros, this matters because SQL Server modernisation is often fragmented across multiple tools and teams.

What changed is that you can now discover, assess, and execute SQL migrations through Arc-native workflows, using the same permissions and governance model you already have for infrastructure and hybrid resources.

The operational gain is consistency: discovery data feeds migration planning, assessments surface blockers early, and rollout can be controlled through the same change and approvals processes you use for other infrastructure migrations.

Operational value

Operationally, this reduces tooling sprawl and improves coordination between infrastructure and database teams. Arc becomes your single control plane for tracking migration progress, managing runbooks, and collecting audit evidence.

Before production use, validate that your SQL Server inventory is complete, that migration blockers are understood and addressed, and that your maintenance windows can accommodate expected cutover timings.

Prerequisites include Azure Arc agent deployment on source VMs, Azure Database Migration Service readiness, and network connectivity to target Azure SQL resources.

Real-world example with step-by-step guidance

1. Deploy Azure Arc agents to SQL Server VMs and confirm all instances report healthy status with complete inventory data.
2. Run Arc-integrated SQL Server assessments to identify compatibility issues, dependencies, and recommended migration targets.
3. Pilot migration for a non-critical workload to establish runbook patterns, measure cutover time, and validate post-migration validation procedures.
4. Execute validation tests: connectivity, login success, database consistency checks, job execution, and application integration tests.
5. Scale migration in waves using documented runbooks, with gates for monitoring data health and application performance after each cutover.

Technical details including code examples

This example validates Arc agent health and SQL Server discovery completeness. The sequence ensures your Arc infrastructure is ready for migration workflows.

Run these commands as part of your pre-migration checklist to catch configuration gaps before committing to migration timelines.

Expected behaviour: Arc agents report healthy status, SQL Server instances are fully discovered with accurate inventory, and required extensions are provisioned successfully. If discovery is incomplete, check Arc agent connectivity, extension deployment, and SQL service running status on source VMs. If migration pre-checks fail, verify SQL Server version compatibility and review Defender logs for blocking issues.

Comprehensive Resources

1. Azure update: Expanding Azure Arc SQL Migration with SQL Server on Azure Virtual Machines
2. Azure Arc SQL Server Overview
3. Azure Arc-enabled servers
4. SQL Server on Azure Virtual Machines
5. Azure Database Migration Service

For any new capability this week, if they map to your operational roadmap, run a controlled pilot, measure the impact, and then scale with confidence. That is how you move the needle on modernisation while managing risk.

Cheers!

Pierre Roman

Robin and Mazen tackle a listener Q&A covering React Native, AI, mobile development, Expo Router, Flutter, performance, consulting, and code quality. They share practical engineering insights, real world stories, and why React Native continues to thrive in the age of AI.

Connect With Us!

• Robin Heinze: @robinheinze
• Mazen Chami: @mazenchami
• React Native Radio: @ReactNativeRdio

This episode is brought to you by Infinite Red!

Infinite Red is a premier mobile app consultancy, especially focused on Expo and React Native, located fully remote in the US. We're a team of 30 with highly experienced mobile app developers and have been doing this for over a decade. We are also one of the first development teams to adopt agentic coding in a way that keeps high quality standards and aren't afraid to do things the old school way if we need to. If you're looking for mobile app or React Native or Expo expertise for your next project, hit us up at infinite.red/radio.

I’m Matt Burns, Chief Content Officer at Insight Media Group. Each week, I round up the most important AI developments, explaining what they mean for people and organizations putting this technology to work. The thesis is simple: Workers who learn to use AI will define the next era of their industries, and this newsletter is here to help you be one of them.

Last week I told you the AI frontier was dropping the price of intelligence toward a dollar. This week, Elon Musk took one part of the stack to zero.

On Wednesday, SpaceXAI open-sourced Grok Build, its terminal coding agent, under an Apache 2.0 license. “Grok Build is now open source,” Musk posted. The move looks like a direct attack on Claude Code and Codex: Give developers the harness for free, reset usage limits, and make competing tools defend their prices.

Then Bloomberg supplied the number that explains why SpaceXAI can afford the open source move. Anthropic, the company behind Claude Code, reportedly pays SpaceXAI $1.25 billion a month for compute. Across Anthropic, Google, and Reflection, SpaceXAI’s compute agreements total roughly $2.3 billion a month. 

Musk is competing with Anthropic for developers while renting Anthropic the machines it needs to compete. Grok does not have to beat Claude for SpaceXAI to benefit from Claude’s growth. 

Open-sourcing the harness may expand the market for coding agents. SpaceXAI is unusually positioned to make money if that happens, even when developers choose Claude instead.

Musk can lose the coding-agent race and still get paid

Coding agents have become more capable, more autonomous, and more token-thirsty throughout 2026. Musk has now made one of the major agent harnesses open source, even though the model powering it still costs money to run.

Grok Build is a terminal coding agent in the same category as Claude Code and OpenAI’s Codex. As our own Janakiram MSV wrote in a six-months-in comparison, the contest stopped being about raw model quality a while ago: “Once everyone accepted the shape, the contest moved to the platform around it.” Grok Build entered the platform war in May with a local-first design and a roughly 70% score on SWE-bench. The model behind it is not a joke, either: Artificial Analysis placed the newly launched Grok 4.5 near the frontier on its independent benchmarks while measuring it as one of the cheapest models at that performance level. OpenAI noticed. Greg Brockman, its president, replied: “If you’re able to get better price/perf on any workload, would love to hear the details,” and published his email address.

So why give the coding agent away? Because SpaceXAI can afford to fight this war differently from OpenAI and Anthropic. Musk can open-source the harness, price Grok aggressively, and still earn infrastructure revenue from Anthropic, the company behind the coding agent it’s trying to undercut.

Musk has enough compute to make this move. According to Bloomberg Businessweek, SpaceXAI’s own models were using just 11% of its available computing power in April, so it has room to spare and rarely caps its customers, even as Anthropic is reportedly scrambling through a compute crunch. SpaceX’s CFO put the strategy plainly: “Elon felt the constraint was going to be compute and power. We are already seeing that.” That is the strange shape of it. SpaceXAI can subsidize the product competing against one of its largest infrastructure customers.

The business model is stronger than the organization running it

A second economic position is worth nothing if the company can’t run the product. This is where the story gets harder for Musk. That same Bloomberg piece is a portrait of an operation in disarray: All eleven of xAI’s co-founders have left, and an internal survey found the most common complaint was that management “didn’t seem to know what it wanted.” The most damning detail for a company selling coding tools is that xAI’s own engineers reportedly won’t use them, reaching for Anthropic’s and OpenAI’s tools instead. If the people building Grok don’t trust it to code, it’s fair to ask why outside developers should.

That trust problem got worse the week of the open-source release. Grok Build was open-sourced the day after developers discovered it was quietly uploading entire directories to SpaceXAI’s cloud. One user watched it grab “my SSH keys, my password manager database, my documents, photos, videos, everything.” Musk promised the data would be “completely and utterly deleted.” In that context, whatever strategic value the open-source release had, it also became damage control.

Then the world read the Grok Build code. As Simon Willison writes, parts of Grok Build’s tooling were ported from other coding agents, including OpenAI’s Codex and the open-source OpenCode. So the tool positioned against Codex incorporates openly licensed work derived from Codex.

That is not necessarily a scandal. It is how open source is supposed to work. But opening the repository exposed two things at once: The privacy mechanism Musk had just disabled, and how quickly the coding-agent layer is becoming portable. Our own Paul Sawers made the case months ago that the harness is where coding agents differentiate themselves. Grok Build shows how difficult it may be to keep that differentiation proprietary. 

Strip away the organizational chaos, and the economic move is narrow and smart. 

Musk does not need to win developers away from Anthropic. Open-sourcing Grok Build can expand the market for coding agents, and SpaceXAI can benefit even when developers choose Claude. Anthropic pays for the compute beneath that growth.

That’s the strange shape of Musk’s position. Anthropic has to make Claude beat Grok, and Musk can get paid when it does.

The post Musk open-sourced Grok Build to fight Anthropic. Anthropic pays him $1.25 billion a month. appeared first on The New Stack.

If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to connect with third-party applications without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you.

The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. This guide details what you need to support and how to make resource requests to a third-party app using XAA.

Table of Contents

• How XAA in SAML works
• XAA implementation checklist for SAML-federated applications
  • Request the refresh token
  • Request the refresh token
  • Request the access token
  • Handle token expiration
• Making cross-application requests from your SAML app securely
• Configure your XAA SAML Requesting App in Okta
  • Register and configure the AI Agent in Okta
  • Test the SAML 2.0 app
  • Validate the XAA connection end-to-end
• Learn more about Cross App Access, SAML, and OAuth 2.0

How XAA in SAML works

When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the Identity Provider (IdP) for your app’s user. You exchange the ID-JAG token for an access token to the resource application you’re connecting with.

The sequence diagram shown below describes the SAML XAA flow and how your application fits in. You’ll handle the flow in two parts: where your application requests the ID-JAG from the IdP using a refresh token, and where your app requests the access token from the ID-JAG from the third-party resource app’s authorization server.

XAA implementation checklist for SAML-federated applications

Follow the guide in this section to support XAA in your SAML application when your app connects to a third-party resource application. The XAA flow places the burden of token validation onto the IdP and the resource app’s authorization server. The initial SSO step remains the same; however, you’ll add three requests before getting an access token to make the resource API call.

Once the user completes signing in, you’ll:

1. Request an OAuth refresh token from Okta
2. Request the ID-JAG token from Okta
3. Request the OAuth access token from the third-party resource app’s OAuth authorization server

Request the refresh token

Your SAML application makes the initial SSO handshake and handles the SAMLResponse as usual. The ACS handler verifies the incoming payload and its digital signature, then extracts the underlying XML assertion. This assertion serves as the required credential for the subsequent exchange.

Immediately after validating the SAML response, in the same ACS request before redirecting the user onward, you’ll perform the first exchange. Base64-encode the assertion you extracted, then exchange it for a refresh token using Okta’s token endpoint. This exchange follows the OAuth 2.0 Token Exchange (RFC 8693) mechanism.

The refresh token HTTP request looks like this:

POST /oauth2/v1/token HTTP/1.1
Host: your-okta-domain.okta.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token=<base64url-encoded SAML assertion XML>&
subject_token_type=urn:ietf:params:oauth:token-type:saml2&
requested_token_type=urn:ietf:params:oauth:token-type:refresh_token&
scope=openid+offline_access&
client_id=<your_client_id>&
client_secret=<your_client_secret>

The IdP (Okta) responds with the refresh token. The refresh token is opaque and long-lived. Persist the refresh token for the session; never persist or use the SAML assertion past this exchange.

Request the refresh token

With the refresh token in hand, you have the credentials to request the ID-JAG token when your application needs resources from a third-party app. This exchange uses the same OAuth token exchange mechanism as the first step. You make the POST request to the same endpoint, Okta IdP, use the refresh token as your credential, and request the ID-JAG token type.

The HTTP request looks like this:

POST /oauth2/v1/token HTTP/1.1
Host: your-okta-domain.okta.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token=<the refresh_token from prior step>&
subject_token_type=urn:ietf:params:oauth:token-type:refresh_token&
requested_token_type=urn:ietf:params:oauth:token-type:id-jag&
audience=<the resource app's authorization server issuer URI>&
resource=<the resource app's API base URL>&
scope=<the resource app's required scopes>&
client_id=<your_client_id>&
client_secret=<your_client_secret>

The IdP responds with a short-lived, signed JSON Web Token (JWT), the ID-JAG, as the value in the access_token property within the payload.

Request the access token

Redeem the ID-JAG at the resource app’s authorization server’s token endpoint. The resource app’s authorization server handles the redemption request, not the IdP. This request uses the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants (RFC 7523). The ID-JAG is the assertion now, and you include the scopes required for the resource request. The scope matches the scopes requested in the ID-JAG request. The HTTP request looks something like:

POST /token HTTP/1.1
Host: the-resource-server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64(resource_as_client_id:resource_as_client_secret)>

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=<ID-JAG token>&
scope=todos.read

In the example HTTP request, the Authorization header uses the Basic scheme as a demo. Use the authorization scheme required by the resource application.

The response payload contains the access_token property, whose value is the access token. Use the access token to make the API resource request by using the value in the Authorization header. For example:

Authorization: Bearer <access_token>

Handle token expiration

ID-JAG tokens have a short timeline by design. When it expires, request a shiny new ID-JAG from the refresh token. Refresh tokens also have a lifespan. If the IdP rejects the refresh token due to expiration (you’ll see an invalid_grant error), then you need to obtain a new refresh token by having the user sign in via SSO again.

Making cross-application requests from your SAML app securely

With these steps complete, your SAML application is configured for Cross App Access. Agents can now authorize requests against your API while maintaining your existing production federation, eliminating the need for protocol migration.

You can now use Okta to make cross-application requests with your SAML app.

Configure your XAA SAML Requesting App in Okta

Let’s configure your SAML requester application in Okta. Before you begin, you’ll need:

• Values from your app (we’ll walk through the values needed below)
• An Okta Integrator Free Plan account. Sign up for a new account to test out the XAA feature
• xaa.dev for testing your requesting app

Cross App Access is an early access feature in Okta. New Integrator Free Plan account types include XAA support. If you have a paid Okta org plan and the following options are missing, contact your representative.

Sign in to your Integrator Free Plan org and open the Admin Console.

Enable AI Agent Identity Assertion:

1. Navigate to Settings > Features > Early Access
2. Find AI Agent Identity Assertion and Agent to Agent Connections, and enable both

You’ll need an Okta application representing your requesting app.

Navigate to Applications > Applications

In the Create a new app integration model, select SAML 2.0 and press Next.

In General Settings:

1. App name: Enter a descriptive name for the app, for example, “Requesting App”.
2. Press Next to continue

In Configure SAML:

1. Single sign-on URL: Use the ACS URL of your requestor app, e.g., “https://requester-app-uri/saml/acs”
2. Audience URI (SP Entity ID): Use the SP Entity of your requestor, e.g., “https://requester-app-uri/saml/metadata”
3. Name ID format: select EmailAddress
4. Application username: select Email
5. Update application username on: select Create and update
6. Press Next to continue

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 requesting app. You’ll make changes in more than one tab.

Sign On configuration

Select the Sign On tab. To the right, locate the View SAML setup instructions under the header SAML Setup, open the saml-doc file, and copy the Identity Provider Single Sign-On URL and Identity Provider Issuer. You will need these values in your requesting app setup. On the same page, make sure you download the X.509 certificate and add it back to your requester app as idp-cert.pem.

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

1. Select Assign > Assign to People
2. Search for your test user and select Assign
3. Press Save and Go Back, then select Done

Now that we have the requesting app registered, it’s time to register a resource app on the Okta platform. You’ll also need an Okta application representing the resource app.

Navigate to Applications > Applications

In the Create a new app integration model, select SAML 2.0 and press Next.

In General Settings:

1. App name: Enter a descriptive name for the app, for example, “Resource App for Testing”.
2. Press Next to continue

In Configure SAML:

1. Add https://idp.xaa.dev/saml-resource/acs for Single sign-on URL
2. Add https://idp.xaa.dev/saml-resource/metadata for Audience URI (SP Entity ID)
3. Name ID format: select EmailAddress
4. Application username: select Email
5. Update application username on: select Create and update
6. Press Next to continue

⚠️ Note Please note that we’re providing these for setup; they don’t constitute a working SSO connection to the resource app. Also, don’t assume the NameID is an email address; it is whatever the customer’s SSO emits. Your matching set must remain consistent across your deployment.

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 app. You’ll make changes in the resource server tab.

Resource Server extra configuration

Navigate to the Resource Server tab and make the following configuration changes:

1. Select Enable XAA
2. Issuer URL: Add this value to your Issuer URL: https://auth.resource.xaa.dev

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

1. Select Assign > Assign to People
2. Search for your test user and select Assign
3. Press Save and Go Back, then select Done

The next step is to set up xaa.dev for the resource app.

Go to Test your requesting app Add your IdP issuer URL as your Okta Integrator account ID (i.e., https://your-okta-domain.okta.com) Put your email into the Test user identifier example, name1234…@okta.com Finally, select My ID-JAG is SAML-derived and add your SAML IdP entityID from the requesting app you created under the Sign On tab > SAML Setup > View SAML setup instructions, open the saml-doc file, and find the Identity Provider Issuer value (i.e., http://www.okta.com/) After all values are entered, click on the **Register**

Register and configure the AI Agent in Okta

With your Okta SAML 2.0 requesting app and the resource app configured, register a new AI Agent in Okta. The AI Agent configuration defines the relationship between the Okta SAML 2.0-requesting app you have and the resource application, which in this case is xaa.dev. You’ll configure credentials, add your requesting app as a delegated caller, and connect the resource app as a Resource Connection.

In the Okta Admin Console:

1. Navigate to Directory > AI Agents
2. Select Register AI Agent > Register Manually
3. Enter a Name, e.g., “Agent”
4. Select Register

Select the AI Agent you just created to open its configuration. Configure the agent across the following tabs:

1. On the Owners tab
   1. Select Assign individual owners
   2. Search for and add yourself as an owner
   3. Press Save
2. On the Credentials tab (select the agent you’ve just created to see this tab)
   1. Copy the AI agent ID and add the value as the Client ID for your requesting app.
   2. Back in Okta, select the Add Public Key, and then press Generate new key. Okta generates a key pair and displays the private key. Under PEM, press Copy to clipboard, then store the key securely on your end. You’ll paste this private key into the Private key (PKCS8 PEM or private JWK) field in your requesting app, then save.

3. Also copy the kid and add it back to your requesting app

4. On the Delegations tab
   1. Select Add Caller
   2. Search for the newly created Okta SAML requesting app
   3. Select Add Caller to confirm
5. On the Resource Connections tab
   1. Select Add Resource Connection. Under the Resource section, select Application as the resource type.
      1. Under the Application section, choose your App configured for AI Agent access instance as the Resource app. (In this case, it should be the “Resources App”) from the dropdown menu and paste the Client ID from xaa.dev. (It should look something similar to byora...)
   2. Under Scope Condition, select Allow all
   3. Select Add to confirm

The final step is to activate the AI agent. Go to Actions and select Activate

Once the AI Agent is active, the configuration is complete. All checkmarks on the agent configuration page must be green.

Test the SAML 2.0 app

At this stage, you are all set to run the requesting app and verify the complete XAA flow it is supposed to perform.

Validate the XAA connection end-to-end

Once the flow is complete in the SAML 2.0 application, return to xaa.dev. In the Live verification tab, a green Conformance passed panel appears. This confirms all steps:

1. Auth Server Accepted your ID-JAG
2. Access token was issued
3. Resource Server accepted your access token
4. API call to the /api/todos/ was a success.

At this stage, the JSON conformance log will have the complete details of the XAA flow.

Learn more about Cross App Access, SAML, and OAuth 2.0

If this guide helped you implement Cross App Access with SAML, explore these resources:

• 📘 Cross App Access Documentation: Official guides for configuring and managing Cross App Access in production.
• 🎙️ Developer Podcast on MCP and Cross App Access: Hear the backstory, use cases, and why this matters for developers.

Identity 101:

• What’s the Difference Between OAuth, OpenID Connect, and SAML?
• What are SAML, OAuth, and OIDC?
• Why You Should Migrate to OAuth 2.0 From Static API Tokens
• How to Get Going with the On-Demand SaaS Apps Workshops

Follow us on LinkedIn and X, and subscribe to our YouTube channel. Leave a comment below if you have any questions!