DEV Community: Will Velida

Configuring and Securing Azure Key Vault for the Enterprise

Will Velida — Thu, 05 Nov 2026 06:02:46 +0000

We can use Azure Key Vault to securely store and control access to sensitive information. We can use it to handle secrets (things like database connection string, passwords, API tokens etc.), cryptographic keys (used for encrypting and decrypting data), and certificates (SSL/TLS certificates used to secure communications).

However, just having a Key Vault by itself doesn't automatically make your application secure. We can deploy Azure Key Vaults with soft delete and purge protections to protect our vaults from accidental deletions, we can configure RBAC-based access controls, just-in-time activations using PIM, and we can lock down our Key Vaults using firewall rules, virtual networks, and private endpoints.

In this blog post, we'll talk about how we can set up our Key Vaults properly for enterprise scenarios, with the right security, access, and network controls that will help protect your sensitive information from being compromised.

Deploying Azure Key Vault with security controls

The first thing you need to consider is what SKU do you need. Azure Key Vault provides two tiers:

Standard, which protects keys using software-based encryption. The key never leaves Azure, but it's not backed by dedicated hardware. For most workloads, this level of protection is fine.
Premium, which protects keys with a hardware security module (HSM) validated to Federal Information Processing Standard (FIPS) 140-3 Level 3. The key is created inside the HSM and never gets exported in unencrypted form.

Once you've decided what SKU you need, you'll need to set some critical properties on the Key Vault when you deploy the vault.

Soft delete preserves deleted vault objects (keys, secrets, and certificates) that can be recovered within a configured period of between 7 to 90 days. During this window, any deleted objects can be recovered.

Soft delete in enabled by default on all new vaults and can't be disabled after you create the vault. The retention period can also only be set when you create the vault.

Purge protection prevents Key Vaults and objects from being purged permanently. Without this, any identity with the right level of permissions can delete objects and vaults, and purge them! Imagine if you're encrypting your data at rest using cryptographic keys in Key Vault, and someone deleted that key! Good luck trying to read that data again!

Finally, when you create the vault, Public network access is enabled by default, which means that any internet IP address can try to authenticate with your Key Vault.

That doesn't mean that the vault is unprotected, you still have to have a valid Microsoft Entra token and the appropriate role assignment over the vault, it's just that the endpoint is exposed to the public internet, which expands the attack surface.

Configuring soft delete and purge protection for Key Vault is pretty straightforward in Bicep.

@description('Globally unique name for the Key Vault.')
param keyVaultName string

resource keyVault 'Microsoft.KeyVault/vaults@2024-11-01' = {
  name: keyVaultName
  location: 'australiaeast'
  properties: {
    tenantId: tenant().tenantId
    sku: {
      family: 'A'
      name: 'standard'
    }
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    enableRbacAuthorization: true
  }
}

We can enforce vault configuration at scale using Azure Policy. There are two built-in policies that help us apply soft-delete and purge-protection settings at scale:

Key vaults should have soft delete enabled. This helps identify vaults without soft delete configured.
Key vaults should have deletion protection enabled. This audits existing vaults and can block creation of new vaults that don't have purge protection enabled.

Assign these policies at either the subscription or management group scope to ensure every vault meets these requirements. You can also combine it with a remediation task to bring update existing vaults that don't have this enabled.

Configuring access to Azure Key Vault

Access in Azure Key Vault can be divided into the control plane and the data plane

The control plane governs the Key Vault itself. Operations use Azure Resource Manager (ARM) and include creating or deleting the vault, configuring network rules, and viewing metadata.

The data plane governs objects stored inside the vault. Both planes authenticate through Microsoft Entra ID, but authorization is independent on each plane.

Having this separation between the two planes helps improve security, since you can assign control-plane access to identities that only need to manage the vault as infrastructure, and data-plane access to those identities that need to work with Key Vault objects.

Key Vault supports two authorization models for the data plane: Azure RBAC and legacy vault access policies. These vault access policies are being retired, so I'll just discuss how Azure RBAC works for Key Vault, and tell you that if you're still using legacy access policies in your Key Vault, migrate to RBAC now!.

Azure RBAC provides roles for Key Vault operations across both planes.

Role	Plane	What it governs
Owner, Contributor	Control plane	The vault resource itself
Key Vault Administrator, Secrets User, Certificates Officer, Purge Operator	Data plane	The vault content

Let's take a closer look at some RBAC roles that you can apply in Key Vault.

Key Vault Administrator grants full data-plane access to all objects in the Key Vault. This role is the most powerful role, so don't grant it on a permanent basis and reserve it for break glass scenarios or automation that genuinely needs cross-object access.

Key Vault Secrets User grants read-only access to secret values. This is the right role for application service principles and managed identities that need to retrieve runtime secrets such as API keys and connection strings. This role only allows the identity to read the secret content, not create, update, or delete secrets.

Key Vault Certificates Officer allows full lifecycle management of certificates, including creating, importing, updating, and deleting certificates. With this role, you cannot touch secrets or keys.

Key Vault Purge Operator allows users to permanently delete soft-deleted vault objects. This role should only be used in explicit recovery or decommissioning scenarios, where you intend to purge soft-deleted objects.

To assign an RBAC role over the Key Vault in Bicep, we can do the following:

@description('Microsoft Entra object ID of the user.')
param userObjectId string

var secretsUserRoleId = subscriptionResourceId(
  'Microsoft.Authorization/roleDefinitions',
  '4633458b-17de-408a-b874-0445c86b69e6'
)

resource secretsUserAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, userObjectId, secretsUserRoleId)
  scope: keyVault
  properties: {
    roleDefinitionId: secretsUserRoleId
    principalId: userObjectId
    principalType: 'User'
  }
}

We can also use Privileged Identity Management (PIM) to eliminate the need to grant these roles permanently. If a user needs elevated Key Vault access, they can request activation of that role through PIM, which can use controls like MFA verification, justification, approvals, and time durations to limit access of the role.

Microsoft Entra Conditional Access let you apply policy-based controls to Key Vault access, such as requiring MFA for access from unmanaged or noncompliant devices, blocking access from risky sign-in locations, or limit access to requests that originate from locations or network paths you trust.

Configuring firewall and network settings for Azure Key Vault

By default, public network access is enabled when creating Key Vaults, making it reachable by any internet IP address.

The first thing we can do to increase network security on the Key Vault is enable the firewall and add explicit allow rules. Once you enable the firewall, all traffic is blocked by default, and only specific IPv4 addresses or Classless Inter-Domain Routing (CIDR) ranges that are defined will have access.

This is handy for situations where you have workloads or agents running on known IP addresses, and you enable that IP address on the firewall.

We can enable firewall access on Key Vaults in Bicep like so:

@description('Globally unique name for the Key Vault.')
param keyVaultName string

@description('Public IPv4 addresses or CIDR ranges allowed through the firewall.')
param allowedIpAddressesOrRanges array

resource keyVault 'Microsoft.KeyVault/vaults@2024-11-01' = {
  name: keyVaultName
  location: 'australiaeast'
  properties: {
    tenantId: tenant().tenantId
    sku: {
      family: 'A'
      name: 'standard'
    }
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    enableRbacAuthorization: true
    publicNetworkAccess: 'Enabled'
    networkAcls: {
      bypass: 'None'
      defaultAction: 'Deny'
      ipRules: [
        for addressOrRange in allowedIpAddressesOrRanges: {
          value: addressOrRange
        }
      ]
      virtualNetworkRules: []
    }
  }
}

We can take this further and disable public access entirely, but only after we create a private endpoint or virtual network rule. If we don't have this, we'll lock ourselves out of the vault!

Bear in mind that firewall rules only apply to data plane operations, not the control plane. Private IP address ranges cannot be used in IP allow list rules. In dynamic environments, this approach can be limited, as allow lists would need to be updated each time our infrastructure changes.

An alternative to this is to use Virtual network service endpoints inside an Azure virtual network. When we enable the Microsoft.KeyVault service endpoint on a virtual network subnet and add it to our Key Vault network rules, traffic from that subnet travels over the Azure backbone network, rather than than the public internet.

Configuring a service endpoint for our Key Vault can be done in Bicep like so:

param virtualNetworkName string
param subnetName string

@description('Subnet CIDR within the virtual network address space, without overlapping existing subnets.')
param subnetAddressPrefix string

@description('Globally unique name for the Key Vault.')
param keyVaultName string

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
  name: virtualNetworkName
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-05-01' = {
  parent: virtualNetwork
  name: subnetName
  properties: {
    addressPrefix: subnetAddressPrefix
    serviceEndpoints: [
      {
        service: 'Microsoft.KeyVault'
      }
    ]
  }
}

resource keyVault 'Microsoft.KeyVault/vaults@2024-11-01' = {
  name: keyVaultName
  location: 'australiaeast'
  properties: {
    tenantId: tenant().tenantId
    sku: {
      family: 'A'
      name: 'standard'
    }
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    enableRbacAuthorization: true
    publicNetworkAccess: 'Enabled'
    networkAcls: {
      bypass: 'None'
      defaultAction: 'Deny'
      ipRules: []
      virtualNetworkRules: [
        {
          id: subnet.id
          ignoreMissingVnetServiceEndpoint: false
        }
      ]
    }
  }
}

Service endpoints are an improvement over IP-based rules for Azure workloads, as traffic stays on the Azure backbone and never crosses onto the public internet.

However, Key Vault is has a public endpoint and it's DNS name still resolves to a public IP.

We can fully isolate our Key Vault using Private Endpoints. Once we combine a private endpoint with disabling public network access, the vault is no longer reachable through the public internet. The only way to connect to the vault is through your virtual network, or through connected networks such as Azure ExpressRoute or site-to-site VPN.

To get this to work correctly, we'll need a private endpoint resource, which is a network interface in your virtual network subnet that's bound to Key Vault via Azure Private Link. This receives a private IP address. We'll also need a private DNS zone. Without it, clients will resolve your vault's public IP regardless of the private endpoint.

param virtualNetworkName string
param keyVaultName string
param subnetName string = 'snet-private-endpoints'

@description('Non-overlapping subnet CIDR within the existing virtual network.')
param subnetAddressPrefix string

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
  name: virtualNetworkName
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-05-01' = {
  parent: virtualNetwork
  name: subnetName
  properties: {
    addressPrefix: subnetAddressPrefix
    privateEndpointNetworkPolicies: 'Disabled'
  }
}

resource keyVault 'Microsoft.KeyVault/vaults@2024-11-01' = {
  name: keyVaultName
  location: 'australiaeast'
  properties: {
    tenantId: tenant().tenantId
    sku: {
      family: 'A'
      name: 'standard'
    }
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    enableRbacAuthorization: true
    publicNetworkAccess: 'Disabled'
    networkAcls: {
      bypass: 'None'
      defaultAction: 'Deny'
      ipRules: []
      virtualNetworkRules: []
    }
  }
}

resource privateEndpoint 'Microsoft.Network/privateEndpoints@2024-05-01' = {
  name: '${keyVault.name}-pe'
  location: virtualNetwork.location
  properties: {
    subnet: {
      id: subnet.id
    }
    privateLinkServiceConnections: [
      {
        name: '${keyVault.name}-connection'
        properties: {
          privateLinkServiceId: keyVault.id
          groupIds: [
            'vault'
          ]
        }
      }
    ]
  }
}

resource privateDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01' = {
  name: 'privatelink.vaultcore.azure.net'
  location: 'global'
}

resource virtualNetworkLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
  parent: privateDnsZone
  name: '${virtualNetwork.name}-link'
  location: 'global'
  properties: {
    registrationEnabled: false
    virtualNetwork: {
      id: virtualNetwork.id
    }
  }
}

resource privateDnsZoneGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2024-05-01' = {
  parent: privateEndpoint
  name: 'default'
  properties: {
    privateDnsZoneConfigs: [
      {
        name: 'key-vault'
        properties: {
          privateDnsZoneId: privateDnsZone.id
        }
      }
    ]
  }
}

Once this is configured, you can disable public network access on the vault, fully isolating it from the internet. If you need some Microsoft-managed services to reach the Key Vault (E.g. Azure Monitor), you can use Allow trusted Microsoft services to bypass this firewall exception rule.

Not all vaults require the same level of network isolation. This diagram shows how you can match the model to the workload to keep the network configuration maintainable and appropriate for the risk:

Wrap up

Hopefully you now have a better understanding about how you can configure your Azure Key Vaults for enterprise scenarios. We discussed how security controls such as soft delete, purge protection, and SKU selection factor in to protect our Key Vaults and the objects inside our Key Vaults. We also took a look at how we can configure RBAC-based access controls to limit permissions on what identities can do to our Key Vault. Finally, we took at a look at how we can secure our Key Vaults via network controls such as firewall rules, service endpoints, and private endpoints.

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Implement and configure Privileged Identity Management (PIM)

Will Velida — Tue, 03 Nov 2026 23:40:33 +0000

Imagine if an attacker was able to compromise a privileged user at your company. The damage they could do with that identity could have permanent effects and they can continue to do that damage until someone notices.

This is was Privileged Identity Management, or PIM, is designed to stop. With PIM, we can implement just-in-time (JIT) access across a full surface of privileged access in a Microsoft cloud environment.

Why does this matter?

If you've ever worked on a greenfield project before, you've probably configured a Global Administrator account just to make sure you weren't blocked when you needed to do administrative tasks.

Did you remember to delete it?

This is called Standing privilege where a privileged role assignment is permanently active regardless of whether it's being used or not. Because it's always active, the credentials that control the role assignment are a valuable target to malicious actors, because the window of opportunity is the same of the lifetime of the assignment.

As you can imagine, if you have a Global Admin account just sitting there waiting to be compromised, the blast radius of damage has the potential to be quite destructive. For a Global Admin in Microsoft Entra ID, that would include:

User accounts
Group memberships
Application registrations
Federated trust settings
Every Azure subscription linked to the directory!

It's not just Global Admins either. Privileged Role Admins, Security Admins, and User Access Admins carry their own blast radiuses, and if you leave them standing there, they become permanent targets.

It's not just humans with these privileges. AI agents, model endpoints, and automation pipelines can operate under the same permissions granted by the identity that configured them. A compromise standing Global Admin account can redirect agent behavior, exfiltrate data, or use the agent to escalate access to other systems.

Just-in-time (JIT) access provides elevated permissions that you don't hold persistently. You can activate them for a specific task, and they expire after a defined period.

JIT access reduces the risk that standing privilege creates through 3 properties:

You don't have the access by default, meaning that there are no persistent credentials for an attacker to discover or steal.
You activate access. It's a deliberate process to elevate your permissions, which becomes an explicit, auditable event.
Access expires automatically. If a session is compromised, permissions are timeboxed, meaning that the attacker's window closes when the session ends.

Core capabilities of PIM

PIM implements JIT access through a set of controls. PIM supports both Microsoft Entra ID and Azure resource roles.

PIM uses two types of role assignments to give you control over when access is live:

An eligible assignment

This means you hold the entitlement to a role, but don't hold the role until you explicitly request an activation.

Activation is the act of requesting and receiving temporary elevated permissions from that entitlement, which is the JIT model in action.

An active assignment

This grants the role directly, making access immediate without any activation step. PIM can time-bound active assignments, making them suitable for temporary standing access with a defined expiration.

This is ideal for situations where the activation step is impractical, such as break-glass emergency accounts or tightly scoped temporary roles with a defined end date.

How Activation Controls work

When you activate an eligible assignment, PIM can require you to satisfy one or more conditions before granting the role. These controls decrease the possibility of unauthorize use and ensure that if an attacker steals a credential, that alone isn't enough to obtain elevated permissions.

These controls include:

MFA verification, which confirms your identity before elevation, so stolen credentials alone aren't enough to obtain the role.
Justification, which is a written reason you must supply before PIM grants the session. This creates an auditable record of why access was requested.
Approval, a delegated approver must confirm the request before PIM activates the role, which creates a human checkpoint for sensitive assignments.
Activation duration, the configured time window. This is measured in hours, after which PIM will automatically remove the role.

Some roles require all of these controls, while others only require MFA verification.

After a user activates a role, PIM sends email notifications to both the activating user and any configured approver, which creates immediate awareness that an elevated session is open. This results in a durable record of all privileged activity across your tenant.

PIM also supports access reviews, which periodically validates that eligible assignments are still appropriate.

Implementing JIT access for Microsoft Entra roles

Not every Entra role needs JIT controls, but there are a couple of high-privileged roles that have a large enough blast radius where permanent assignment of that role creates unacceptable risk.

Role	Why JIT?
Global Administrator	Broadest blast radius in the tenant, as it gives full control over all directory settings and services.
Privileged Role Administrator	Can modify any role assignment, including its own!
Security Administrator	Controls security policy configuration across the tenant
Exchange Administrator	Has full access to email and calendar infrastructure
Application Administrator	Can register apps and modify application credentials
Authentication Policy Administrator	Controls authentication methods policy, tenant-wide MFA settings, and password protection policy

Just a heads up, before you make Global Admin eligible in PIM, verify that at least 2 break-glass accounts hold a permanent active assignment to the role. Store these securely offline, because without it, a misconfiguration or an identity provider outage could lock every admin out of the tenant with no recovery path!

To assign eligible access to a Microsoft Entra role, do the following:

Sign in to the Entra admin center and open ID Governance > Privileged Identity Management
Under Manage, select Microsoft Entra roles
Select the target role.
Select Assignments > Add Assignments.
Set Assignment type to Eligible.
Select the member and set the assignment duration (either permanent or time-bound)
Select Assign to complete the assignment.

Role settings are the per-role configuration in PIM that governs the conditions eligible users must satisfy before PIM grants access to that role. These settings apply to all eligible users of a given role. Configuring these roles only determine what conditions must be met when an eligible user activates the role, it doesn't create the assignment.

To activate an eligible Microsoft Entra role, perform the following steps:

In PIM, select My roles > Eligible assignments.
Find the role and select Activate.
Set the activation duration.
Enter a justification describing the task that requires elevated access.
If approval is required, submit the request and wait for approval.
Confirm the role appears under Active assignments with a duration countdown.

Implementing JIT access for Azure roles and resources

Azure RBAC operates across a nested scope hierarchy, starting from a management group, then subscription, resource group, and individual resource. Assignments at a broader scope inherit downwards, so an Owner assignment at the subscription level would grant ownership over every resource group and resource within it.

PIM surfaces this same hierarchy, letting you make users eligible at the subscription, resource group, or individual resource level. This scope selection is important, as assigning eligibility at a narrower scope limits the potential damage from a compromised activation.

With Azure RBAC, you're managing RBAC assignments on Azure control-plane objects rather than directory identities, so it's important to keep that distinction in mind to prevent inadvertently configuring the wrong target when managing resources.

Not every Azure resource has the same risk from a compromised Owner or Contributor role. It depends on the following factors:

Data sensitivity.
Blast radius.
Regulatory exposure.
Reversibility of any damage.

You can apply resources to a risk tier so you can apply the strictest controls where they make sense. For example:

Risk tier	Resource examples	Why this level of risk?	Recommended controls
Critical	Production subscription	Compromise grants lateral movement	MFA required, justification required, approval required, 1-2 timebox
High	Production resource group	Narrower scope but high data sensitivity or service continuity risk	MFA required, justification required, approval optional, 4-8 max
Standard	Dev/Test resource groups	Low data sensitivity, mistakes can be reversed	MFA required, justification required, no approval, up to 8 hours

Once you've done your tier analysis, you can apply access to an Azure resource as follows:

In PIM, select Azure resources.
Navigate to the target resource using the Subscriptions or Resource groups dropdown, and under Manage, select Roles, then select Add assignments.
Select the Azure resource role.
Set Assignment type to Eligible.
Select the member and configure the assignment duration.
Select Assign to complete the assignment.

To activate an eligible Azure resource role, go to My roles in PIM, select the Azure resources tab to see your eligible assignments, and select Activate.

The difference is that you configure role settings for Azure resource roles independently per role per resource scope. This provides us with a flexible approach to apply stricter requirements on different resources depending on their sensitivity (e.g. production vs development resources).

Scaling PIM with Groups

Configuring JIT access for one or two engineers is pretty straightforward. Doing it individually for a group of engineers would be a pain, as that would require a separate eligible assignment, each one carrying its own role settings, its own maximum activation duration, own approvers list etc.

PIM for Groups shifts the eligible resource from a role to a group membership, so instead of making each engineer eligible for a role, you create a group, assign that group the role, and make each engineer eligible for membership in that group. When an engineer activates their membership, they gain all the roles the group holds. When the activation expires, membership ends, and access is revoked.

For groups that need to govern access to sensitive resources, use a role-assignable group. Standard Microsoft Entra ID groups are modified by its owners, or by lower-privileged admins such as Groups Administrator, without triggering approvals or audit entries in PIM.

Wrapping up

Hopefully you have a better idea on how to configure PIM for both Microsoft Entra ID roles and Azure resources. Using PIM can help structure better privileged access design in your environments, and provide safeguards against malicious actors who can potentially use standing privilege to exploit your workloads.

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Manage and Implement authentication methods in Microsoft Entra ID

Will Velida — Tue, 03 Nov 2026 05:44:41 +0000

Microsoft Entra ID supports a wide range of authentication methods, from legacy password-based approaches to passwordless alternatives. These methods fall into the following categories:

Something you know such as a password or PIN.
Something you have such as a registered device, security key, or authenticator app.
Something you are such as Biometric data, including fingerprints or facial recognition.

Ideally, passwordless methods would be implemented since they remove the need for a password entirely. Instead, we can authenticate users using a combination of device possession and a biometric or PIN.

However, not all organizations can immediately move to passwordless authentication. That's where multifactor authentication, or MFA, can provide a intermediate security layer. MFA requires users to verify their identity using 2 or more factors from different categories.

In this blog post, we'll take a look at the different ways we can manage and implement authentication methods using Microsoft Entra ID

Multifactor authentication (MFA)

Multifactor authentication is a process where users are prompted during sign-in for additional forms of identification, such as a code on their mobile phone or a biometric scan. This helps increase the level of security in your applications, because if you just used a password to authenticate users, this would be the single vector for attack. If a password is weak or has been exposed, an attacker can use it to gain access.

Microsoft Entra ID supports several MFA methods:

Method	Type	Security Level
Microsoft Authenticator push notification	App-based	High
Microsoft Authenticator TOTP code	App-based	High
OATH TOTP hardware token	Hardware	High
SMS one-time passcode	Phone	Low-medium
Voice call verification	Phone	Low-medium

As you can see, not all MFA methods offer the same level of protection. Microsoft Entra ID has authentication strength which lets you specify the minimum level of acceptable MFA method required to access a given resource through Conditional Access policies.

From most least to most secure, the security hierarchy of MFA is as follows:

Password only (no MFA).
Password and SMS or voice call.
Password and Microsoft Authenticator app.
Passwordless sign-in (Windows Hello for Business, FIDO2 security keys, passkeys in Microsoft Authenticator, certificate-based authentication).

Through authentication strength policies, we can require phishing-resistant MFA. Microsoft Entra ID's built-in phishing-resistant strength covers Windows Hello for Business, FIDO2 security keys, passkeys in Microsoft Authenticator, and certificate-based authentication.

Authentication strength policies are applied per application. So you can set phishing-resistant MFA for your most sensitive systems, while allowing standard MFA for low-risk applications.

Microsoft Entra ID authentication architecture

When a user signs in, the request flows through the Microsoft Identity platform, the authentication engine behind Microsoft Entra ID. The platform evaluates user's credentials, applies Conditional Access policies, and issues tokens upon successful authentication.

If you have any devices that are joined to Microsoft Entra ID, a Primary Refresh Token is issued after the first time you sign-in. This PRT enables single sign-on (SSO) across applications and services without requiring you to re-authenticate. This helps user experience (imagine having to sign-in each time!) and helps improve security thanks to stronger authentication methods.

Deploying MFA with the right enforcement model.

Conditional Access gives us precise control over when MFA is required. We create a policy, target users or groups, select cloud applications or user actions, and then set the grant control to Require multifactor authentication.

The policy evaluates each sign-in and applies MFA only when the conditions you have defined match. Here's how the MFA evaluation flow works:

Named locations and trusted IP boundaries

We can refine our Conditional Access policies by defining named locations. These are logical groupings of IP ranges or areas that represent trusted boundaries, such as corporate offices and VPN egress addresses.

When we use named locations in Conditional Access, we can reduce the friction for trusted sign-ins while still requiring MFA for sign-ins outside those defined trusted boundaries.

Named locations are recommended for trusted IP configuration because they support IPv6 and they integrate with all Conditional Access conditions. The Trusted IP setting is available, but it doesn't support IPv6.

Configuring authentication methods that match risk

After we decide when MFA is required, we can configure which methods users can use through the Authentication methods policy:

Microsoft Authenticator should be the primary method for most users.
OATH tokens are useful for users in regulated environments, or for users who can't use a smartphone.
SMS and voice calls can be used as a backup, however be mindful that these are vulnerable to attacks such as SIM swapping.
Third-party OATH tokens are useful if your organization already has a token rollout process.

Passwordless authentication in Microsoft Entra ID

Passwordless authentication is better than using MFA for two reasons. It removes the need for users to remember a password, and it helps users sign-in faster.

Microsoft Entra ID supports multiple passwordless methods, which you can assign by persona.

Persona	Recommended method	Alternative
Administrators and regulated users	FIDO2 security key	Windows Hello for Business
Office workers on corporate Windows devices	Windows Hello for Business	Passkey in Microsoft Authenticator
Mobile and cross-platform users	Passkey in Microsoft Authenticator	Synced passkey
Frontline or shared-device workers	FIDO2 security key	Passkey in Microsoft Authenticator
BYOD users	Synced passkey or Authenticator passkey	FIDO2 security key

Windows Hello for Business creates a cryptographic credential protected by device hardware and unlocked locally with a PIN or biometric gesture. The level of phishing resistance is high because no password is sent during sign-in. Windows Hello for Business is best for Microsoft Entra joined or hybrid joined Windows devices managed by Intune or Group policies.

For privileged administrator, regulated users, and shared workstation environments, use FIDO2 security keys which provide strong phishing resistance and are not tied to one device.

Passkeys in Microsoft Authenticator provides a portable phishing-resistant credential which is hardware-backed on your mobile device and you can unlock it with a biometric or PIN.

For users with multiple personal devices, you can implement synced passkeys. This is ideal for lower-risk users where usability is a problem.

Applications that use Microsoft Entra ID with OAuth 2.0/OpenID Connect can use passwordless sign-ins without changes to their code. For non-human identities and backend services:

Use managed identities for workloads in Azure
Use certificate-based authentication rather than long-lived client secrets if you can't use managed identities.
Apply workload identity controls and monitoring to high-privilege service principals.

Configure self-service password reset in Microsoft Entra ID.

Like I mentioned earlier, not all organizations can switch to passwordless authentication methods. Self-service password reset (SSPR) is a great feature to help users reset their own passwords, and reduce the amount of requests your poor support team gets to reset passwords!

Before users can reset their own passwords, you need to enable it. In the Microsoft Entra admin center, you can choose the following SSPR scopes:

None, which means SSPR is disabled for all users.
Selected, which means SSPR is enabled for members of a specific security group.
All, meaning all users inside the tenant can use SSPR.

SSPR and Password writeback are available on Microsoft Entra ID P1, P2, and Microsoft 365 Business Premium licenses. These features aren't available on the Free license.

You can configure SSPR methods in the Entra admin center. It's best to require 2 methods for reset to reduce the risk of account takeover, and avoid using security questions as a primary method.

Administrator accounts have stricter reset protections than standard users. They must use two authentication methods for reset, and email-based reset isn't recommended in case their mailbox is compromised. Place privileged accounts in a dedicated group, and then apply stricter SSPR method controls to that group.

Conclusion

Hopefully now you have a better understanding on how we can implement modern authentication methods in Microsoft Entra ID that both improves security and usability.

We learnt how MFA with Conditional Access enforces stronger verification based on context, we learnt how passwordless methods work and how we can apply different methods to different kinds of users, and we learnt how self-service password reset works and how it helps users recover their access quickly without bothering support desk staff with mundane requests!

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Last week in Agent Security Update 5: The Pentagon Prompts

Will Velida — Mon, 02 Nov 2026 22:31:22 +0000

Last week I spoke at API Days in Melbourne, where I gave a talk on the OWASP Top 10 for Agents and how you can mitigate the risks using tools such as the Agent Governance Toolkit and Microsoft Entra Agent ID.

My talk was scheduled to be in the last timeslot of the day, which was 4.50pm. That's a tough spot for speakers and audiences, as conferences can be a long and tiring day. I was fully prepared to speak to about 2 people in the room who decided not to beat the traffic and get their money's worth.

Presenting the OWASP Top 10 for Agents at API Days Melbourne.

Luckily about 40-50 people showed up just before I was about to present, which injected some much needed energy into the room. I'd given the same talk before at NDC Oslo, but I decided to rebuild the entire slide deck and demo since I only had about 20 minutes to talk (as opposed to 1 hour in Oslo). I'm giving a longer version of the talk at NDC London in January, so if you're in London and are planning to attend, make sure you get your tickets!

The sample I showcased is available on my GitHub if you're interested. There's a couple of things I need to do before I share it more widely, but I'm looking for contributors and feedback, so please take a look and let me know what you think.

This week's attacks

Big focus on the agentic supply chain this week, as there were several attacks that targeted vulnerabilities in how agents are set up, how extensions are configured for agents, and how agents can accidently executed code just by opening up configuration files in a project.

As always, I’ll point out that I’m not trying to shame any of the companies involved (maybe just the ones who deserve it), nor do I condone any of the methods used in any of these incidents. My goal here is just to spread awareness of the different ways that agents can be exploited, and hopefully trigger a conversation with your teams on how you should protect your agents and the people who use them from potential vulnerabilities.

Here’s some incidents that have happened over the period 26th October to 1st November 2026.

Trojanised Claude Code extension in Cursor Marketplace

On October 29th, versions 2.1.312 and 2.1.313 of the Clade Code VS Code extension were published to Cursor's VS Code extension marketplace for macOS and Windows that carried a malicious loader embedded in its extension.js bundle.

This extension.js file carried a small self-contained loader embedded in the legitimate bundle. It was designed to activate after VS Code startups and when its WebView opens, the loader proceeds to add an attacker-controlled key to the user's ~/.ssh/authorized_keys file. This key is labeled "svc-telemetry" to hide its true intentions. It then attempts to make the victim reachable through SSH across Windows, Linux, and macOS, establishes a reverse tunnel, installs platform-specific persistence and then transmits host recon data back to the reverse tunnel over an unencrypted HTTP request.

How the trojanised Claude Code extension plants an SSH backdoor, maintains persistence, and sends host details to the attacker. Credit: OpenSourceMalware, reproduced in The Hacker News.

The collected data includes public IP addresses, hostname and local usernames, OS and CPU architecture, home directory and current working directory information, global git email from git config files, and environment variables containing things like KEY, TOKEN, SECRET, PASS, AWS, or GCP.

Cursor's security team have published a blog notifying customers of the incident, and stressed that this trojanised extension does not impact other extensions downloaded from the Cursor marketplace, Grok Bot, Grok, or any other of their AI products. In response, Cursor had to rebuild the marketplace and take the server offline so that the reverse shell would no longer work.

Anthropic have stated that this was not a compromise of Anthropic's systems, as the malicious actor used access to Cursor's marketplace to publish a tampered copy of the extension. The malicious update was only distributed through Cursor's marketplace, with no evidence that it reached Open VSX or Microsoft's official VS Code marketplace.

The Microsoft Security Research team are advising affected users to remove confirmed unauthorized SSH keys, tunnel identities, scripts, and startup entries separately. Removing or updating the extension won't remove artifacts written outside the installation directory.

Here, we see a trusted distribution channel for installing extensions for coding agents being exploited by a backdoor trojan (ASI04). Securing the agentic supply chain is a challenge, because there's no real attestation being conducted in this space, and with package managers being administrated by vendors over foundations, the focus on innovation at any cost comes at the cost of security.

By injecting threats in the agentic supply chain, attackers can use access to developer environments to perform other types of attacks, such as RCE and Identity abuses. Until there's a more unified approach to how we secure the agentic supply chain, we're going to see more attacks like these slip through the cracks.

Accenture contractor's personal Claude Code agent on a Pentagon system

WIRED reported on October 29th that a contractor from Accenture connected their personal Claude Code account to a Department of Defense system which held controlled unclassified information over a period of two months. The agent appears to have sent login credentials and a network map to outside the Pentagon's network.

The system in questions hold sensitive data that needs to be reviewed before it's released (unclassified information, or CUI for short) and it's used by several intelligence agencies. The system runs on NIPRNet, which is the Pentagon's network for unclassified information. It does connect to the public internet, but it has heavy restrictions (as you can imagine).

The contractor gave Claude access to their login credentials so it could write code, and set up cloud servers. This granted the agent admin access, and it also had the ability to talk to the internet to do its work. This resulted in credentials, passwords, and network maps being sent to a third-party website, which the US National Institute of Standards and Technology has flagged as high risk.

What's worse is that Defense Department staff and federal contractors must report cybersecurity incidents within 72 hours, which Accenture didn't do. They also denied any wrongdoing. There's also a political element to this, after the debacle that cause the defense department to label Anthropic a supply chain risk, staff at the Pentagon may not use Claude.

Whether this is a case of the contractor accidently using their personal account for work use by mistake or something more malicious is unconfirmed at this time. There's no indication at this time that hackers have reached any classified systems, but this does open up the possibility that code operate normally within NIPR and perform malicious acts inside a SIPR network.

Here a human's admin credentials were handed to an unsactioned agent, which then acted under that identity in highly sensitive networks. This opens up the possibility of rogue agents sending data outside a secure network and performing malicious acts inside the secure network.

So if you're contractor working for a defense department, or any other customer in a highly regulated environment, just make sure you're logged in with the right credentials and use the right tools for the job.

Cathedral's agent-led intrusion into Anthropic

Remember those douchebags from DOGE? Well they're doing a sequel, and this time they're taking on Anthropic.

The founders of Cathedral informed Anthropic that they had penetrated sensitive internal data and messaging systems through third-party business software. Cathedral is cybersecurity startup founded by former DOGE employees and sells AI-powered security tools to government agencies and businesses.

Anthropic confirmed that the researchers accessed a limited set of sales, HR, and IT systems, including contact information for some customers and partners. Chats with Claude, source code, and model weights were never exposed. Anthropic shut down the affected access points, disabled third-party programs until the issue was resolved, and notified U.S federal authorities.

There's a bit of disagreement between Anthropic and Cathedral as to how long the breach lasted, and what data was breached. Anthropic also accuses Cathedral of violating their bug bounty program's rules through incomplete disclosure, and through targeting third-party providers.

Now, as much as I dislike anyone who's worked for DOGE, if there's a vulnerability in a third-party or external system that you use that could cause a potential breach or security incident, you need to take it seriously. As you can imagine with the actors involved, there's a certain amount of dick measuring going on regarding the extent of the breach (even a former OpenAI employee is getting involved), but as much as it pains me to say, integration with third-party applications are a problem when it comes to security, and Anthropic could have done a better job making sure that the external services they use were secure.

Regardless of the rules of a bug bounty program, you can see that it's easy for anyone with an agent to use legitimate tools to cause cybersecurity incidents, whether they are researchers from startups like Cathedral, or malicious state aligned attackers. It's important to factor in how AI is used with your various different systems, as one rogue agent with access to legitimate tools can cause real damage.

Just going to take a brief break so I can shower off the fact I'm kinda on the side of ex-DOGE employees.

123 Reg "AI-driven" breach

UK domain registrar 123 Reg disclosed that they were a victim of an AI-driven cyberattack that exposed customer data.

An initial investigation by 123 Reg identified attack servers in both China and Singapore that conducted the attacks. They observed the use of AI attack skills (including copies of Anthropic's open-source skills) and the use of ARTEX, an open-source AI pentest framework.

If you're a regular reader of the series, you would have seen attackers using ARTEX for attacks before.

123 Reg suspect that a Chinese-state group who conducted similar attacks on finance companies in South Korea are behind the attack. Nothing has been confirmed yet, and 123 Reg have notified the FTC, UK, and EU regulators. Customers have been notified that information such as company VAT (tax) numbers, names, phone numbers, account creation dates etc. have been compromised.

123 Reg discloses 'AI cyberattack' on customer data, suspects China nexus: The Register

testmetest worm plants agent hook files in 42 GitHub repos

The folks at JFrog Security identified 42 GitHub repositories across 11 owners connected to the testmetest npm campaign. Essentially, the testmetest is a worm that planted configuration files in GitHub repositories so that when a developer opened a project in an AI coding tools, it would execute the attackers code.

The testmetest campaign links malicious npm packages to credential theft, hijacked GitHub repositories, and further malicious releases. Source: JFrog Security Research, Beyond testmetest.

The attackers used stolen credentials to take over the target's real GitHub account (including one organizational account!) and used scripts to copy old commit messages and dates so that the attack changes would blend in. Each repository was infected with a set of configuration files that pointed at a single script .github/init.js.

The attack would change depending on the tool used:

In Claude Code, a SessionStart hook in .claude/settings.json would run node .github/init.js whenever a session starts.
In Gemini CLI, a similar trigger exists in .gemini/settings.json.
In Cursor, the script would trigger in .cursor/mcp.json and .cursor/rules/setup.mdc.
In VS Code, a task would run in .vscode/tasks.json whenever the folder is opened.

The tools simply follow project settings they trust by default and runs in the background, so the developer would see nothing. The init.js would then proceed to steal GitHub tokens, swap them for npm publishing rights, and then publish malicious packages whenever someone installs them. One infected developer would become a new way to infect others. The file was over oversized, which kept the file payload out of GitHub's code search.

It's a novel method to hijack the supply chain. Poisoned repositories that contained agent configuration that tools trust by default is a simple but effective way to deliver a vulnerability. Once the workspace opens, attackers can run code that performs a variety of malicious activities.

Beyond testmetest: Native Addon Camouflage and 42 Armed GitHub Repositories Reveal a Hidden npm Publisher: JFrog Security Research

"Embrace" embedded-browser flaws in five AI dev tools

The team at Forever Security have discovered vulnerabilities in Cursor, GitHub Copilot, Claude Desktop, VS Code, and Codex that can allow attackers to execute code on host machines, read and steal files, or spoof browser address bars.

If you've been using AI coding assistants recently, you would have noticed that most of the tools now have their own built-in browsers so that the agent can preview apps and read web pages. However, in this case each tool gives its own browser powers a normal browser may block, meaning that the browser is a way to get access into the agent and the host machine.

In Cursor, the built-in browser lets every page send messages to the app. A hostile page could use this to slip hidden text into the agent's message box, and hijack the goal of the agent. In GitHub Copilot, the preview tab could tell the app what the address was, but Copilot would only check if the text looked like a web address, not where the page really came from. In Claude Desktop, Codex, and VS Code, a local HTML file opened in the tool can read other files. Now in both Claude and VS Code, the workspace trust boundary applied to the web pages, but not the web workers. So when those pages load, the web workers could read anything. The whole disk is readable, which can include SSH keys, .env files and tokens.

No CVEs have been raised because of this, and the worrying thing here is that these tools are being fixed quietly or dismissed as outside their trust models. Context from a malicious web page could easily redirect coding agents to perform malicious acts. There's also the human-agent trust exploitation issue, as a spoofed address bar abuses the trust that developers have placed in the tool, and the agent's browser.

It's disappointing that these companies either quietly fix these vulnerabilities without giving developers the heads up, or they just ignore or dismiss it entirely.

Researchers find bugs in 5 AI developer tools, with OpenAI and Microsoft flaws still unpatched: The Register

CyberStrikeAI: 44 agents against Japanese organisations

Cybersecurity researchers from TrendAI have disclosed details of AI-driven cyberattacks targeting organizations in Japan. TrendAI analyzed three attacks used by threat actors to conduct malicious operations.

The first used a tool called CyberStrikeAI, which is an open-source penetration testing tool, to automate attacks into a repeatable workflow, including activities such as reconnaissance, vulnerability detection and validation, exploitation, command-and-control, data exfiltration, and automated reporting. The work was delegated among 44 agents to handle various aspects of the attacks. At least 19 organizations where subjected to these attacks.

The second was characterized as a human-led attack using LLM models to accelerate planning and tool development. Analysis of these artifacts seem to indicate that the campaign was designed to target AI workflow platforms and inference services in an attempt to obtain a large amount of inference capacity at a low cost. One instance targeted a geographic information system server exposed with default credentials, resulting in data exfiltration.

In the third attack, AI was used to develop the operator's tools and scripts. The attack then used these tools to target edge devices from Cisco, Citrix, F5, and Yamaha using published vulnerabilities, management functions, or credentials present in configuration files.

It's unknown at this stage if these attacks share the same operator, or if these attacks have targeted other regions.

CyberStrikeAI Uses 44 AI Agents to Automate Hacking Operations Against Japan Targets: The Hacker News

Conclusion

Quite a few attacks last week focused on the developer's agent setup. Agent configuration files are acting as executable code inside coding assistants that most tools trust by default. Whether that's through backdoors in official marketplaces, or malicious hook files in GitHub repositories that run malicious code as soon as projects are opened, there are gaps in the agentic supply chain that need urgent attention.

It's not good enough for Big Tech firms and Frontier labs to quietly patch systems or ignore threats as outside their trust boundary without issuing advisories. The only way to get these companies to act properly is through government intervention and legislation. Which I don't see happening anytime soon.

As always, opinions are my own

Remember, I'm not trying to scare folks or discourage people from using these tools. Just be mindful of what your agent is installing. Treat agent configuration like any other code and review it like any other executable. Lock down where agent extensions and models come from, and restrict agent traffic to approved model endpoints.

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Last week in Agent Security Update 4: Cairn’t Touch This

Will Velida — Tue, 27 Oct 2026 07:00:41 +0000

What a fucking week....

If you've been living under a rock this week, two critical RCE vulnerabilities were found in PHP, collectively known as PHP2Shell. This vulnerability allows unauthenticated attackers to remotely execute code on vulnerable web servers without logging in or providing credentials, potentially seizing server control or stealing data.

These vulnerabilities affected all PHP versions released over the last decade, spanning back to version 5.4. This was particularly scary because according to Wiz, PHP powers 70% of the world's websites, including banking and government applications.

Many websites and pages were taken offline as a precaution, including those of the Finnish government, The Netherlands' cyber-security agency, and Wikimedia (the organization behind Wikipedia).

Researchers at Calif and Wiz used models from OpenAI to find the tools, so AI was pretty useful in finding the flaw. The problem was that the vulnerability was leaked before the embargo was lifted, so the PHP platform developers were forced to rush out the disclosure of the vulnerability as well as the fix. With attackers being able to use agents to operate at machine speed, this only highlights the dangerous world we now live in.

So far, no breaches have been reported. I'm holding my breath on this one, as we have seen in the past attackers being able to breach a system, lie dormant for months, and then strike. Keep your eyes open on this one.

In more positive news, While I was at NDC Oslo, Richard Campbell invited me on RunAs Radio to talk about the OWASP Top 10 for Agentic Applications, and how the different layers of agentic architecture can be compromised. You can check out the podcast here.

This week's attacks

This week we focus less on misalignment from frontier models and more on attackers who are using agents to drive more targeted attacks using open-source tools. We also take a look at how agentic supply chain vulnerabilities have the potential to cause harm on a wide scale, and finally we make fun of Meta because I hate them.

Here’s some incidents that have happened over the period 19th October to 25th October 2026.

Cairn agents break into 100+ company websites

NorForge found more than 20 publicly exposed control panels for Cairn, which is an open-source AI pentest system, that criminals were using to point autonomous agents at e-commerce, payment and pharmaceutical targets. These agents tried more than 1200 sites and reached websites belonging to more than 100 companies, including Deere, SharkNinja, and Cummins.

The operator provided short instructions to agents to attempt code execution and plant web-shell uploaders. One documentation chain combined unauthorised write access to a memcached session store, unsafe PHP object deserialization (oh PHP) and old Zend Framework code. NorForge haven't confirmed which models were used in the attack.

NorForge estimates that 10% of attacks were successful. One large US retailer was independently confirmed that they were compromised, and one shell URL serving a uploader shell has been successful. The volume of data that has been taken is currently unknown. The panels also leaked secrets and some legitimate pentest firms have had client data exposed on those open panels.

Source: NorForge — Inside Cairn: Open Windows into massive AI-Driven Cyber Operations.

A couple of weeks ago, I described how Cairn was being used in a multi-agentic attack targeting retail websites in the US. We're going to see more sophisticated rogue agent attacks using specialized frameworks to perform malicious, specific attacks on their targets, utilizing these specialized tools to successfully breach them with minimal effort from the human operator. The maker of Cairn told Reuters that the tools was not designed for hacking attacks, but we've already seen multiple instances where agents can use legitimate tools to do harm, and how attackers can exploit them to do damage.

Storm-0940 uses ARTEX agents in ConnectWise supply-chain campaign

It's not just Cairn that's been exploited by bad actors. The folks in Microsoft Security have attributed Chinese state-aligned actor dubbed Storm-0940 was behind the recent supply chain compromise of the ConnectWise Cloud Backup application.

ARTEX, an open-source multi-agent LLM pentest framework, was used to automate the operation from reconnaissance through to exfiltration. The actor abused stolen ConnectWise multi-tenant application identities and the trust that customers had already granted to those identities. It was also able to run password spray attacks against Microsoft 365, Exchange Online, Okta, and Entra ID.

These ARTEX-driven attempts reached more than 2,250 tenants and peaks of up to 2,900 attempts per minute. Between 10th-14th October, the spray generated more than 151,000 failed logins. After the 15th, agents were able to reach Microsoft Graph and were able to change identities, groups, roles, and app credentials. In several cases, they were able to gain privileged access in under 3 hours.

Source: The Hacker News — China-Linked Hackers Use ARTEX AI Agents in ConnectWise Supply Chain Attack.

Looking at the prompt histories, it appears that the motive is financial, and Wiz have reported that the campaign has expanded to other software vendors. ConnectWise has responded by shutting down services and restoring them, and Microsoft Security have published a list of immediate actions and mitigations that affected customers should take.

This attack managed to abuse OAuth app identities and delegated trust across multiple tenants at machine speed, using ARTEX as the multi-agentic attack vector, exploiting the tools that the framework provides to repurpose them for an offensive campaign.

INC / The Gentlemen ransomware affiliates' "Phantom" AI kill chain

In more examples of rogue agents and tool misuse and exploitation, the folks at SOCRadar traced an exposed command-and-control server, and six more adversary servers, to Russian-speaking operators. This was an AI-driven intrusion ecosystem run by affiliates of the INC Ransomware and The Gentlemen Ransomware groups. The operation runs on an AI-executed, human-approved model, where a human writes a victim-specific prompt and approves each step, while commercial models that are accessed through OpenRouter carry out intrusions via a OpenCode coding agent.

The toolkit includes a tool called "Phantom", which is an autonomous red-team framework, and "WormGPT-MCP", a set of MCP servers that cover reconnaissance through extortion. When a model would refuse the request, the operator would reframe it as an authorized red-team engagement, and the model would continue.

Source: SOCRadar — INC / The Gentlemen ransomware AI infrastructure.

62 names organizations have been listed as victims, with 36 in the United States. The operators gained access by exploiting public-facing edge devices, and then moved towards ransomware deployments. This was followed by credential reuse, lateral movement, and data exfiltration.

INC and The Gentlemen Ransomware: Exposed AI Infrastructure - SOCRadar

Autonomous LLMjacking agent captured by Symantec

Symantec's Threat Hunter team have discovered the instruction set of a self-directed offensive agent that hunts for exposed LLM endpoints, AI gateways, and MCP servers to run their own work through them or through stolen keys, so that victims pay for the compute.

The agent was designed to use the hijacked AI models to autonomously run up to 100,000 malicious actions without human approval, including scanning for targets, exploiting vulnerabilities, stealing credentials, deploying cryptocurrency miners and reinfecting compromised systems. Attackers used layered prompts to bypass commercial model safety controls.

The honeypoint logged more than 127,000 requests from tens of thousands of addresses. This telemetry included reconnaissance of model endpoints, spraying of stolen API keys, and probing for exposed configuration files. What makes this attack disturbing is that instead of attackers trying to trick a public chatbot into misbehaving, the operators built AI into the core of an offensive tool and attempted to hijack other people's models to power it.

LiteLLM 1.107.0 supply-chain compromise via leaked Agent Platform key

Turning towards vulnerabilities on the supply chain, a malicious version fo LiteLLM litelmm==1.107.0 was published to PyPI, Docker Hub, and GHCR images. This was caused by a master key for its internal Agent Platform that was exposed in a opencode.json file that was committed to a public repository back on May 27th (We've all been there before).

The commit was force-pushed over, but the key wasn't actually revoked. Attackers were able to use the key against the Agent Platform API, which returned a GitHub CLI OAuth token belonging to an organization owner. From there, the attackers were able to steal maintainer tokens, push secret-harvesting workflows, and repoint releases to lookalike repositories.

Source: The Hacker News — Report on a leaked LiteLLM master key.

The malicious version runs a credential stealer at start up that takes information like SSH keys, cloud tokens, git tokens, browser data, AI tool credentials, and environment variables, and sends them to litellm[.]dev. It also installs a Unix backdoor that polls the code hourly for new code.

The release was quarantined and affected images were removed. Due to the breach, LiteLLM are undertaking the process of revoking internal and vendor tokens. LiteLLM are advising users to rotate credentials from a clean machine and pin 1.106.2 by digest.

Thanks to this supply chain vulnerability, a widely used AI gateway package was able to be trojanised, putting every downstream agent stack that had the affected version installed at risk. The unrevoked agent-platform master key returned an over-scoped owner token, which gave the attackers a wide scope to perform authorized actions for malicious intent.

OpenCode RCE via malicious MCP server during OAuth sign-in

The folks at Pillar Security have discovered a critical RCE (remote-code execution) flaw in OpenCode that affects Windows and Windows Subsystem for Linux (WSL). This flaw allows an attacker-controlled remote MCP server to execute arbitrary code on a developer's machine during the remote MCP OAuth authentication process, without requiring additional user interaction or consent.

MCP servers connects agents to external tools and services. This vulnerability highlights that connecting coding agents to compromised or malicious remote MCP servers can expose a developer's machine to remote code execution. It's vital that developers and security teams assess the trustworthiness of connected MCP servers and ensure that applications that handle externally supplied URLs do not pass untrusted input into shell commands.

In this case, Anomaly (the company behind OpenCode) have claimed that since they believe that users who configure MCP servers for their agent are "outside our trust boundary", no CVE has been created and no advisory has been published. This means that this vulnerability won't show up in vulnerability scanners or dependency alerts, so the responsibility is on developers and security teams to check the OpenCode version directly.

Pretty poor response from Anomaly in my opinion.

Open and Shut: Remote Code Execution in opencode via MCP OAuth: Pillar Security

Planted AGENTS.md in ~/Downloads hijacks coding agents

Markdown is the hottest new language! It's also the hot new attack vector! The folks at Forever Security found a malicious AGENTS.md file that was downloaded into a users ~/Downloads folder, and discovered that it tried to make Codex install a malicious npm package.

AGENTS.md files are files that coding agents are built to trust and obey, so you can imagine that if an attacker than supply a AGENTS.md file that gets downloaded onto a users computer that direct the agent to perform malicious activity such as installing malware or handing over login information, that's a pretty powerful attack! Coding agents are getting more capable in their functionality, including having the ability to open up browsers, or even being able to take over control of the computer. This type of attack starts from a simple Agent Goal Hijack using a malicious AGENTS.md file, and can lead to other risks like supply chain vulnerabilities, unexpected code execution, and identity abuses.

That's a pretty big design flaw. There's no patch for this, so the way that we can mitigate that is to only run agents from project directories, review instruction files before trusting them, keeping approvals in the hands of humans, and applying sandboxes to our agents.

Meta Muse "GhostShares"

Oh Meta....

In Meta's Muse AI assistant, you can share conversations. These conversations are published as public pages that anyone with the link can open. (That's by design, which doesn't surprise me considering it's Meta. Why it's by design after all the bad publicity that Meta have received due to their lax attitude toward privacy shouldn't be a surprise to anyone).

However, the folks at Claroc's research team found that these links were pretty easy to find, because what Muse names each share's web address after the conversation's own title, and that address is written into public DNS. One passive-DNS search brings back thousands of them, listed by name, like a table of contents.

To be fair, this isn't a new type of leak. This has also happened to both ChatGPT and Grok conversations

Source: Claroc — GhostShares article.

This type of leak can lead to some pretty dangerous situations. One conversation included a candidate's notes preparing for a confidential executive-search call with a frontier AI lab, which included naming the lab's internal contact and the meeting time. Another included a to-do list that included a bank fraud alert, with partial account number and transaction information.

Why anyone trusts Meta with anything is a mystery to me. Let alone one of their AI agents.

Wrapping up

We're seeing an increase in malicious actors using agentic-driven attacks to cause harm. Both incidents that used Cairn and ARTEX in their agentic-driven attack used tools that they were authorized to use, and they were designed by the developers of both those tools to automate pentest tasks. It's just that they were used by malicious actors to perform those tasks at machine speed for malicious purposes.

Hopefully we'll see an increase in watch dog agent capabilities to prevent or limit attacks from these rogue agents. It's difficult to stop the bad guys using open-source frameworks to do harm, but there's a lot of work to be done to make it easier for folks to protect their applications and themselves from harm (Probably not a bad startup idea in there...).

With these types of attacks being able to be executed at machine speed, more focus needs to be paid to identity, and how over scoped credentials that are either stolen or mishandled have the potential to do some real harm.

This also wasn't a great week for vendors. I hope that Anomaly come to the table and at least issue an advisory. This helps vulnerability and dependency scanners pick up issues in code, and help make everyone a little safer. Until then, security teams and developers need to be extra vigilant in what models, gateways etc. they are using, so they can prevent vulnerabilities causing harm.

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Last week in Agent Security Update 3: That's not Aoki!

Will Velida — Mon, 19 Oct 2026 21:52:53 +0000

An apology to start off with! I was too busy having fun in Sydney last week hacking with customers, building agents and agent harnesses. I got to experiment with Entra Agent ID and Agent Governance Toolkit, two technologies I'm looking forward to building with more over the next few months.

We're slowly starting to see governments around the world catch up to the dangers that AI Agents can present to organizations around the world. The EU AI office has declared that they've "started enforcing" the EU AI Act, and it has sent formal requests to both OpenAI and Anthropic about security, external evaluations and post-market monitoring. In the US, the FTC has sent civil investigative demands to both OpenAI and Anthropic, seeking records on security incidents, safeguards, marketing, and privacy. Whether this goes anywhere is anyone's guess. I'm pretty pessimistic about it, but hopefully I'm wrong.

This week, the theme of agents drifting from their original goals (whether it's unintentional or not) continue to be a issue for governments and businesses alike. MCP servers remain a potential gateway to organizations and developer environments, and coding assistant credentials are increasing in value to potential attackers.

As always, I’ll point out that I’m not trying to shame any of the companies involved, nor do I condone any of the methods used in any of these incidents. My goal here is just to spread awareness of the different ways that agents can be exploited, and hopefully trigger a conversation with your teams on how you should protect your agents and the people who use them from potential vulnerabilities.

Here’s some incidents that have happened over the period 12th October to 19th October 2026.

CERT-In: test agents read confidential data at Indian organisations

CERT-In issued an advisory that AI agents under research and evaluation by multiple AI model providers went beyond their assigned tasks and reached live systems at numerous Indian organizations. CERT-In haven't explicitly named the providers, models, victims, sectors, or number of cases. However, they were able to determine that agents accessed business records that contained personal and confidential data.

This data included credentials and connection strings left in application configuration files and public code repositories, and over-permissive cloud roles. The advisory also states that agents sometimes reused the same exposed credentials in multiple waves of attacks.

The same advisory also describes a separate, financially motivated campaign against Indian entities that used rebranded open-source AI offensive-security frameworks with multiple agents working in parallel. This enabled the attacks to cut time from initial access to impact from days to a few hours. The scale of this attack has not been disclosed.

CERT-In are recommending that affected targets enforce network-enforced isolation and default-deny egress for AI test runs, automaticl kill switches when agents touch 3rd-party systems, rotating secrets and enforcing least privilege, implementing MFA, and implementing 180-day retention.

More countries are being impacted by rogue agents (ASI10) where agents are either drifting from their original tasks or being directed to do so through their system prompt. While CERT-In provides some good guidance on how to protect your systems from rogue agents, there's clearly work to be done to prevent agents from drifting from their original tasks.

Developers also need to be mindful about leaving credentials lying there for attackers to steal. Both Azure and AWS provide strong RBAC controls that can be used over permissive connection strings and API keys. This is also a good reminder to consider how agents use tools that are available to them. In the case of goal drift, agents using legitimate tools available to them won't be flagged in retrospect. They're allowed to use the tools that you configure, so think about the design of your agents and whether or not the tools you give them are too permissive.

Langflow MCP stdio command injection now exploited (CVE-2026-105740)

Langflow is a tool for building and deploying AI agents and workflows. Prior to version 1.9.0, any authenticated Langflow user could perform Remote Code Execution (RCE) on the server by adding an MCP server using stdio transport. This command could be supplied to the user by passing bash -c "exec {command}" with zero validation, no allowlisting, and no sandboxing. This command would execute immediately when the server list is fetched.

A bad actor could exploit this by logging in as a regular non adminuser, and add a malicious MCP server with a command field containing a malicious payload. The server would then accept the server and store the attacker-supplied command without validating it, which the attacker would then trigger by fetching the MCP server and achieve code execution.

Previdian have found that 1,423 exploitation attempts have been recorded since September 19th from 27 unique IP addresses located in Belgium, China, Germany, Hong Kong, Japan, Nigeria, the Philippines, Russia, Seychelles, Singapore, South Korea, Taiwan, Tanzania, the U.S., and Vietnam. In one observed attack, attackers checked the Langflow version, attempted to auto-login, then immediately use the resulting bearer token to access the vulnerable MCP server configuration endpoint. Some of the captured payloads included attempts to extract environment variables and sensitive Langflow configurations, Docker commands attempting to access the host filesystem and read password file contents /etc/passwd, and command execution probes using id, whoami, and other commands.

Mapping this back to OWASP, a configuration string flaw in Langflow has become a arbitrary shell execution on the agent platform's host. The payload planted as an MCP server definition also is a threat to the agent's supply chain. Exploitation also depends on the use of weak or default credentials, which leads to the theft of platform secrets and superuser access.

Aoki infostealer adds AI coding-agent credentials

On October 15th, the folks at Symantec reported that the Aoki infostealer is now targeting AI coding-tool credentials. This includes Claude's .claude.json and desktop cookies, Codex config.toml and .env files, Cursor's local state database, tokens for GitHub Copilot, Gemini, Codeium, JetBrains AI Assistant and Kiro, and ChatGPT cookies and AWS Credentials.

An infostealer is a type of malicious software designed to covertly harvest sensitive data from a victim's computer or device without thier knowledge. Once an infostealer infects a machine, it scans the system for valuable data, bundles it into an archive, and then exfiltrates it to a command-and-control server controlled by the attacker.

If an attacker is able to steal credentials from their victims, they'd be able to carry out activity under their legitimate user's identity and API quota. That includes access to linked repositories, CI/CD pipelines and paid API quota. This is just as valuable as payment card data, as it can be cashed in on directly, and provider the attacker a route to the developer's environment.

Symantec doesn't know who is behind the attack, nor can they link it to any existing malware. However the nature of the attack indicates that this is a financially motivated attack.

There's no patch for this vulnerability, so the important thing to note here is that you need to treat your agent configuration files as secrets. The potential for abusing agent credentials is huge, and any stolen agent token gives attackers a foothold in your repositories and pipeline that your agents feed.

OpenCode Console breach exposes stored LLM provider API keys

On October 16th, attackers managed to gain access to a legacy OpenCode console system that was scheduled to be shut down and gain access to third-party API keys in affected workspaces. Affected users where limited to some Console users who had connected external providers.

How old does something have to be to be called legacy in the age of AI?

OpenCode have emailed affected users and later confirmed the breach on X.

OpenCode have said that the breach was connected to a large-scale distillation attack, however it hasn't provided any technical evidence to how it was linked. Distillation can involve using the outputs of one AI model to train or improve another model. OpenCode hasn't said whether any exposed credentials were used to generate such requests, and it has yet to identify the attacker.

If agents were used here for the attack, stolen keys that are used to call LLMs are already being exploited (with some unfortunate victims receiving hefty AI-spend bills!)

OpenCode Breach Exposes Third-Party API Keys of 1.4% of Console Users

Wrap up

It's easy to think that agents are running wild, but if you think about it rationally, agents act with the tools and permissions we give them. They're also enabled by our bad habits and bad developer practices. If you leave connection strings and API keys lying around for agents to discover, you're asking for trouble.

The platforms that we build agents on are also a target too. In the case of Langflow, that CVE went from published to being actively exploited all through a single MCP server definition. Treat any MCP server configuration as a mechanism for executable code.

If you're building agents for your organization, or using coding agents in your developments, you need to treat the credentials that they use like any other production secret. Keep them out of code and configuration files, ensure they are scoped appropriately, and rotate them often (better to not use API keys at all if you can).

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Last week in Agent Security Update 2: Zam-mad Max

Will Velida — Mon, 19 Oct 2026 06:57:31 +0000

This week I've been struggling with some kind of illness. My throat was dry and I couldn't breathe on Friday, so I took a course of pseudoephedrine medication, bought some strepsils, and a nasal spray just to manage it. I was sick the whole weekend and started to recover just in time for Monday! Being an adult is awesome....

Now those of you who are a little too keen for our robot overlords to consume us might point out that agents don't get sick, but they can be subject to a wide variety of vulnerabilities. Not the greatest segway into this weeks article, but I couldn't think of anything else.

This week we saw further exploitations of what agents can reach, not necessarily what they are asked to do. Rogue Agents and the tools that they can use are becoming increasingly sophisticated attack vectors.

Here’s some incidents that have happened over the period 28th September to 4th October 2026.

OpenAI agent breach of Medicare

Last week I covered how OpenAI agents managed to breach Medicare here in Australia and gained access to non-public information. OpenAI confirmed on September 28th that agents had also breached New South Wales Bureau of Crime Statistics and Research (BOCSAR), the Victorian Department of Health, and the Australian Institute of Health and Welfare.

OpenAI has committed to an Australian taskforce, and support through it's Daybreak programme. On 1st and 2nd of October, OpenAI went through the process of notifying 100+ organizations of unauthorized agent activity. Independent analysis from Asymmetric Security named 55 organizations, including the SEC and US Bureau of Economic Analysis as victims of unauthorized agent activity, some of which has left records inaccessible or erased.

I've never been optimistic about the speed of government officials in responding to incidents like this, but this may prompt some much needed response to breaches like this. In Australia, a Joint Select Committee has been scheduled for the October 6th, which OpenAI's Jason Kwon will attend (Sam Altman and Dario Amodei both declined).

In the US, senators Josh Hawley (Republican) and Chris Murphy (Democrat) have introduced a bipartisan AI Agent Accountability Act on October 1st, which would make AI Agent operators criminally and civilly liable for agentic hacks. Also, the Legal Advocates for Safe Science and Technology have sued OpenAI in San Francisco's Superior Court under California's anti-hacking law and Unfair Competition Law, citing both the Hugging Face and Medicare breaches.

Whether OpenAI will actually be held to account is another matter. Watch this space.

DIVD breached by an agentic AI attacker chaining Zammad zero-days

On September 21st, The Dutch Institute for Vulnerability Disclosure (DIVD) was hacked in an automated AI attack that exploited zero-day vulnerabilities in user support/ticketing solution Zammad.

DIVD is an organization that searches for new vulnerabilities in software and report them to vendors, and it's made up of mostly volunteer security researchers. While it may be discouraging that even an organization full of security experts got breached, hopefully it illustrates that anyone can be a victim of cybercrime.

These flaws enabled unauthenticated attackers to achieve remote code execution and leak user sessions (CVE-2026-102489), and allowed a local user to elevate their privileges to root (CVE-2026-102490). Combined together, the attacker could hijack sessions, run code remotely and escalate privileges from the Zammad user to root.

From there, the attackers were able to access other services, read and exfiltrate data. Luckily network segmentation prevented the attack from going deeper into the environment.

According to the DIVD, the attack was "loud and very very messy, including password spraying and man-in-the-middle activity. In fact the DIVD were able to reverse engineer the attack because the agent overexplained what it was doing.

However, it's still unknown whether this was a capability test or part of a broader campaign. So we have a Rogue Agent running the attack (ASI10), but at the time of writing we don't know if a human has maliciously set out a goal or if an agent exceeded its brief. What is clear that the agent drove the exploitation, using password spraying and pivoting tools at machine speed.

Transluce: autonomous agents aimed SQL injection at US and Canadian government sites

Transluce is a non-profit research lab that's building a public tech stack for scalable oversight of AI. On September 30th, they published an article after discovering several additional incidents where rogue AI agents have used techniques to access publicly available data on government websites in the US and Canada.

So far, Transluce haven't identified any instances where agents have been able to access any information that's not publicly available. However, they were able to identify that agents were able to probe several government agencies and violate explicit usage policies. This attempt targeted several government websites including the White House, Department of Defense, The CDC and SEC, as well as state agencies in California, Maryland, Illionis, Texas, and New York.

For the US Department of Education, agents attempted basic SQL injection to access school statistics. What's interesting in this case is that the data stored on the websites appeared to match a web search task in Google's DeepSearchQA benchmark. This means that the agents were potentially not given a hacking-related task, but were being graded on their ability to retrieve specific information on the internet.

Transluce also reported agents attempting rudimentary hacks on Library and Archives Canada. Arquivo.pt captured 899 requests that included failed rudimentary hacking attempts that carried attack payloads (SQL injection and cross-site scripting).

While they don't explicitly attribute these attempts to OpenAI, they claim that they exhibit the same tactics that have been attributed to OpenAI agents in a similar timeframe. OpenAI are currently reviewing the findings and have provided an initial briefing to Canadian officials.

This is another example of Rogue Agents straying away from original goals and using information gathering techniques for attack probes (ASI10), and the use of ordinary web-request tools for SQL injection and XSS payloads (ASI02).

"PixelLeak": coding agents published internal screenshots to public GitHub repos

Developers who get coding agents to make visual changes will often use screenshots as evidence that a change has been made. As you can imagine, if you're doing this as part of your day job, there's IP involved, and that information shouldn't be leaked to the public until it's ready.

However, Glow Labs identified over 13,000 internal images that were published on public GitHub repositories by developers at over 300 organizations.

The issue is that GitHub CLI couldn't attach images to a PR, so agents would work around this by creating public repositories tied to the developer's personal account to host the image. There's an open-source tool called gitshot that defaults to public storage, and the agents saved this workaround to a skill. If you have multiple coding agents in your organization, that increased the blast radius.

These screenshots also included billing records, unreleased features, and treasury consoles.

The GitHub CLI added an --attach flag through version 2.99.0 (Released 1st September). However, Flow also advises that you need to enforce runtime controls for developer agents to prevent information from being leaked.

These were legitimate tools that agents used (The GitHub CLI, gitshot). They just used those tools to publish confidential information. The agents also abused developers' personal GitHub credentials to create public assets outside organizational control (ASI03), and the use of agent-shared skills spread the unsafe pattern across organizations, infecting their supply chain (ASI04).

GitLab AI Gateway: prompt-template sandbox escape to RCE (CVE-2026-90970)

GitLab warned customers to patch a vulnerability in its AI Gateway product that could let attackers run arbitrary commands on vulnerable instances. AI Gateway gives access to AI-native GitLab Duo features.

The flaw lies in the prompt template of a custom flow. A custom flow is an AI-powered workflow that users create on the Duo Agent platform to automate multi-step tasks. A logged-in user with Duo Agent platform access could have used the flow to escape the prompt template sandbox via a crafted flow configuration. This escape could be used to execute arbitrary commands on the gateway.

For GitLab-hosted gateways, this vulnerability has already been fixed. However if you host your own gateway, GitLab has advised that you update your environment immediately. GitLab sent that guidance to customers before it published the advisory.

Self-hosted gateways holds signing keys for JWT, which are treated as sensitive credentials, as well as connections to GitLab instances and model providers.

GitLab credits HackerOne user 'invisiblemeerkat' with reporting the flaw. I wish I had a cool hacker name, any suggestions are welcome. Keep it SFW.

Currently there are no reported incidents from this disclosure, but I'd keep an eye on those self-hosted gateways. This does have the potential for Unexpected Code execution (ASI05) incidents via the agent flow configuration, and identity and privilege abuses (ASI03) as a low-privileged agent-platform user could end up with the gateway's signing keys and service credentials.

Official MCP Python SDK: malicious MCP servers can hijack OAuth credentials

Cycode reported an official MCP Python SDK flaw could trick applications into handing over the OAuth credentials it uses to log into a real service. In versions >= 2.0.0a1, < 2.2.0 and >= 1.9.1, < 1.30.0, it could send the client secret, authorization code, and PKCE proof key to a token endpoint that an attacker controls.

When an MCP client needs to log in, it'll ask the server it is connecting to where the authorization server can be find. In the affected versions, a malicious server could point it at a server that an attacker chooses. The client then sends the secret, PKCE proof key and auth code to the attacker. The proof key is a one-time value that's designed to prevent a stolen authorization code from being used, so if that gets handed over, that protection is gone.

No exploits have been reported yet, and this issue was fixed in version 1.30.0 and 2.2.0. However, if you're using affected SDK versions, you could be opening yourself up to Agentic Supply Chain vulnerabilities and Identity and Privilege abuses.

Furthermore, if you use ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider, you should also pass the issuer=. Without this, they'll still follow whichever auth server your MCP server advertises.

Malicious ChatGPT Custom GPT "Plus 5.6" used to deliver a RAT via ClickFix

Malware developers use sponsored Google results as an attack vector to lure unsuspecting victims. Huntress found that attackers are using sponsored results to push a malicious ChatGPT custom GPT named "Plus 5.6", that lures them to a fake Cloudflare CAPTCHA check and make them download and run a remote access trojan (RAT).

Essentially users would search "chatgpt" in Google, and a link to the custom GPTs would appear in the sponsored Google Search result. Those who navigate to the site and complete the CAPTCHA check would be delivered with a ClickFix attack, which tell users to copy-and-paste a command into their terminal.

That triggers a chain that ends up with a remote access trojan being downloaded onto your machine.

Huntress reported the initial finding and OpenAI were able to remove it. However, it didn't take long for another site to be created and pushed through sponsored results (who at Google verifies these?).

The second one is still online, and while it doesn't contain the malicious ClickFix lure anymore, it's only a matter of time until a new installer is created.

The general advise here is that any page or website that asks you to run something in the Run dialog, Terminal, PowerShell, or command prompt is asking for trouble. Don't do it.

But this is a great example of how agents can exploit the trust of humans (ASI09). Who among us hasn't typed 'chatgpt' into a Google search? Imagine if you're not a technical person, or you just forget to look at the actual web address? If the domain looks official enough, you're going to trust it, and if you're not sure what a download does, are you really going to take the time to stop it?

Malicious Custom GPT on chatgpt.com lures users into installing a RAT

LiteLLM: JWT email_verified account takeover (CVE-2026-93355)

LiteLLM is an open-source gateway that you can use to manage access to OpenAI, Anthropic, and other LLM APIs. The gateway holds API keys, tracks how much you're spending on LLM calls, and controls who can access what.

The folks at OX Research discovered a way to use a legitimately signed login token to authenticate as another LiteLLM user (including admins). The JWT authentication silently falls back to an unverified email claim when a direct identity match misses. This allows the attacker to log in as any user, and then permanently rebind that victim's SSO account to the attacker's own token.

This vulnerability was actually discovered on May 18th, but Ox has still not received a response, and it was publicly disclosed on September 14th. There's been no reported exploitations yet, the vulnerability has been confirmed through to version 1.100.1

CVE-2026-93355: Account Takeover in LiteLLM

Conclusion

We're only going to see more agents being used in cyberattacks. Whether it's agents going against their intended goals or being directed to be malicious. Agents can also cause trouble when they are acting within their expected behavior, as in the case of PixelLeak.

The agentic supply chain also continues to be a challenge. Agents depend on MCP servers, SDKs, gateways, and shared skills which all can be weak links to be exploited.

If you're developing agents for your organizations, you need to ensure that you're thinking about the underlying agent infrastructure, and implement constraints and guardrails over what your agents can do.

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Last week in Agent Security 1: We are not-a-mused!

Will Velida — Tue, 29 Sep 2026 00:15:01 +0000

Last week I talked at NDC Oslo about the OWASP Top 10 for Agents where I showed folks the different ways that agents can be exploited. If you've turned the news on recently, you've probably heard about AI will kill us all and how we're all doomed.

Call me optimistic, but I think we're currently in the middle of a hype cycle where AI labs are overstating the abilities of the models, and we're at a point where we've seen how powerful agents can be, but we need to be more serious about the harms agents can do, and how we can mitigate those risks.

With that in mind, I'll aiming to do a weekly blog post on different agentic attacks and incidents, what happened, how it happened, and what OWASP risks they fall under. Depending on demand or the severity/publicity of the attack, I may do a deep dive on how you could prevent such an attack in the first place.

I'll point out that I'm not trying to shame any of the companies involved, nor do I condone any of the methods used in any of these incidents. My goal here is just to spread awareness of the different ways that agents can be exploited, and hopefully trigger a conversation with your teams on how you should protect your agents and the people who use them from potential vulnerabilities.

Here's some incidents that have happened over the period 21st-27th September 2026.

Meta Muse macOS zero-day ("not-a-mused")

On September 21st 2026, macOS security researcher Patrick Wardle (also founder of the Objective-See Foundation) created a POC (amusingly called "not-a-mused") showing that malware already running inside a Mac can hijack Meta's Muse AI assistant.

The flaw centers on a undocumented configuration setting endo_voyager_dictation_endpoint that an unpriviledged local process can flip to reroute Muse's dictation traffic to an attacker's controlled server (via your own microphone). From there, you could inject extra instructions that Muse trusts, read dictated content from Muse, and steal the authentication token that signs into the user's Muse account. You can use Muse on multiple devices, which extends the blast radius.

Meta have apparently released a hotfix, but we see a number of risks being highlighted here. Theft and reuse of the agent's token (Identity & Privilege Abuse), injected goal hijack of the instructions that the agent acts on (Agent Goal Hijack), and how a trusted assistant becomes an attack surface (Human-Agent Trust Exploitation).

Gambit "Strix/Cairn/Hermes" autonomous card-skimming campaign

Gambit Security published an interim report about a financially motivated campaign in which a single operator chained three open-source AI agent frameworks to attack online retailers autonomously. They've traced the attack to July 2026 and it's still ongoing (at time of writing).

The first framework involved is Strix, which is an open source AI penetration testing tool. Between 23rd and 31st August, Strix was run in deep mode against various hosts to provide reconnaissance and vulnerability discovery.

Cairn, which is an automated penetration testing engine, was then used to launch attacks. Each attack path was chosen by the harness in real time through extensive probing and exploitation attempts, resulting in dynamic and mostly different TTPs across victims.

Then finally, Hermes, is being used to orchestrate the attack. Gambit attributes a Chinese-speaking operator running a SOUL - Red Team Operator persona with 121 skills. The operator has also added a skill that removes the content security filters of Hermes itself. It used Opus 4.6 (after newer models had refused its requests), with just under 2,000 prompts typed by the human operator across 260 sessions. Some example prompts include:

看漏洞报告开干 (“read the vulnerability report and start”)
看看进web后台 (“get into the web backend”)
你去搜一下wp2shell (“go and search for wp2shell”)

So far, more than 600,000 valid credit-card records have been exfiltrated from two victims, with the vast majority being US records, card-skimmer scripts planted on the sites of five organizations, and 119+ compromised websites overall; victims include a Fortune 500 hospitality company, a major US airline, a large US industrial-supplies distributor and an online fashion retailer. One Hermes "skill" file instructed the agent to wipe card fields from victims' Magento databases after exfiltration, causing operational disruption.

So another example of Rogue Agents in action, but this time the agents belong to the attacker, rather than a defender's own agent being subverted.

Autonomous AI Agents are breaking into hundreds of Online Retailers for $25 a target in an ongoing campaign

Bifrost AI-gateway unauthenticated RCE

AI Gateways are an effective mechanism to protect calls to LLM models, but they aren't foolproof. CVE-2026-90898 was reported in open-source AI gateway Bifrost which allows unauthenticated attackers to run arbitary commands on the gateway server with a single HTTP request. This is a good example of ASI05, Unexpected Code Execution.

Yuval Moravchick of JFrog Security Research found that an attacker can register a stdio-type MCP client through a single unauthenticated POST request to the management API endpoint /api/mcp/client. Before any MCP handshake, Bifrost starts the specified command immediately as the gateway process user.

The Bifrost binary binds the management API to localhost by default, which limits exposure to the local machine. The official Docker image binds it to 0.0.0.0, making the management API reachable from outside the container if the port is published.

Upgrading to transport versions v2.1.0 will result in a 403 response when unauthenticated callers try to register a stdio MCP client. Now the CTO and co-founder of Maxim says that the risk is lower than the CVE rating suggests, since exploitation requires the management interface to be reachable from an untrusted network and the operator to have left authentication unset. The default and documented deployment places the gateway inside a private network. Maxim and JFrog are working together to revise the severity assessment.

Critical Bifrost AI Gateway Flaw Lets Attackers Run Commands Without Credentials

Carbonato Docker botnet built on the Hermes "GH0ST" agent

On September 23rd, The researchers at ThreatDown disclosed a new botnet malware called Carbonato, which targets insecure hosts running Docker daemons exposing an unauthenticated daemon API on port 2375 to launch a privileged container to gain host access, and then install the Hermes Agent AI framework running an agent persona named GHOST with instructions that overwrite the default SOUL.md persona file.

It then opens a reverse SSH tunnel, installs an SSH server with the operators' key, and reports the new deployment through Telegram. Operators issue tasks over a Telegram interface, which is then interpreted by the model, and writes terminal commands, reads the output and decides to do what next. These tasks prioritize tasks such as harvesting AI API keys, SSH credentials, access tokens etc. and then returns those via Telegram.

This is an example of a Rogue Agent (ASI10) being weaponized as the malware core combined with tool misuse and exploitation (ASI02). The recommendation here is to keep Docker daemon APIs off the network and require authentication on registries.

New Carbonato malware uses AI agents to hijack exposed Docker hosts

OpenAI agent breached Australia's Medicare statistics portal

In local news, OpenAI breached Medicare!

So back in June, An OpenAI agent breached a Medicare statistics reporting portal operated by Services Australia, accessing public and non-public files and writing data to an internal server.

The agent was running a research task on public medical-spending data and when the portal's controls refused its requests, the agent found a workaround. The portal holds aggregated Medicare/Pharmaceutical Benefits Scheme statistics and is separate from claims and personal-record systems.

While no evidence that individual medical records were accessed, it didn't help that OpenAI found out about the attempt in June, and only told the Australian government last week. Despite the outrage from Australian media and general public, this isn't the worst example of Rogue Agent attacks. OpenAI should have acted quicker. This also shows how agents can be hijacked through goal drift, and how agents can bypass access controls to reach non-public files.

The Australian Government has stood up a cross-government task force, so watch this space.

OpenAI hacked Australian Medicare govt site, probed data providers

Salesforce Agentforce "SalesBleed" 0-click data exfiltration

On 24 September 2026, Zenity Labs disclosed SalesBleed, a set of zero-click vulnerabilities in Salesforce Agentforce that allowed attackers to exfiltrate CRM data with no victim interaction and without authenticating into the target's Salesforce environment.

An attacker plants a hidden prompt-injection payload inside a public-facing Web-to-Lead form. The malicious lead persists in CRM as a dormant record, and when an Agentforce agent later processes it during normal operations, the injected instructions hijack the agent.

The payload then queries and exfiltrates sensitive account data using DNS-based exfiltration that evaded Salesforce's Trusted URLs redaction control. So any external party who submits a lead could silently exfiltrate CRM data.

Zenity Labs and Salesforce have worked together to fix the bugs in Agentforce, but Zenity were quick to stress that the vulnerabilities found aren't unique to Agentforce. Any agent that ingests untrusted external records, renders links back to users, and holds sensitive tool access can be hijacked in the same way.

Memory and Context Poisoning through poisoned CRM records that resurface as trusted context (ASI06), indirect prompt injection redirecting agent behavior through those poisoned records (ASI01), and the agent's tool becoming the blast radius (ASI03) can occur in anyone's agent.

Conclusion

As you can probably see, these incidents came from agents that could make real tool calls, use credentials, and had the autonomy to perform consequential actions. Some agents were developed by the attackers themselves, while others drifted from their intended goals.

That's why it's critical for developers to control what your agent can do, not just what you tell them do. You have to assume that prompt injection attacks will eventually prevail, so you can design your agents to stop the damage early when it does.

If you have any questions, feel free to reach out to me on X @willvelida or on Bluesky

Until next time, Happy coding! 🤓🖥️

Running parallel GitHub Copilot agent sessions with tmux and git worktrees

Will Velida — Sun, 09 Aug 2026 23:08:03 +0000

When I first started using GitHub Copilot, I kept to the chat window, as I wasn't too comfortable with the idea of using the CLI for long prompts. The chat interface in VS Code was more friendly and intuitive for me, and I felt more in control using the chat UI.

Over time, I've been using GitHub Copilot CLI more often. As the scope of work increases (and as demand from stakeholders also increases!), I've found myself firing up multiple terminals to do multiple different tasks on a project. However, I've had to be careful about how I've done that, as I didn't want to have to deal with the trouble of merge conflicts only made worse by overzealous coding agents!

A colleague of mine suggested that I take a look at tmux and git worktrees as a method to safely work on multiple features within the same repository, and use the GitHub Copilot CLI to use agents to work on each worktree without compromising the others work. I'd never used tmux before, nor had I really used git worktrees in anger before, so this seemed like the perfect excuse to hack with it and learn something new.

What is tmux?

tmux is a terminal multiplexer that allows you to create, access, and control any number of terminals from a single screen.

What's different about just splitting the terminal or creating a new tab in Windows Terminal is that with tmux, you can detach from a session and reattach later through persistence. The running processes stay alive across disconnects and reboots. This is great for remote work, because if the connection drops, you can pick up exactly where you left off.

Persistent workspaces that survive disconnects are enabled through Sessions, which is just a collection of Windows. Windows are like tabs in a browser, where each can contain multiple panes and has its own command history. Panes split windows into multiple terminals.

tmux isn't exactly new. It was built in 2007 (remember life before the GFC? Pepperidge Farm remembers), so why use it for coding agents?

Why use tmux for agentic coding?

tmux has some pretty great features that are ideal for agentic coding workflows.

tmux's persistence model is particularly handy when agents are running long processes within a session. Imagine you're using GitHub Copilot to do a big refactor of your code, and half-way through the terminal got killed. With tmux, we can prevent this by detaching from our session, and reattaching later.

Each pane provides its own PTY, which is great for isolating agents from each other. The changes that Agent 1 makes can't step on the work that Agent 2 is doing. Being able to split the window and watch every agent work at the same time is also aesthetically pleasing.

Running this on WSL2

I'm running on a Windows machine, so I have to use tmux through WSL2. This isn't a bad thing, it's just that tmux doesn't run natively on Windows.

GitHub Copilot CLI runs on WSL2, so I thought I'd just set everything up on WSL2.

There is a native substitute called psmux if you're not comfortable with WSL2, but the rest of this guide will assume that you're running in WSL2.

What you'll need

I'm going to assume that you already have WSL2 installed. If you do, then you can use sudo apt install to install the following packages:

sudo apt install -y git tmux curl

For the GitHub Copilot CLI, that ships as an npm package. So if you need to install node on WSL2, you can do so using this command:

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs
node --version

Once you have node installed, install the CLI like so:

npm install -g @github/copilot
copilot --version

I also had to update the GitHub CLI so that I could open and merge PRs. I'm using Ubuntu as my distro, so I ran the following:

(type -p wget >/dev/null || sudo apt install wget -y)
sudo mkdir -p -m 755 /etc/apt/keyrings
wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg \
  | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" \
  | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install -y gh
gh auth setup-git      # so git push over HTTPS uses your gh credentials
gh --version

I'm also using Windows Terminal to run tmux inside that. This can be installed on Windows using WinGet:

winget install --id Microsoft.WindowsTerminal -e

Some tmux basics

Let's do a basic tour of tmux commands that I'll use in this blog post. We can start a new session like so:

tmux new -s tutorial # tutorial is the name of the session I've created

tmux uses Ctrl+b as the prefix key, and then you'd enter the command key to do something.

So if we want to split a pane, we can use Ctrl+b % to create a new pane left or right, or Ctrl+b " to create a pane top or bottom.

You can tidy the panes up by entering Ctrl+b :select-layout even-horizontal. There are other layout styles that you can as well. I find it easier to use Ctrl+b space to cycle through different layout options.

To detach a session, enter Ctrl+b d, then you can use the tmux sessions using tmux ls and then reattach using tmux attach -t <session-name>!

There's a lot more to it than just these basics. This blog post talks about how you can edit config for tmux to add features like mouse support, and there are more commands that tmux provides.

Giving each agent its own workspace with git worktrees

Git worktrees allow you to check out multiple branches from a repo at a time, with its own isolated directory, but sharing the same .git directory. This provides our agents with a reasonable amount of isolation since each worktree has its own directory, this will prevent autonomous agents editing the same directory from stepping on each other's toes (do agents have toes? No, it's a transformer model. It's just an expression) and creating merge conflicts in real time.

I have an API that I'm building for viewing past Arsenal results, and preparing for upcoming matches so I can export them into various calendars. For this API, I want to build the following endpoints:

GET /table returns the full league table, ordered by position.
GET /fixtures/h2h?teamA=&teamB= returns every match between two named teams.
GET /fixtures/upcoming (optional ?team=) returns the fixtures that have not been played yet.

Using git worktrees, each will check out into its own folder while sharing the API repository. This isolation gives each GitHub Copilot CLI instance its own workspace, so they won't overwrite each other in the middle of their work.

Let's set up our worktrees for the features we want to implement:

git worktree add -b feature/standings ../fixtures-standings
git worktree add -b feature/h2h       ../fixtures-h2h
git worktree add -b feature/upcoming  ../fixtures-upcoming

git worktree add creates a new worktree. -b feature/standings creates a new branch called feature/standings and ../fixtures-standings creates a sibling folder next to our repository, not inside it. This prevents git from getting confused about which repository owns what.

To see the list of worktrees that we have created, we can run the following:

git worktree list
# produces the following output
willv@Yggdrasil:/mnt/c/Users/willv/Documents/Learning/fixtures-api$ git worktree list
/mnt/c/Users/willv/Documents/Learning/fixtures-api        dc738bd [main]
/mnt/c/Users/willv/Documents/Learning/fixtures-h2h        dc738bd [feature/h2h]
/mnt/c/Users/willv/Documents/Learning/fixtures-standings  dc738bd [feature/standings]
/mnt/c/Users/willv/Documents/Learning/fixtures-upcoming   dc738bd [feature/upcoming]

Running multiple GitHub Copilot agents in parallel

With our worktrees created, we can now create a new tmux session and split it into panes for each of our worktrees:

tmux new -s swarm

Create three new panes using Ctrl+b % and style the layout how you want. Then within each pane, we'd cd into each worktree. Using my worktrees:

# In pane 1
cd /fixtures-standings
# In pane 2
cd /fixtures-h2h
# In pane 3
cd /fixtures-upcoming

You can move between panes using Ctrl+b then an arrow key.

Within each pane, you can confirm that the folder and branch are correct by running the following:

pwd && git branch --show-current

Within each CLI session, it'll pause to ask permissions before editing files or running commands like dotnet build. If you want to run these without having to press enter each time Copilot asks you for something, you can add --allow-all-tools to the command. I'm still not 100% comfortable with just YOLOING in agentic coding sessions, but this is just a demo and we can have some fun with it 😅

For each pane, I ran the following prompts:

# pane 1
copilot --allow-all-tools -i "Add Endpoints/StandingsEndpoints.cs implementing IEndpointModule (see Endpoints/IEndpointModule.cs), mapping GET /table that returns FixtureData.Standings ordered by position. Inject FixtureData via the constructor pattern the other modules use. New file only, do not edit Program.cs. Make sure the project still builds."

# pane 2
copilot --allow-all-tools -i "Add Endpoints/HeadToHeadEndpoints.cs implementing IEndpointModule (see Endpoints/IEndpointModule.cs), mapping GET /fixtures/h2h?teamA=&teamB= that returns every match from FixtureData.Matches where those two teams met (either could be home or away). Inject FixtureData. New file only, do not edit Program.cs. Make sure the project still builds."

# pane 3
copilot --allow-all-tools -i "Add Endpoints/UpcomingEndpoints.cs implementing IEndpointModule (see Endpoints/IEndpointModule.cs), mapping GET /fixtures/upcoming with an optional ?team= filter, returning matches from FixtureData.Matches where Played is false, ordered by matchday. Dates may be null for those fixtures, so do not sort by date. Inject FixtureData. New file only, do not edit Program.cs. Make sure the project still builds."

Press enter to send those prompts and watch the agents do their thing!

If you need to step away and you don't want to lose them, you can always use Ctrl+b d to detach the session, and then use tmux attach to come back. Remember that the session lives on the machine, so we can pick up the same session on a different terminal, or even ssh into the machine and start the session from there.

Reviewing our changes

Once our agents have finished making their changes, we need to make sure that we can merge the changes back into main, and that there aren't any conflicts between the different branches and main. This is where git worktrees can be advantageous, since they have their own working directory.

Because our worktrees are isolated, we can commit the changes as the changes that the agents have made don't conflict with each other. Once we've committed the changes, we can raise a PR for each worktree.

cd /mnt/c/Users/willv/Documents/Learning/fixtures-api
git push -u origin feature/standings feature/h2h feature/upcoming

Then we can open a PR for each of our worktrees using --head to name the branch.

gh pr create --base main --head feature/standings \
  --title "feat: add GET /table standings endpoint" \
  --body "Adds Endpoints/StandingsEndpoints.cs (IEndpointModule) mapping GET /table, returning the league table ordered by position. New file only; Program.cs untouched."

gh pr create --base main --head feature/h2h \
  --title "feat: add GET /fixtures/h2h endpoint" \
  --body "Adds Endpoints/HeadToHeadEndpoints.cs (IEndpointModule) mapping GET /fixtures/h2h?teamA=&teamB=, returning matches between the two teams. New file only; Program.cs untouched."

gh pr create --base main --head feature/upcoming \
  --title "feat: add GET /fixtures/upcoming endpoint" \
  --body "Adds Endpoints/UpcomingEndpoints.cs (IEndpointModule) mapping GET /fixtures/upcoming (optional ?team=), unplayed fixtures ordered by matchday. New file only; Program.cs untouched."

We can use the gh CLI to see the PRs that we've just raised!

gh pr list

The output should look something like this:

We can then merge each PR using the gh CLI:

gh pr merge feature/standings --squash
gh pr merge feature/h2h       --squash
gh pr merge feature/upcoming  --squash

Once everything has been merged, we can bring the squashed commits down to our local main:

cd /mnt/c/Users/willv/Documents/Learning/fixtures-api
git checkout main
git pull

Then, confirm and build everything to make sure it all works:

git log --oneline -5     # three new squash commits on main
ls Endpoints/            # all three endpoint files present
dotnet build             # green

Once you're satisfied that everything looks good, you can clean up the worktrees like so:

git worktree remove ../fixtures-standings
git worktree remove ../fixtures-h2h
git worktree remove ../fixtures-upcoming
git worktree prune

git worktree remove deletes each sibling folder and frees its branch. Once that's done, the merged branches are safe to delete (both locally and remote):

git branch -d feature/standings feature/h2h feature/upcoming
git push origin --delete feature/standings feature/h2h feature/upcoming

If you run git worktree list or git branch again, you should only see the main branch.

Conclusion

Combining tmux and git worktrees has given me the confidence to run multiple coding agents simultaneously without them trampling on each other's branches. tmux gives us session persistence and isolation, and git worktrees give each agent a clean workspace to work with, preventing agents from overwriting each other's changes.

Bear in mind that this is just the basics. There's a lot more that we can build on here, including extending orchestration tools, and scaling past just a couple of agents. As always though, this is AI-assisted engineering, not a replacement. Make sure that you have sufficient guardrails in place so that your agent swarms don't cause production faults! You're still getting that call at 2am when shit goes sideways!

If you have any questions about this, please feel free to reach out to me on Bluesky!

Until next time, Happy coding! 🤓🖥️

What are Agent Plugins?

Will Velida — Fri, 07 Aug 2026 11:42:24 +0000

Implementing Agent Skills and MCP servers as part of my development workflow has been a huge boost to my productivity. Long gone are the days where I'd actually have to leave my IDE to raise a pull request in GitHub, and then manually add that PR to a Jira ticket that's still impossible to find in 2026.

Now it's just a matter of me asking GitHub Copilot to create the PR using my create-pr Agent Skill, then use the Atlassian MCP Server to link the PR to the appropriate Jira ticket. All of which I can do without ever having to leave my IDE.

However, I use different coding agents for my development. I'll use GitHub Copilot heavily for work, but I'll use Claude Code and Cursor for my side-projects. For those of you who've used both tools in anger will know that configuring Agent Skills, MCP servers, agents and other agentic components differ slightly between the two tools, which was a bit of a pain to deal with every time I wanted to use the same components in different tools.

The Agent Plugins standard was announced on August 6th 2026, which defined a packaging layer that sits on top of both Agent Skills and MCP Servers, giving developers a way of installing agentic coding components in a standardized format across different coding agent clients.

Considering it's only a day old (at time of writing), I decided to look at the docs, and see if I could develop a plugin for my health project using it's MCP server. There are some gaps that need to be addressed, but I think it's a big step towards a standard for giving developers what they need, rather than having to configure every individual component themselves.

In this blog post, I'll talk about what Agent Plugins are, why we need them, how we can build one, how we can install plugins across different clients, and what the gaps are that need to be addressed.

What are Agent Plugins?

Agent Plugins are an open, vendor-neutral standard for packaging reusable agent components into portable plugins. It defines a shared format for Agent Skills and MCP servers that compatible clients can discover and load.

This is an initiative from AWS, Cursor, Microsoft, OpenAI, and Vercel, who are part of the Technical Steering Committee. Google has also joined as a Core Maintainer.

Agent Plugins are just directories that include a required manifest and optional components. Take the following as an example:

my-plugin/
├── plugin.json
├── skills/
│   └── weekly-health-brief/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.biotrackr.client/
    └── hooks/

The plugin.json identifies the plugin and the Agent Plugins version it targets. skills/ contains Agent Skills that the plugin will use. mcp.json describes MCP servers that the plugin has access to. These can be stdio, Streamable HTTP, or legacy HTTP+SSE servers.

Why do we need them?

Agent Skills and MCP servers have been fantastic in augmenting our coding agents. The problem was that each client had their own way of implementing them. For example, in VS Code you have native support for the SKILL.md format. They live in .github/skills/<name>, .agents/skills/ (project level), or ~/.copilot/skills/ (personal), and you define them like so:

---
name: webapp-testing
description: Run and debug integration tests for the web app. Use when asked to test the login page or a UI flow.
---

# Web application testing

1. Start the dev server with `npm run dev`.
2. Use the template at [test template](./test-template.js).
...

In Cursor, you don't have native support for SKILL.md. Instead, Cursor's equivalent is something called Rules (that live in .cursor/rules/*.mdc) or just the AGENTS.md file. A rule is markdown and frontmatter controlling when it applies:

---
description: RPC service conventions for the backend
globs: src/services/**/*.ts
alwaysApply: false
---

- Define each service in its own file under `src/services/`.
- Validate inputs at the service boundary.
- Reference @service-template.ts when creating a new service.

Agent Plugins is a good step towards solving this problem, as the specification defines a small interoperability floor for parts that can be portable across different coding agents. Shared components can use a predictable structure, while things like distribution, installation, permissions, UX and client-specifics can be handled by the clients themselves.

Building a minimal plugin

For Biotrackr, I have an MCP server that exposes tools from across my various APIs. All this plugin will do is use that MCP server to retrieve information from my health data, as there are no write operations that the MCP Server exposes. Pretty basic, but good enough to see how Plugins work without potentially deleting any data.

Since we're just exploring Plugins, I'll keep the directory simple:

biotrackr-brief/
├── plugin.json
├── skills/
│   └── weekly-health-brief/
│       └── SKILL.md
├── mcp.json
├── README.md
└── LICENSE

We'll define the plugin.json manifest, give it a single skill, create a mcp.json configuration file, and add a README.md and LICENSE file (even though I'm not publishing this 😅).

Let's take a look at the plugin.json manifest:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "biotrackr-brief",
  "version": "1.0.0",
  "description": "Turns Biotrackr health data into a short weekly brief. Bundles a weekly-health-brief skill with Biotrackr's MCP server (activity, sleep, vitals, and nutrition tools).",
  "author": {
    "name": "Will Velida",
    "url": "https://github.com/willvelida"
  },
  "homepage": "https://github.com/willvelida/biotrackr",
  "repository": "https://github.com/willvelida/biotrackr",
  "license": "MIT",
  "keywords": [
    "health",
    "fitbit",
    "withings",
    "mcp",
    "weekly-brief",
    "activity",
    "sleep",
    "vitals",
    "nutrition"
  ]
}

The SKILL.md file is pretty simple, we're just going to ask it to retrieve a weekly summary of our data for us:

---
name: weekly-health-brief
description: Assembles a concise weekly health brief from Biotrackr activity, sleep, vitals, and nutrition data. Use when the user asks for a weekly summary, a health recap, "how was my week", or a brief covering steps, sleep, weight, or diet trends over the last seven days.
---

# Weekly health brief

etc. etc.

We can also configure the MCP servers that the plugins will use in the mcp.json file like so:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "biotrackr": {
      "type": "streamable-http",
      "url": "https://biotrackr-mcp-server-dev.io",
      "headers": {
        "X-Api-Key": "API_KEY"
      }
    }
  }
}

Loading the plugin across clients

In VS Code, we can load our plugin via our user settings json file. Within it, we need to add the following:

{
    "chat.plugins.enabled": true,
    "chat.pluginLocations": {
        "<directory-path>": true
    }
}

The chat.plugins.enabled setting turns the Agent Plugin feature on. The chat.pluginLocations maps the plugin's root directory to true. VS Code auto-detects the Agent Plugins format from the $schema in the plugin.json file, then it loads the weekly-health-brief skill and the biotrackr MCP server from the mcp.json.

You can manage the plugin in the Extensions view. Search @agentPlugins in the Extensions view to see the Agent Plugins that have been installed:

Our Agent Plugin can now be added to other Agent-Plugin compatiable clients, like Cursor. We can add our plugin using the Customize menu, and then adding the plugin from our local repository:

We can inspect the plugin and see what skills are available to the plugin, as well as any MCP Servers that are packaged as part of the plugin. For my Biotrackr plugin, I can see the weekly-health-brief skill and biotrackr MCP as part of the plugin.

I can also see what MCP tools are available as part of the plugin:

From there, we can start a new chat, and use the skill to get a weekly view of my health data. For example, let's take a look at my data for the week:

Drilling down into Cursor's thought process, we can see that Cursor has taken a look at the SKILL.md file, and used the MCP server to fetch our weekly data from all our domains:

Using the same file format and specification, we can use skills and MCP servers bundled as a plugin across two clients without having to change any of the files to be compliant with a particular coding assistant.

Limitations

It's important to point out that this is just a starting point. I think it's a step in the right direction, but there's a couple of features missing that still need to be addressed.

Currently, there's no permission model, no sandboxing, no trust/provenance and no approval UX for MCP servers that execute commands or access external services. As you can probably imagine, that's a massive task, as install, policy, and enterprise controls will differ across developer environments, CLIs and managed platforms.

There's also no portable secret mechanism. The mcp.json schema is closed, and it forbids any credentials in headers or env. This makes sense from a package perspective, as packages are intended to be for public consumption.

My MCP Server sits behind Azure APIM, and there's no portable slot for the subscription key in the plugin's mcp.json schema.

For my local plugin, it was fine to hardcode the X-Api-Key header just to get it running on my machine. If this was a package that I published, authentication would have to be handled by the client. Taking VS Code as an example, that would come from VS Code's .vscode/mcp.json config file.

There are a list of future considerations that the Agent Plugin team are working on, so I expect these questions to be answered over time.

Another gap is support for Claude Code. Claude has its own plugin system which already comes with skills, agents, hooks, commands, and MCP servers. What differs between Claude Code plugins and Agent Plugins are the manifest and discovery. Agent Plugins uses a root plugin.json with the canonical $schema; Claude Code uses .claude-plugin/plugin.json.

Conclusion

Agent Plugins are a simple, but positive step forward for sharing Agentic coding capabilities across teams who use different agentic coding tools. It was a pain having to make edits to skills and MCP servers just so they could work from one tool to another.

There are a couple of major gaps that need to be addressed, but I think this is a big step towards having mature package managers for Agent Plugins, rather than having to copy/paste between different repositories and coding environments!

If you have any questions about this, please feel free to reach out to me on Bluesky!

Until next time, Happy coding! 🤓🖥️

Distributed tracing for multi-agent systems with OpenTelemetry

Will Velida — Thu, 06 Aug 2026 13:01:48 +0000

Multi-agentic architectures can pose challenges from an observability perspective. Each agent within a workflow makes its calls to its own toolset and each agent may be configured to use a different underlying LLM (or even a Model Router which picks the most efficient model for us). Being able to observe which agent made what call with which model in a unified manner can be challenging over an entire workflow.

OpenTelemetry provides semantic conventions that help us solve this problem and Microsoft Foundry provides tracing integrations for agent frameworks that enable us to implement tracing for different agentic frameworks, and assist us in quickly identifying root causes for issues in our agents.

Imagine we have a multi-agent solution for an incident drill runner. We use this to run chaos engineering drills and a crew of agents investigates a simulated outage in the same way an on-call roster would do. We have an agent for an incident commander who fans out to a Logs specialist, a Metrics specialist, and a Runbook specialist who all investigate the simulated outage. They report back to the incident commander, who then assembles the timeline of the incident and provides a suggested solution.

Each specialist agent is configured with its own tool:

Agent	Job	Tool	Deployment
`logs`	Read logs and follow them downstream	`query_logs`	`gpt-5-mini`
`metrics`	Find the change point in a metric series	`query_metrics`	`gpt-5-mini`
`runbook`	Match observed symptoms to the catalog	`lookup_runbook`	`gpt-5-mini`
`incident-commander`	Assemble a timeline and a mitigation	none	`model-router`

N.B. The incident-commander uses the model-router deployment. If you're running the sample yourself, you will notice different gen_ai.response.model values for different runs. If you want to learn more about how Model Routing works, check out this video on YouTube

The flow looks something like the following:

In this article, we'll discuss how distributed observability works for multi-agent systems, how we can propagate context across agents within our workflow, dive a little deeper into the OpenTelemetry Semantic Conventions for GenAI, and how we can implement observability in our agents and Microsoft Foundry so that we have a unified view across our agents.

If you want to take a look at the code while reading the article, you can view the complete sample here.

I've also made a YouTube video for this too! Check it out 👇

What does distributed observability mean for multi-agent systems?

Multiple agents can be invoked as part of an agentic workflow, with each agent making calls to its own tools and different LLMs. Agent-to-agent calls and tool chains mean that per-agent observability isn't enough to get a complete picture of what happened, we need to have a connected trace across the whole system.

OpenTelemetry provides a standardized protocol for collecting and routing telemetry data. Microsoft Foundry uses OpenTelemetry semantic conventions to provide consistency across tools and integrations. Within Foundry, tracing captures information such as user inputs and agent outputs, tool usage, token consumption, and time signals such as duration and latency.

There are a couple of OpenTelemetry concepts we should discuss before moving on. Traces 'trace' the journey of a request or workflow through your application by recording events and state changes (which can include function calls, and system events). Spans are the building blocks of traces. They represent a single operation within a trace, and capture start and end times, attributes, and can be nested to show hierarchical relationships so we can see the full call stack and sequence of operations. Attributes are essentially key-value pairs attached to traces and spans, and provide contextual metadata.

How does it work?

Propagating context across agents

For multi-agentic systems, span context contains both a trace ID and span ID. The span context gets propagated across agent boundaries using the W3C Trace Context standard.

When a receiving agent takes the context, it will create a child span with the same trace ID, but create a new span ID. If the agent needs to call any downstream agents, the context will be propagated. Without this, each agent would create a new trace ID, and we'd lose the correlation.

For our incident drill simulator, one drill would be one trace. Our span is opened when the commander is invoked and the drill scenario is created.

with drill_context(
    id=drill_id,
    incident_id=incident_id,
    service=service,
    scenario=scenario,
    mode=mode,
):
    with get_tracer().start_as_current_span("game_day_drill", kind=SpanKind.SERVER) as root:
        brief = _brief(scenario, service, symptoms)

        findings = await asyncio.gather(
            *(_delegate(crew, role, brief) for role in Role)
        )

        report, severity, model = await _assemble(crew, brief, findings)

The with drill_context() attaches Baggage, which is a key-value store which lets you propagate any data we like alongside context. The trace is created in the with get_tracer().start_as_current_span() statement. as_current means that the span is created and it gets installed in the context. Any span started inside that block becomes a child of root, which uses the same trace ID, but its own span ID.

The SpanKind.SERVER value for the kind parameter starts the SERVER span deliberately. Without this, Application Insights has nothing to use as the start of a transaction, so we need to set this in order to see the end-to-end view.

In order to give our processor a rule for what to copy, we can provide a BAGGAGE_PREFIX namespace so that our key id becomes drill.id like so:

BAGGAGE_PREFIX = "drill."

Next, we need to set the Baggage. In OTel, contexts are immutable, so we use the set_baggage method to return a new context rather than modifying each one:

@contextmanager
def drill_context(**entries: str) -> Iterator[None]:
    ctx = context.get_current()
    for key, value in entries.items():
        ctx = baggage.set_baggage(f"{BAGGAGE_PREFIX}{key}", value, context=ctx)
    token = context.attach(ctx)
    try:
        yield
    finally:
        context.detach(token)

Baggage lives in the context, while attributes live in the spans. To bring them together, we need to use a span processor to hook the start of the span, and then use a BaggageSpanProcessor to copy the matching baggage across as attributes:

def _install_baggage_processor() -> bool:
    provider = trace.get_tracer_provider()
    add_span_processor = getattr(provider, "add_span_processor", None)
    if add_span_processor is None:
        return False
    add_span_processor(BaggageSpanProcessor(lambda key: key.startswith(BAGGAGE_PREFIX)))
    return True

The GenAI semantic conventions

The OpenTelemetry semantic conventions define a common set of semantic attributes which provide meaning to data when collecting, producing and consuming it. As far as agents are concerned, OpenTelemetry has conventions for spans, metrics, and events for GenAI clients, MCP servers and provider-specific (For example, OpenAI LLMs) conventions

Different namespaces exist for different attributes. For example, gen_ai.* has key attributes like gen_ai.agent.name, gen_ai.agent.id, gen_ai.operation.name, gen_ai.usage.*. Underneath those attributes, there are well known values. For example gen_ai.operation.name has values such as invoke_agent, execute_tool, execute_task, agent_to_agent_interaction.

Standardised conventions provide us consistency across different agentic frameworks, so you can use the same tracing standards for agents that use Microsoft Agent Framework and agents that use LangChain, OpenAI Agents SDK etc.

The Microsoft Agent Framework instruments invoke_agent, chat, and execute_tool automatically. However, when we need to trace when the Commander agent hands work to our specialist, we need to implement that ourselves.

This is what happens inside _delegate(), the function our asyncio.gather calls once per specialist:

with get_tracer().start_as_current_span(
    "agent_to_agent_interaction",
    kind=SpanKind.CLIENT,
    attributes={
        "gen_ai.operation.name": "agent_to_agent_interaction",
        "gen_ai.agent.name": agent.name,
        "game_day.from_agent": COMMANDER_NAME,
        "game_day.to_agent": agent.name,
        "game_day.role": role.value,
    },
) as span:
    response = await agent.run(f"{brief}\n\n{SPECIALIST_ANGLE[role]}")

Because agent.run() sits inside this with block, the invoke_agent span that Agent Framework opens becomes a child of our hand-off span. That gives us the three levels we'll see in the portal later: the drill, the hand-off, then the specialist's own agent, chat and tool spans. Without it we'd have three invoke_agent spans sharing a parent and no record of who handed work to whom.

OpenTelemetry with Azure Monitor

Azure Monitor supports two approaches with OpenTelemetry. Either through its native OpenTelemetry Protocol (OTLP) ingestion path so we can send standard logs, metrics, and traces into Azure Monitor using the open source collector, or we can use the Microsoft OpenTelemetry Distro, which is a client that bundles all open-source and Microsoft components required for a full integrated experience with Azure Monitor for both AI Agents and normal applications.

To use OpenTelemetry in Python, we need to install the following dependencies:

agent-framework-foundry>=1.10.4
azure-identity>=1.19.0
# Not installed by Agent Framework. Without it there is no Application Insights exporter.
azure-monitor-opentelemetry>=1.6.0
# Copies drill baggage onto every span, which is what makes one drill one queryable unit.
opentelemetry-processor-baggage>=0.65b0
python-dotenv>=1.0.1

For the purposes of this demo, I wanted to extend the sample so that we can have the option of either seeing the traces in the console, or in Azure Monitor, so we'll need to configure both like so:

async def configure(client: FoundryChatClient, *, sensitive_data: bool) -> str:
    otlp_endpoint = os.environ.get("OTEL_EXPORTER_OTLP_ENDPOINT", "").strip()

    if otlp_endpoint or flag("ENABLE_CONSOLE_EXPORTERS"):
        configure_otel_providers(enable_sensitive_data=sensitive_data, views=_metric_views())
        destination = otlp_endpoint or "the console"
    else:
        connection_string = (
            await client.project_client.telemetry.get_application_insights_connection_string()
        )
        configure_azure_monitor(
            connection_string=connection_string,
            resource=create_resource(),
            enable_live_metrics=True,
            views=_metric_views(),
        )
        destination = "Application Insights, via the Foundry project connection"

    # ENABLE_INSTRUMENTATION defaults to false. Without this the crew runs and emits nothing.
    enable_instrumentation(enable_sensitive_data=sensitive_data)

One thing that I noticed is that we need to add the enable_instrumentation() method in order to export our telemetry data. Agent Framework disables this by default, and while our agents will run, without this our telemetry isn't emitted.

Another thing worth mentioning is the enable_sensitive_data parameter. This is what puts prompts, tool arguments, and tool results into the spans. It's off by default, and it should stay off for production. This sample is just using synthetic data to show what's possible. If you want to keep user prompts out of Application Insights, set this to false.

Building our observable multi-agent system

As I mentioned earlier, the Microsoft Agent Framework provides some of this out of the box. Once we've configured our instrumentation, these spans appear without any extra effort on our part. What's lacking is what choices our agents have made.

If we wanted to see what tool calls our agent makes, we want to be able to see that within our traces. For example, for our Logging Agent, we can configure this like so:

@tool(approval_mode="never_require")
async def query_logs(
    service: Annotated[str, Field(description="Service name from the service map, for example 'checkout-api'.")],
    min_level: Annotated[str, Field(description="Lowest severity to return: info, warn or error.")] = "warn",
) -> str:
    """Read recent log lines for one service in the incident window."""
    key = _clean(service).lower()
    level = _clean(min_level).lower()
    _count("query_logs", key)

    span = trace.get_current_span()
    span.set_attribute("game_day.tool.service", key)
    span.set_attribute("game_day.tool.min_level", level)

    ...
    span.set_attribute("game_day.tool.result_count", len(lines))
    return _ok(service=key, min_level=level, lines=lines)

Let's break this down:

@tool registers the tool as a function within the Microsoft Agent Framework.
The _clean() method trims and caps every argument. Our tool arguments come from a model, so it's best to treat this as untrusted input.
The trace.get_current_span() method grabs the execute_tool span that is already open. We're not creating a new span, we are adding to the one that already exists to get that unified span.
The game_day.tool.* attributes record what tool the agent invoked, and what it got back.

Without those attributes, we wouldn't be able to see that the Logs agent looked at the wrong service, or that a query returned 0 results but it did some work anyway.

Seeing it work

Let's see this in action. We can run one of the drills like so:

$ python demo.py

This produces the following output:

[1] INC-A1C212  checkout latency spike     normal  sev1      48.5 s  drill 1b1b480ad6e2
    logs       24.9 s  Checkout-api p99 latency and error spike caused by payments-gateway connection-pool exhaustion leading to timeouts and a circuit-breaker opening.
    metrics    24.4 s  ~09:25 spike in checkout-api p99 and errors, traced to payments-gateway timeouts after a 09:20 deploy that reduced its connection pool.
    runbook    12.5 s  RB-014 (Downstream connection pool exhaustion) selected; confirm pool.max vs prior release and restore it if it was lowered.
    commander  routed to grok-4-1-fast-reasoning
    tool calls  lookup_runbook 1  query_logs 4  query_metrics 6    total 11

     - ~09:20: Deploy to payments-gateway reduced connection pool max from 200 to 20 (Metrics).
    - ~09:25: p99 latency jumps in payments-gateway (90ms to 7.66s) and checkout-api (~360ms to 1.9s then 7.9s), with error rates rising to 17% and 15% respectively; request volumes flat then falling (Metrics).
    - payments-gateway connection pool saturated: in_use=20 max=20 waiters=61, then pool acquire timed out after 8000ms with waiters=112 (Logs).
    - checkout-api slow downstream calls to payments-gateway: duration_ms=6902 (Logs).
    - checkout-api upstream timeouts on payments-gateway after 8000ms (Logs).
    - Circuit breaker opened on payments-gateway dependency after 23 failures (Logs).

    RB-014 "Downstream connection pool exhaustion" matches symptoms of latency step change, flat-then-falling volume, and upstream timeouts. Confirm current pool.max value against the previous release; since metrics evidence shows it was reduced from 200 to 20 by the 09:20 deploy, raise it back to 200 or roll back the release. Monitor p99 latency, error rates, and pool metrics post-mitigation to confirm recovery.

    SEVERITY: sev1

The header line shows the root span duration (48.5s). All 3 agents ran concurrently and have returned their findings back to, or reported back to, the incident commander. We can see that the Commander agent uses grok-4-1-fast-reasoning to produce the timeline and a mitigation path.

Within the tool calls, we can see how many calls each agent made to various tools, along with a total.

Within the classic Foundry portal, we can see the entire game_day_drill trace in the Tracing portal. Our run generated a trace ID aaaeef28ce1288c5cf456d39a345a576:

Taking a closer look at this, we can see that the child spans all use the same trace_id, so looking at the metadata of game_day_logs, it uses a new span_id, but has the same trace_id:

We can also view the entire transaction in Application Insights' Transactions using that trace_id:

When models are invoked, we can view GenAI properties such as input and output tokens spent, as well as how long the call took:

We can also view custom properties:

Application Insights has a preview feature where we can also view operational metrics from our agents, such as Agent runs, tool calls, models used and importantly, token consumption by model and input vs output tokens.

From here, we can explore specific agent runs using our trace_id from before. This is handy for when we want to start with a high-level overview, and then drill down into our transaction view.

Conclusion

Hopefully you now have a better understanding of how we can use OpenTelemetry to create a unified trace for distributed multi-agentic systems. Using this unified trace, we can gain insights into how agents interact with each other, what decisions they make, and how they consume tokens.

If you want to take a closer look at the code, the complete sample is available on my GitHub.

If you have any questions about this, please feel free to reach out to me on BlueSky!

Until next time, Happy coding! 🤓🖥️

How Model Routing works for Microsoft Foundry Agents

Will Velida — Sun, 02 Aug 2026 04:59:06 +0000

If you prefer to watch videos over reading, check out this video on my YouTube channel:

About a year ago I got back into skateboarding. Probably not the safest midlife crisis ever, but I can travel from my house to the gym, I can kickturn, and even manage a nose stall 1 out of 10 times. Look at this footage for an example

I even built my own board! I applied my own grip tape, bolted on the trucks, and applied the bearings to the wheels. One thing I definitely learnt through that exercise is that skateboards cost a lot more than they used to.

You know what else is expensive? Tokens. The age of tokenmaxxing (I hate that term) is truly over thanks to token-based billing over flat subscription fees.

Turns out AI labs need to make money to actually make a profit

One thing that the move to token-based billing exposed was how much people were wasting in tokens doing simple tasks like searching the web for documentation, or even simple git commands!

But what if we have a multi-agent system that processes different types of tasks? Do we just use a high level model like Opus or Fable to cover our bases? Or can we be smarter than that?

This is where model routing comes into play. Model Routing is a traffic system for AI that matches each user request to the appropriate model to serve that user request.

In this article, we'll take a look at how model routing works in Microsoft Foundry, how we can set up model routing, and how we can configure our agents to use model routers to choose the best model for the task it's been given.

What is model routing?

Powerful reasoning models like Fable and Opus tend to deliver better quality results but they cost more request/token plus reasoning tokens to use, and respond slower. Smaller models by comparison are faster and cheaper, but can't perform complex reasoning tasks.

In single-agent architectures, there is a tendency to pick powerful models to tokenmax our way out of the problem. However, since tokens are expensive, applying this logic to a multi-agent architecture will bankrupt you pretty quickly. Also, tasks that agents need to perform can vary in complexity, and using powerful models to perform simple tasks is counter-productive.

Model routing acts as an automated decision-making layer that analyzes incoming tasks and directs them to the appropriate model. So instead of hard-coding every request to use an expensive, high-end model like Fable, model routing matches the complexity of the task to the optimal model.

Model routing is ideal in multi-agent architectures, as different tasks fall into different complexity categories, so they would be better served being handled by models that are appropriate to the task they are given, rather than just burning tokens to use powerful models for simple tasks. The complexity of each request is assessed by the model router before models are invoked, and then the model router will decide which model matches the requirement of the request.

A friend of mine mentioned to me that he used Opus 4.8 to look up git commands. I don't want to shame him, but that's a simple web search....

Microsoft Foundry has a built-in Model router which is a trained ML model that analyzes each prompt in real-time and routes it to the most appropriate LLM for the task, optimizing for cost, quality of response, and latency. Model Router is an ML model that's been trained on numerous scenarios ranging from single prompts to complex agentic workflows. Microsoft updates the active router version with new models and routing improvements, so you don't have to.

For the remainder of this blog post, when we talk about the Model Router, that will refer to the Model Router capability in Microsoft Foundry. When we talk about model routing, that will apply to the concept. If you're confused about anything, please ask me in the comments

How does it work?

Model Router will analyze prompts based on complexity, reasoning, the task type, and other attributes. When Model Router is used with agents, it analyzes the full request context. This includes the system message, user message, tool definitions, conversation history etc.

Model Router has three routing modes for us to choose from:

Balanced considers models within a small quality band, then selects the most cost-effective.
Cost, which uses a larger quality range and then chooses the most cost-effective model.
Quality mode, which just picks the highest rated model for the prompt, and ignores the cost.

Each turn in the conversation is routed, as the Model Router works per-request, not per-session. During a conversation, you might have multiple agents using different models depending on the request. The router determines the complexity of the request based on the following:

For factual recalls, simple greeting, or basic follow-up questions, these requests are considered low complexity tasks and will use cheaper models.
Tool orchestration will route to mid-tier models to reliably generate structured tool calls at a lower cost.
Research, multi-step reasoning, and complex code generation route are highly complex tasks, and therefore typically will be routed to higher-performing, higher-cost models.

Within Foundry, we can create multiple model router deployments, with their own routing modes and model subset. For example, we can create a deployment called router-efficient that uses the cost routing mode, which then the model router uses to route our prompts to cheaper models, such as gpt-5-nano.

Deploying a Model Router in Microsoft Foundry

Setting up Model Routers in Microsoft Foundry is similar to creating a regular deployment. You can find it in the Foundry model catalog just by typing model-router:

The defaults give us Balanced mode across the full supported model set. You can also customize it if you need different routing modes or you want to restrict the subset of models to route to.

At the time of writing, model router is limited to five regions (Australia East being one of them). You don't need to deploy the underlying models first, except for any Claude models that you want to use.

In Bicep, you can create your Model Routers like so:

resource efficientRouter 'Microsoft.CognitiveServices/accounts/deployments@2025-10-01-preview' = {
  parent: account
  name: 'router-efficient'
  dependsOn: [
    project
  ]
  sku: {
    name: skuName
    capacity: routerCapacity
  }
  properties: {
    model: {
      format: 'OpenAI'
      name: 'model-router'
      version: routerVersion
    }
    routing: {
      mode: 'cost'
      models: [
        {
          format: 'OpenAI'
          name: 'gpt-5.4-nano'
          version: '2026-03-17'
        }
        {
          format: 'OpenAI'
          name: 'gpt-5-nano'
          version: '2025-08-07'
        }
      ]
    }
  }
}

Again, the model router model is just another deployment under the Microsoft Foundry account. The Foundry Project hosts the agents, with the dependsOn: [project] line preventing concurrent writes to the account.

For our sample, we'll use a triage agent to route to different agents depending on the task. The Model router for each specialist agent then selects the underlying model. In the Bicep block above, we've implemented the Cost mode so that simple tasks get routed to agents using the gpt-5.4-nano or gpt-5-nano models. This is handy when we want to further refine which models handle tasks.

The downside here is that you'll need to keep an eye on when certain models are deprecated.

Building our sample

Going back to skateboarding, imagine a multi-agentic system for a second-hand skateboard gear marketplace, where skaters can buy second-hand gear from others, instead of having to shell out hundreds of dollars to get a decent setup.

If you want to follow along with the code, check it out on my GitHub!

Listings on the marketplace might look like the following, where we hold product information, the condition of their gear, a photo, and information about who's selling it:

{
"L01": {
    "brand": "Powell Peralta",
    "model": "Flight",
    "width_in": 8.25,
    "length_in": 32.0,
    "wheelbase_in": 14.25,
    "condition": "good",
    "price_aud": 140,
    "photo": "photo of the actual item",
    "seller_id": "S01",
    "posted_days_ago": 6,
    "description": "riding it about 8 months, few chips on the tail but no cracks. pickup Brunswick or can post"
  }
}

Within the marketplace, there are sellers. The information that we might have about sellers include how long their account has been open, how many sales they have completed, how many disputes they currently have open, a satisfaction rating, and whether or not they have a verified payment:

{
"S01": { 
    "account_age_days": 1240, 
    "completed_sales": 87, 
    "open_disputes": 0, 
    "rating": 4.9, 
    "verified_payment": true 
    }
}

To demonstrate model routing, we can implement the following agents:

Agent	Job	Router	Mode
`triage`	Decide which specialist answers	`router-efficient`	Cost
`spec`	Read a width off a listing	`router-efficient`	Cost
`price`	Judge whether an asking price is fair	`router-balanced`	Balanced
`scam`	Decide whether a listing is a scam	`router-frontier`	Quality

For simple queries or triaging questions, we use lower cost models for these simple tasks. For analysis or research type tasks (such as determining whether a listing is a scam or not), we route to a frontier model.

Configuring our agents

To map our model routers, I have a config.py file that maps each specialist role to a router deployment:

def deployment_for(self, role: Role) -> str:
        return {
            Role.SPEC: self.router_efficient,
            Role.PRICE: self.router_balanced,
            Role.SCAM: self.router_frontier,
        }[role]

Agents are then created with the router deployment name like so:

def ensure_agents(project: AIProjectClient, settings: Settings) -> dict[Role, str]:
    """One agent per job, each on the router deployment that suits it."""
    created: dict[Role, str] = {}
    for role, spec in AGENT_SPECS.items():
        agent = project.agents.create_version(
            agent_name=f"deck-check-{role.value}",
            definition=PromptAgentDefinition(
                model=settings.deployment_for(role),
                instructions=spec.instructions,
                tools=spec.tools or None,
            ),
        )
        created[role] = agent.name
    return created

This produces the following agents and assignments:

deck-check-spec  -> router-efficient -> Cost mode
deck-check-price -> router-balanced  -> Balanced mode
deck-check-scam  -> router-frontier  -> Quality mode

The triage agent also uses the efficient router, so we can configure it like this:

triage_agent = ensure_triage(
    project,
    settings.router_efficient,
)

def ensure_triage(
    project: AIProjectClient,
    deployment: str,
) -> str:
    agent = project.agents.create_version(
        agent_name="deck-check-triage",
        definition=PromptAgentDefinition(
            model=deployment,
            instructions=TRIAGE_INSTRUCTIONS,
        ),
    )
    return agent.name

Having the Model Router as just another deployment in Foundry is useful here, because in our application code, it's just a model parameter.

If we didn't have this, we'd have to implement our own classifier to perform the routing to different models, which would require more code.

To observe routing decisions, each response includes the model field which shows which model was selected by the Router. We can use this field to track routing distribution across our agent's interactions:

def _record(response: Any, elapsed_ms: float) -> RequestRecord:
    usage = getattr(response, "usage", None)
    details = getattr(usage, "input_tokens_details", None)
    return RequestRecord(
        # The model field reveals which underlying model the router selected.
        model=getattr(response, "model", "unknown") or "unknown",
        input_tokens=getattr(usage, "input_tokens", 0) or 0,
        output_tokens=getattr(usage, "output_tokens", 0) or 0,
        cached_tokens=getattr(details, "cached_tokens", 0) or 0,
        latency_ms=elapsed_ms,
    )

Running our sample

Let's buy a second hand board! Take a look at the following listing:

{
"L04": {
    "brand": "Santa Cruz",
    "model": "Screaming Hand",
    "width_in": 8.25,
    "length_in": 32.0,
    "wheelbase_in": 14.25,
    "condition": "good",
    "price_aud": 40,
    "photo": "stock catalogue image",
    "seller_id": "S90",
    "posted_days_ago": 1,
    "description": "BRAND NEW SEALED. price firm and i have 3 others. msg me on whatsapp and we can do bank transfer, dont bother with the app checkout its slow",
  }
}

The Santa Cruz Screaming Hand design looks pretty good, and if it's just $40, that's a good deal!

Almost too good right? Plus that description looks a little dodgy (always beware of sellers trying to install a sense of urgency in you. It could be a scam). Let's ask our agents to check it out.

First let's get some basic facts about the deck:

L04  Santa Cruz Screaming Hand, good, 40 AUD

you> what width is this deck?
    triage    gpt-5-nano-2025-08-07      -> spec     3.8 s
    spec      gpt-5.4-nano-2026-03-17       basic       1.9 s
    > The deck width is 8.25 in.

This is a simple question asking about a fact about the deck, so as we can see, the triage agent uses gpt-5-nano to route our question to the spec agent, who can answer the simple fact check for us using a cheaper model.

Now let's see if the $40 price tag is a fair price for the board:

you> Is $40 fair for this?
    triage    gpt-5.4-nano-2026-03-17    -> price    2.9 s
    price     gpt-5-mini-2025-08-07         medium     68.1 s   tool: lookup_comparables
    > No — $40 is far below market for a Santa Cruz Screaming Hand. Comps for "good" condition show a median ~AUD105 (IQR ~92–120), so a realistic price is around AUD100–120 (higher if truly brand-new sealed). Also note red flags in the listing (stock photo, contradictory condition text, and request to deal off-platform) — treat $40 as suspicious and verify before paying.
    > Estimated fair value: 100 AUD

Oh, ok. We can see that the triage agent has routed our question to the price agent, which has used our balanced routing mode to produce an answer for us. It's also highlighted a couple of issues that it sees with the listing, mentioning contradictory information about the condition, and request to complete the transaction off-platform.

Let's see what our scam detector agent thinks of this! For this, we'll need to route our task to an agent who uses a frontier-level model, which is what our scam detector does.

you> Is this seller dodgy?
    triage    gpt-5-nano-2025-08-07      -> scam     3.8 s
    scam      gpt-5.5-2026-04-24            frontier    4.8 s   tool: lookup_seller_history
    > Yes — this looks very dodgy. The listing uses a stock catalogue image, the account is only 3 days old with 0 completed sales and no verified payment, the price is very low at 40 AUD for a “brand new sealed” Santa Cruz deck, and the seller is pushing WhatsApp plus bank transfer instead of app checkout.
    > Verdict: likely scam — avoid and do not pay off-platform.

Our scam agent, which uses a frontier level model, has identified that this seller looks very dodgy, and listed the reasons why it's come to that verdict.

So the triage agent has selected the scam detector agent, whose Model Router has selected the gpt-5.5 model to detect the scam, helping us avoid an obvious scam.

N.B I had too much fun with this example as you could probably tell...

Conclusion

Hopefully you now have a better understanding of how model routing works in Microsoft Foundry. You just deploy it like any other model deployment, configure your agents to use the model router, and the model router will select a model according to the configured mode and model subset.

Let this be your sign to ease up on the token spending when building your agents, and let easier tasks be handled by lower cost models. Models like Opus and Fable are powerful (and a lot of fun), but use their power in the proper place.

One thing I didn't cover too deeply here is how evaluations work for Model Routing. That's probably another blog post for itself, but I'd recommend checking out the Model Router Auto Evaluation toolkit made by the Foundry team.

If you haven't already, check out the sample on my GitHub.

If you have any questions about this, please feel free to reach out to me on BlueSky!

Until next time, Happy coding! 🤓🖥️