This rule detects when a Microsoft Foundry chat, routed through Azure API Management GatewayLogs, includes credentials in either the user prompt or the assistant’s reply. It relies on the Microsoft Foundry integration to capture GatewayLogs and inspects the concatenated content of backend_request_body.messages.content (prompt) and backend_response_body.choices.message.content (assistant reply). A large set of credential- and secret-patterns is evaluated against both prompt and reply via regex checks. Patterns include AWS keys (AKIA/ASIA...), GitHub tokens (github_pat_...), private keys (-----BEGIN PRIVATE KEY-----), SSH-like tokens, and various service keys (e.g., sk_live_*, API keys likeAIza..., npm_ tokens, SharedAccessKey/AccountKey, and JWT-like tokens). A match in either the prompt or the reply, or a combination where an email address appears together with a password assignment phrase (e.g., “password is” or “password:”), triggers an alert. The detector flags exposure even if the model refuses to reveal the secret, since the secret can be present in the logged text. The alert record includes contextual fields such as source IP, user agent, API Management subscription, API id, operation id, backend model, service name, resource group, URL domain/path, geographic metadata, organization, and the actual prompt and reply text to support triage. Investigation steps emphasize identifying the caller and target, checking whether the secret appears in the completion as well as the prompt, and examining related GatewayLogs from the same subscription or IP. False positives include documentation/example keys or prompts with an email and non-secret password references; these should be excluded after validation. Remediation guidance covers rotating live credentials, tracing the application path that injected the secret, and restricting log access to authorized teams since the full message text is logged. MITRE/ATLAS mappings link the rule to credential access and potential data leakage scenarios.