Secrets in LLM logs: how coding-agent tokens end up in gateway bodies
What LiteLLM reported on October 21, 2026, where copies of a request can sit, and the exact settings to read in your own setup.
Founder, Newly
Published Last updated
Yes, they can. A gateway sees every request and response that passes through it, including any token an agent places in either, and it stores them wherever message logging is on. On October 21, 2026 LiteLLM reported that an attacker obtained GitHub CLI OAuth tokens from the logs of its own internal deployment.
What did LiteLLM report about tokens in its logs?
The facts below come from LiteLLM's own incident post, read on October 24, 2026. The post was still marked as an open investigation at that check, so treat the cause as unconfirmed.
| Question | What the report says |
|---|---|
| What was in the logs | GitHub CLI OAuth tokens. LiteLLM says Claude Code will, in specific situations, embed a user's token in a response body, and that where response bodies are logged the token may appear in the logs. |
| Where the logs were | LiteLLM's own internal deployment, which the attacker accessed without authorization. |
| What the attacker did | Took the tokens from the logs and used them to compromise the project's release workflow. |
| What is still open | How the attacker reached the deployment. LiteLLM suspects a recently patched vulnerability and had not confirmed it. |
Datadog Security Labs describes the downstream result: the malicious release of version 1.107.0 that followed. That part of the incident is covered on our LiteLLM page for app builders. This page stays with the logging question, which applies to any gateway.
What this report does not say
It does not say every gateway logs bodies, and it does not list the situations in which a token appears. It names one tool and one token type. Use it as a reason to look, and read your own logs for the answer.
How does a token end up in a request or response body?
A gateway is built to sit in the middle. Claude Code's own documentation lists audit logging of every model request as something a gateway provides. Logging bodies is therefore a normal feature, and the logs are only as careful as their settings.
A credential can reach the gateway by three routes.
- Request headers. Claude Code's compatibility guide says the developer's gateway credential travels in the
Authorizationheader, thex-api-keyheader or both. A log that records headers records that credential. This is our reading of the guide, not a statement from it. - Response bodies. This is the route LiteLLM reported, with a GitHub token in a response.
- Request bodies. A body carries whatever the agent chose to send as context. LiteLLM did not report this route, but it is the same class of risk, and OWASP's LLM02:2026 entry lists credentials among the data an LLM system can disclose and says to restrict and scrub logs and traces before they reach monitoring tools.
GitHub's documentation lists the token prefixes you can search for: ghp_ for a classic personal access token, github_pat_ for a fine-grained one and gho_ for an OAuth access token.
Where can copies of a request sit?
One request can leave several copies. The table uses LiteLLM's setting names because that is the gateway in the report. Defaults are from the documentation as read on October 24, 2026. Other gateways use other names for the same ideas.
| Place | Setting to read | Documented default |
|---|---|---|
| Logging callbacks | turn_off_message_logging under litellm_settings. It keeps messages and responses out of callbacks while spend metadata is still recorded. | false |
| Spend log table | store_prompts_in_spend_logs, disable_spend_logs and maximum_spend_logs_retention_period in the config settings reference. | Prompts off (false), logs on, retention cleanup off (null) |
| Process logs | set_verbose, json_logs and the LITELLM_LOG variable. The production guide recommends set_verbose: False and LITELLM_LOG="ERROR". | Read your own file and environment |
| Tracing tool | A masking function. In Langfuse the JavaScript mask option applies to the input, output and metadata of every observation. | None unless you write one |
| AI provider | Retention terms. OpenAI's data controls page says abuse monitoring logs are kept up to 30 days by default. | Set by the provider |
What should you check in your own setup?
Plan for an hour. Work in the order below, and write down the date and the result of each step.
1. List every hop between your agent or app and the provider
Include a hosted gateway, a self-run proxy, a server function that forwards AI calls, and any tracing tool wired into them. Each hop is a place bodies can be written down.
2. Read the settings in the table above
Open the gateway's config file and its environment. Note the value of each setting, including the ones left unset. An unset value means the documented default applies.
3. Search the stores for credentials
Search the log files, the trace store and the spend log table for the token prefixes above, for your AI provider's key prefix, and for the header names Authorization and x-api-key. Do this inside your own systems and keep the matches out of chat tools and tickets. GitHub's secret scanning covers repositories, issues, pull requests, discussions, wikis and gists. Its documentation does not describe scanning a log store, so run your own search there.
4. Reduce what gets written
OWASP's Logging Cheat Sheet says access tokens, session identifiers, passwords, database connection strings and encryption keys should be removed, masked, hashed or encrypted before they are logged. For an LLM gateway, that means message logging off or masked, a retention period set, and debug output off in production. Then restart the process and confirm the new setting is the one running.
5. Act on what you found
| What you found | State | Next step |
|---|---|---|
| A live token or key in a log, trace or row | Detected | Revoke it with the issuer, create a replacement, then reduce logging. GitHub's revocation page covers the options. |
| Message logging on, search found nothing | Unknown | The search covers today's records only. Turn logging down and set retention. |
| Logging off, restart shown, search saved | Confirmed by owner evidence | Confirmed for that hop only. Provider-side copies and other hops still need their own check. |
If a token did appear, our guides on rotating secrets and on leaked AI service keys give the order to work in, and red.run.cloud has a rotation guide for site owners. If your gateway answers from the open internet, start with the exposed gateway page.
Does this apply if I built my app with Newly?
Newly builds a real iPhone and Android app with React Native and Expo, and you can download the code or connect your own repository. This page applies to you in three cases:
- You run your own gateway or proxy for the AI features in your app.
- You use a coding agent against a gateway for your project's development.
- Your server code writes AI requests or responses to a log. In the code you downloaded, look for logging calls next to the lines that call an AI provider.
AI inside a Newly app uses credits, and a provider key that sits in a log is a key someone else may be able to use. For the wider checklist see Is my AI-built app secure? and the notes on supply-chain attacks on AI tooling.
Where do you stand?
Every item starts as unknown. Move an item to confirmed only when you hold the evidence listed under it.
Your LLM log check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Do all LLM gateways log request and response bodies?
No source says they all do. It depends on the product and its configuration. LiteLLM's documentation lists separate settings for message logging, prompts in spend logs and debug logging, so the answer for your gateway is in its config file and in the destinations it sends traces to. Read those before assuming either way.
Is this a Claude Code problem?
LiteLLM's report names Claude Code and a GitHub CLI token, and says it saw this in specific situations. It does not say other agents are free of the behaviour, and it gives no list of situations. Treat any tool that talks to your gateway as able to place a credential in a body, and look at what your own logs hold.
I turned message logging off. Is the old data gone?
No. Turning the setting off stops new message content from reaching your logging callbacks. Records already written stay where they are. LiteLLM's documented default for spend log retention is no automatic cleanup, so old rows remain until you purge them or set a retention period.
I found no token in my logs. Do I still need to rotate anything?
Not because of this check. A search finds what is there today, within the retention you keep, and says nothing about records already deleted or copies held by a tracing tool or a provider. If your gateway was ever reachable from the internet, read the exposed gateway page and decide on rotation from that.
Can the red.run.cloud scan see inside my logs?
No. Both scans work from outside. The free scan can report a console or panel that is reachable from the internet, which is one way logs get read, but it cannot tell what a log store contains. What is in the logs stays unknown until you search them yourself.
Does my AI provider keep a copy of the request as well?
Possibly. OpenAI's documentation says abuse monitoring logs are kept for up to 30 days by default, and that the Responses API keeps stored data for 30 days when store is true or omitted. Check the retention page of every provider your gateway forwards to.
Sources
All sources were read on October 24, 2026.
- Security incident, October 21, 2026, LiteLLM
- LiteLLM compromised on PyPI and Docker, Datadog Security Labs
- Logging: message redaction settings, LiteLLM docs
- Proxy config settings, LiteLLM docs
- Production recommendations, LiteLLM docs
- Other LLM gateways, Claude Code docs
- Gateway compatibility guide, Claude Code docs
- Logging Cheat Sheet, OWASP Cheat Sheet Series
- LLM02:2026 Sensitive Information Disclosure, OWASP GenAI Security Project
- Token expiration and revocation, GitHub docs
- About authentication to GitHub (token prefixes), GitHub docs
- About secret scanning, GitHub docs
- Data controls in the OpenAI platform, OpenAI developer docs
- Masking, Langfuse docs