OpenClaw v2026.4.22 Blocks Cross-Bot Token Replay on Teams

OpenClaw v2026.4.22 tightens how Teams audience tokens are accepted, closing off a path that could let one bot’s token be replayed against another bot in the same enterprise environment. The release, published on GitHub on April 22, changes token validation so shared Bot Framework audience tokens must now identify the configured application through a verified appid or azp claim.

The change matters in Microsoft Teams deployments where more than one bot may be present, especially in organizations that share infrastructure across multiple agents. In that setting, a token issued for one bot should not automatically be trusted by another. OpenClaw’s new check is designed to make sure the token presented to the runtime actually belongs to the app that is configured to receive it.

Bot Framework tokens are used to prove that a request is coming from a legitimate conversational client or service. In practical terms, they are part of the authentication layer that keeps bots from accepting messages or actions from the wrong source. If a token can be replayed across bots, an attacker or misconfigured service could potentially cross boundaries between agents that were meant to stay isolated.

The specific change in v2026.4.22 focuses on the appid and azp claims, both of which are standard fields in identity and authorization tokens. The appid claim identifies the application associated with the token, while azp, short for authorized party, identifies the party that was authorized to receive the token. By requiring one of those claims to match the configured app, OpenClaw adds a stronger check that the token was meant for that bot and not just any bot in the shared audience.

That matters because Teams bot deployments can become complicated quickly. Enterprises often run multiple internal assistants, workflow bots, or service bots under the same tenancy, and those bots may share parts of the Microsoft identity and messaging stack. When that happens, authentication mistakes are not just an abstract security issue, they can become a route for lateral movement, where access gained in one place is used to reach another system or agent.

This release is a targeted hardening step rather than a broad redesign. It does not change what Teams is or how Bot Framework authentication works at a high level. Instead, it narrows the acceptance rules inside OpenClaw so the runtime can distinguish between a token that is valid in general and a token that is valid for this specific configured app.

For teams operating OpenClaw in a Microsoft Teams environment, the update reflects a familiar security pattern, verify more identity context before accepting a request. That approach is especially important in shared enterprise deployments, where different bots may live side by side but still need strict separation at the authentication boundary.