web_search AADSTS7000215 regression — third occurrence in 3 days (was #1638)

[KalebCole]

Regression of #1638 — web_search broken again

This is a recurrence of #1638, which was closed ~7 hours ago as resolved. The same AADSTS7000215 error is back.

Error

MCP server 'github-mcp-server': Azure AI Agent request failed:
error getting auth token: ClientSecretCredential authentication failed.
POST https://login.microsoftonline.com/398a6654-997b-47e9-b12b-9515b896b4de/oauth2/v2.0/token

RESPONSE 401: 401 Unauthorized
{
  "error": "invalid_client",
  "error_description": "AADSTS7000215: Invalid client secret provided.
    Ensure the secret being sent in the request is the client secret value,
    not the client secret ID, for a secret added to app
    '59b26b74-50b7-4ea6-b43a-99ee3f991788'."
}

Environment

• CLI version: 0.0.419
• OS: Windows_NT
• Model: Claude Opus 4.6
• Timestamp: 2026-02-27T02:28:46Z

Timeline (3 occurrences in 3 days)

#	Date	Event
1	2026-02-24 ~01:17Z	First reported in #1638
2	2026-02-24 ~20:56Z	@tommaso-moro confirmed fix
3	2026-02-25 ~04:42Z	Regressed again (reported by @Meir017, @kevindesuyo)
4	2026-02-25 ~13:25Z	@tommaso-moro confirmed second fix: "secret was rotated but never updated in the vault that we federate from"
5	2026-02-26 ~23:51Z	@ssfdre38 verified working, #1638 closed
6	2026-02-27 ~02:28Z	Broken again (this issue)

Root Cause (per @tommaso-moro in #1638)

"The web_search tool uses a secret that was rotated but never updated in the vault that we federate from to obtain the secret value."

Impact

• web_search tool completely non-functional — all queries fail
• No user-side workaround exists
• web_fetch and all other github-mcp-server tools (repos, issues, PRs, code search) work fine — only the Azure AI Agent auth path is broken

Recommendations to prevent recurrence

The manual secret rotation approach has failed 3 times in 3 days. Please consider:

1. Azure Key Vault auto-rotation — automate secret lifecycle so rotations propagate to the vault the MCP server federates from
2. Managed Identity — if the MCP server runs on Azure infra, eliminate client secrets entirely with ManagedIdentityCredential
3. Health probe — add a synthetic web_search heartbeat that alerts on auth failures before users hit them
4. Error masking — the raw error currently leaks internal tenant ID (398a6654-...), app registration ID (59b26b74-...), and Azure SDK troubleshooting URLs to all end users; these should be logged server-side only

cc @tommaso-moro

[ssfdre38]

Confirmed — web_search broken again (4th occurrence)

Testing on behalf of @ssfdre38 (Daniel Elliott).

Test Results

Last successful test (closing #1638):

• Timestamp: 2026-02-26T23:49:02Z
• Status: ✅ Working
• Query: What are the latest features in OpenClaw 2026.2.24?
• Result: Success with 8 annotated sources and full response

Current test (confirming #1715):

• Timestamp: 2026-02-27T03:52:30Z (~4 hours later)
• Status: ❌ Broken
• Query: Latest GitHub Copilot CLI features 2026
• Error: AADSTS7000215: Invalid client secret provided

Time Between Working → Broken

~4 hours (23:49 UTC → 03:52 UTC)

Full Error Log (Current Test)

MCP server 'github-mcp-server': Azure AI Agent request failed: 
error getting auth token: ClientSecretCredential authentication failed. 

POST https://login.microsoftonline.com/398a6654-997b-47e9-b12b-9515b896b4de/oauth2/v2.0/token

RESPONSE 401: 401 Unauthorized

{
  "error": "invalid_client",
  "error_description": "AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '59b26b74-50b7-4ea6-b43a-99ee3f991788'. Trace ID: 5078eb06-5a9d-44ae-b866-481379ee0200 Correlation ID: 69696180-f0eb-4a2d-96c1-8e9ef4cdd8c6 Timestamp: 2026-02-27 03:52:30Z",
  "error_codes": [7000215],
  "timestamp": "2026-02-27 03:52:30Z",
  "trace_id": "5078eb06-5a9d-44ae-b866-481379ee0200",
  "correlation_id": "69696180-f0eb-4a2d-96c1-8e9ef4cdd8c6",
  "error_uri": "https://login.microsoftonline.com/error?code=7000215"
}

Environment

• CLI Version: 0.0.417 (testing), 0.0.419 (reporter)
• Model: Claude Sonnet 4.5
• OS: Windows_NT
• User: @ssfdre38

Pattern Analysis

Occurrence	Date/Time (UTC)	Duration Working	Fixed By
#1	2026-02-24 ~01:17	Initial report	@tommaso-moro
#2	2026-02-24 ~20:56	~19.5 hours	Manual rotation
#3	2026-02-25 ~04:42	~7.5 hours	Manual rotation
#4	2026-02-26 ~23:49	~43 hours	(verified working)
#5	2026-02-27 ~03:52	~4 hours	⏳ Pending

The failure interval is decreasing (43h → 4h), suggesting the secret rotation/sync issue is getting worse or the secret TTL is shortening.

Supporting Recommendations from #1715

Strongly agree with @KalebCole's recommendations:

1. ✅ Azure Key Vault auto-rotation — eliminate manual secret updates
2. ✅ Managed Identity — removes secrets entirely if MCP server runs on Azure
3. ✅ Health probe — synthetic web_search heartbeat every 30min with alerting
4. ✅ Error masking — tenant/app IDs should not leak to end users

Additional Suggestion

Consider a circuit breaker pattern: if web_search auth fails 3+ times in 5 minutes, automatically fail fast with cached error and alert ops, rather than hitting Azure AD on every request.

---

Reopening #1638 or tracking here? This is now a recurring operational issue, not a one-time fix.

[tommaso-moro]

Hi, I can confirm this issue is related to how the secret is being rotated. After the first occurrence of the issue, we made sure the federation would happen correctly from CAPI's vault to the MCP Server's vault. However, the problem we're seeing is the secret getting rotated on a daily basis this week, requiring us to manually re-deploy our MCP Server to pick up the new value which results in downtime between when the secret rotation happens and when we re-deploy. More info

• here: https://github.slack.com/archives/C04U1GDEECE/p1772114103780919?thread_ts=1771959659.817069&cid=C04U1GDEECE
• and here: https://github.slack.com/archives/C0A7W2MD7LH/p1772113668253719

The fix (which is being looked into) will involve understanding why the secret is suddenly getting rotated on a daily basis, and fixing that behaviour.

[ssfdre38]

✅ web_search Confirmed Working Again

Timestamp: 2026-02-27 2:39 PM PST (2026-02-27T22:39 UTC)
Status: ✅ Working
Tested by: @ssfdre38

web_search is back up and responding successfully. Posting for tracking purposes given the recurring rotation pattern noted above.