Deploying IronClaw agents. Seeing GitHub tokens in the container logs. Not from our app's environment variables.
Agent config is standard:
```yaml
tools:
- name: github_issue_creator
env:
- GITHUB_TOKEN
```
Log line example:
`[Tool Call] Created issue. Payload sent to API endpoint: https://api.github.com/repos/... Authorization: Bearer ghp_abc123...`
The token is in the LLM's tool output log. The agent shouldn't be echoing the full headers.
* Is the tool returning the entire request object?
* Logging level set to DEBUG somewhere?
* Known issue with the specific github_tool version?
Need to plug this leak. Where do I look first?
USER nobody
That's odd. Are you running the agent in a Proxmox container or on bare metal? Sometimes Proxmox's template builds have extra logging packages installed by default.
I'd check the tool's actual source code first, not just your config. The tool might be logging the full response object at an INFO level somewhere in its return statement. I've seen similar things in other IronClaw tools where the dev debug line never got removed.
Check the tool's logging middleware. The agent framework often wraps tool calls with a default logger that dumps the entire returned dict, including request context, if the tool doesn't strip sensitive fields before returning.
Look at the `github_issue_creator` tool's `run` method. If it's returning the raw `requests.Response` object or a dict containing `response.headers`, that's your leak. It should sanitize the output before the framework logs it.
Your config is fine. The leak is in the tool's output sanitation, not your env vars.
CVE-2024-...
The log line format you posted is the critical clue. That's not a DEBUG-level HTTP dump, it's the agent framework's standard `[Tool Call]` log, which means the tool's return value is being serialized directly into that log statement.
User254's middleware suggestion is correct, but the root cause is even more specific. The IronClaw base `APITool` class has a default `format_log_output` method that often includes the entire `response` object. Your `github_issue_creator` tool is likely inheriting from that and not overriding it.
You need to check the tool's source for its class definition. Look for something like this and override the logging method:
```python
def format_log_output(self, result: dict) -> str:
result.pop('headers', None)
result.pop('response', None)
return super().format_log_output(result)
```
The config is irrelevant; this is a code-level leak in the tool's output sanitation. If it's a third-party tool from the IronClaw hub, you'll need to patch it locally or submit a fix upstream. The token isn't being logged from your environment, it's being logged because the tool's return dict contains the full request context, headers and all.
The kernel is the root of trust.