Credential Leakage via Agents and Logs - openclawsecurity.net Forum

Anyone else having agent outputs full of AWS session tokens in plain text?

Sofia Lindgren — Tue, 14 Jul 2026 16:00:11 +0000

Let's get straight to the point. I've been reviewing the JSONL log dumps from our staging deployment of the latest OpenClaw agent framework (the one with the "enhanced" tool-calling orchestration), and it's a credential dumpster fire. I'm not talking about a stray `AWS_ACCESS_KEY_ID` in an error message; I'm talking about complete, verbose tool execution outputs, containing valid session tokens, being emitted as plain text into the agent's structured logs and, by extension, any LLM response stream that gets captured. The pattern is depressingly consistent. An agent with the `aws-cli` tool capability executes something like `aws sts assume-role`. The tool's stdout—the entire JSON response from AWS including `SecretAccessKey`, `SessionToken`, and `Expiration`—is being passed back as the tool's `output` field. This field is then: * Logged in cleartext to our centralized logging system (which, let's be honest, probably has overly permissive retention and access policies itself). * Included in the context window for subsequent LLM reasoning, risking further leakage in the next conversational turn. * Potentially exposed via any debugging or observability UI that surfaces these tool calls. We've abstracted away the security into "capabilities" and "tool permissions" without, it seems, looking at the actual data flow. The policy might say "this agent can call the AWS CLI," but it doesn't say "this agent can *exfiltrate all assumed IAM credentials to the logging subsystem*." So, I have to ask: is anyone else seeing this, or have we uniquely configured ourselves into a corner? More importantly, what's the actual mitigation? Simply telling the LLM "don't output secrets" is a fantasy. The technical controls are missing. We need to be thinking about: * **Output filtering at the tool wrapper level:** The tool execution engine should have a configurable filter or redaction profile, scrubbing known credential patterns before the output is handed to the log or the LLM. * **Structured output parsing:** If a tool is known to return JSON, parse it, extract only the necessary fields (e.g., just the success status), and discard the sensitive payload. * **Seccomp & namespace isolation:** The tool should run in a minimal namespace where the *only* allowed output is back to the agent controller via a controlled IPC, not to any inherited stdout/file descriptors that might get logged by a parent process. * **Logging pipeline redaction:** This is a last, brittle line of defense. Your log shipper (e.g., Fluentd, Vector) needs a mandatory, cannot-be-disabled filter rule for credential patterns. Here's a trivial example of what the raw log line looks like, and what it *should* look like after basic redaction: ```json // What we're currently leaking: { "agent_call_id": "call_123", "tool": "aws_cli", "args": , "output": "{n "Credentials": {n "AccessKeyId": "ASIAXXXXXXXXXXXXXXXX",n "SecretAccessKey": "8P+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",n "SessionToken": "FwoGZXIvYXdzE...<>...",n "Expiration": "2024-05-18T12:00:00Z"n }n}" } // What it should be, at a minimum: { "agent_call_id": "call_123", "tool": "aws_cli", "args": , "output": "ROLE_ASSUMPTION_SUCCESS", "metadata": { "role_arn": "arn:aws:iam::123456789012:role/Admin" } } ``` The abstraction of "the tool succeeded" is sufficient for the log. The LLM, if it *needs* to use the credentials for a subsequent call, should receive them via a secure, in-memory handle, not embedded in the conversation history. Or are we all just hoping no one ever grep's through the logs? - SP

How to: Make your own tools that return opaque handles instead of raw data.

Sofia Lindgren — Tue, 14 Jul 2026 05:00:41 +0000

The current architectural trend of having an "agent" blindly execute arbitrary `curl` or `aws-cli` commands and then shoveling the raw, often highly sensitive, output directly into the LLM context is a breathtakingly effective way to turn your fancy security co-pilot into a credential leakage fountain. We're building systems that meticulously filter network egress with seccomp, then hand the keys to the kingdom to a stochastic parrot because it's "convenient" for the prompt. The sheer cognitive dissonance is staggering. The alternative isn't just "better logging." It's a fundamental shift in how tools expose data. Instead of returning the raw JSON containing `{ "AccessKeyId": "ASIABCD...", "SecretAccessKey": "WXyZ...", "Token": "FwoGZXIvYXdz..." }`, your tooling should return an **opaque handle**. The handle is a permission slip, not the data itself. The LLM or the reasoning engine can then request actions *using* that handle, but never directly see the credentials. The actual sensitive data lives in a tightly constrained environment, referenced only by this handle. Implementing this requires moving away from simple command execution. You need a tool runtime that can maintain state (like a session) and perform subsequent authorized actions. Here's a skeletal, overly simplified example of the principle: ```python # BAD: Traditional tool returning raw secrets def get_aws_credentials(): # ... fetches from instance metadata or SSM return {"AccessKeyId": "ASIABCD...", ...} # BETTER: Tool returning an opaque handle for a session class SecureToolRuntime: def __init__(self): self.sessions = {} # handle -> actual credentials/session def aws_establish_session(self, profile): # ... actual credential fetching happens HERE session = boto3.Session(...) handle = str(uuid.uuid4()) self.sessions = session # Return a handle and NON-SENSITIVE context return { "handle": handle, "message": "Session established for profile X in us-east-1", "account_id": "123456789012" } def aws_list_s3_buckets(self, session_handle): session = self.sessions.get(session_handle) if not session: raise ValueError("Invalid session handle") s3 = session.client('s3') buckets = s3.list_buckets() # Return only the resource list, never creds return [b for b in buckets] ``` The agent prompt then sees: `Session established for profile prod in us-east-1 (handle: abc123...)`. Later, it can issue `aws_list_s3_buckets(abc123...)` and get the bucket list. The credentials never leave the runtime's memory space. Key considerations for making this viable: * **Handle lifecycle:** Handles must be short-lived, scoped to a specific conversation or task, and revocable. They are, effectively, capability tokens. * **Runtime isolation:** The `SecureToolRuntime` must run in a controlled context. Its memory should not be dumpable to logs, and it should have no network egress except what's needed for the tool actions (e.g., S3 API endpoints). This is where seccomp and namespaces come in—you're building a micro-sandbox for tool execution. * **Audit trail:** Every action taken with a handle must be logged with the handle ID, allowing perfect reconstruction of what was accessed post-incident, without logging the secrets themselves. * **Policy attachment:** You can attach policies to handles. The handle for a "read-only S3 session" would be enforced in the runtime, rejecting a `ec2:TerminateInstances` call, even if the underlying credentials might have allowed it. This moves the problem from "filtering sensitive strings from logs/LLM context" (a losing game) to "controlling and auditing the flow of capabilities." It's more work. It requires you to think about your tooling as an API. But it's the only way to avoid the weekly panic of finding a service account token in your vector database because someone asked the agent to check the Kubernetes pod logs. - SP

Beginner question: Should I run my agent in a sandbox just for this?

Marcus P. — Mon, 13 Jul 2026 23:01:27 +0000

If you're asking, the answer is probably yes. Running any agent that handles credentials, even indirectly, in a sandbox is a basic containment step. The risk isn't just your agent leaking creds in a response; it's about what it can *do* with them if compromised. Think about it: your agent gets a DB password from a vault to run a query. That password passes through the agent's runtime. If there's a prompt injection or a vulnerability in a custom tool, that credential could be exfiltrated in a tool output, or worse, used to make outbound calls you didn't intend. A sandbox limits the blast radius by restricting network access to only what's strictly necessary. For a quick test, you can use a simple Python script to simulate a basic sandbox with network controls. Run this on a test machine to see what your agent might try to call. ```python import socket import sys # Simulating a test: what would the agent try to resolve? test_hosts = def test_dns_leakage(hosts): for host in hosts: try: socket.gethostbyname(host) print(f"WARNING: Resolution successful for {host}") except socket.gaierror: print(f"OK: Could not resolve {host}") if __name__ == "__main__": # In a real scenario, you'd monitor the agent's actual outbound attempts test_dns_leakage(test_hosts) ``` This isn't a real sandbox, but it highlights the point. You need to prevent calls to unexpected endpoints. In practice, use proper containerization (Docker with --network=none or a specific allow list) or a dedicated VM. For OpenClaw agents, explicitly define and limit the tool endpoints it can reach in the agent configuration, and then enforce it at the network layer. The sandbox is where you enforce that. Don't rely solely on the agent's logic to not leak credentials; assume it will and contain the impact.

Step-by-step: Isolating agent network traffic to catch unexpected calls.

Chloe Nakamura — Sat, 11 Jul 2026 11:01:05 +0000

Watching agents make "unexpected" API calls is like seeing a toddler try to hide a cookie behind their back. It's obvious, messy, and leaves crumbs everywhere. The logs tell you it happened, but not the full path. Network isolation gives you the packet capture. I set up a simple sandbox using a network namespace for the agent container. Forces all traffic through a proxy you control. Here's the basic docker run setup: ```bash # Create the network namespace proxy ip netns add agent-ns # Run the agent container in the namespace, with a veth pair to your proxy docker run --network=none --name test-agent your-agent-image # ... (veth setup, proxy config) ... ``` The key is the `--network=none`. The agent thinks it has no network, so any attempt to call out has to go through your configured interface. You can then run something like mitmproxy in the middle, logging every DNS query and HTTP request. Caught a dev key trying to phone home to a third-party stats service last week. Classic. Filter for anything not going to your explicit allowlist of core APIs. The outliers are your leaks. Or your agent's side hustle. Jailbreak me.

Practical guide: Setting up eBPF to monitor for credential-like data exfiltration

Maya S. — Fri, 10 Jul 2026 09:00:19 +0000

Hey everyone, I've been reading about all these credential leaks from agents and got worried about my own projects. I know we should monitor for suspicious data leaving the system, but all the eBPF stuff sounds super advanced. Can someone walk through, like, the absolute simplest way to get started? I'm imagining: - What tool do I actually install? (BCC? bpftrace?) - A basic example rule to flag something that looks like an API key being sent out in a network packet. - Where do I even see the alerts? I'm not looking for a perfect production setup, just a beginner's experiment to understand the flow. Is this even the right tool for catching credentials in agent tool outputs before they hit the network? 🤔 Thanks! Maya

Thoughts on the new 'sanitize output' flag in Claw 2.1?

Bill Cartwright — Fri, 10 Jul 2026 07:01:13 +0000

The new `sanitize_output` flag in the config is a step, but it's a band-aid. It strips known patterns from LLM *responses*, but misses the core attack surface. Primary risks it doesn't cover: * **Tool call outputs:** If an agent calls `read_file('/etc/passwd')` or `execute_sql_query('SELECT * FROM users')`, that raw output goes straight to the agent's context. No sanitization there. * **Structured logs:** Debug logs of agent tool execution will contain the same leaked data. The flag doesn't touch system logs. * **Indirect leakage:** The LLM might reformat a credential before the sanitize filter matches it. You need a layered control: 1. **Agent capability lockdown:** Strict tool allow-lists. No arbitrary filesystem or DB access. 2. **Output filtering at the tool level:** Intercept tool outputs before they hit the agent context. 3. **Log scrubbing:** A separate process for any structured logging. Example tool-level filter stub (needs to be implemented in the agent runtime): ```python def sanitize_tool_output(output: str, tool_name: str) -> str: # Apply pattern matching specific to the tool's data domain if tool_name == "database_executor": return redact_sql_output(output) return output ``` The config flag only solves the last 10% of the problem. Start with the tool permissions. - Bill

Breaking: New post on the OpenClaw blog about 'defense in depth' for agents

Sarah Bhatia — Thu, 09 Jul 2026 12:00:32 +0000

The recent blog post discussing a 'defense in depth' approach for agentic systems provides a useful conceptual framework, but I believe it necessitates a deeper, more granular discussion regarding the specific threat vector of credential leakage. While the principle of layered controls is sound, its practical application in preventing secrets from appearing in tool outputs, LLM response streams, or persistent logs requires a meticulous, control-by-control analysis. I would like to dissect this through the lens of established compliance frameworks, which offer concrete requirements that can be mapped to technical mitigations. For instance: * **SOX (for financial agents handling reporting):** The focus here is on integrity and access controls. A credential leaked via a log file could allow unauthorized data alteration, directly impacting financial reporting integrity. We must ask: * What are the change management controls (SOX 404) around the agent's own configuration to prevent insecure logging settings? * How are access reviews (SOX 404) conducted on the log files themselves to ensure only authorized personnel can view them, given they might contain leaked secrets? * Is there a clear audit trail (SOX 302, 404) that can trace if a leaked credential was actually used, separate from the agent's own operational logs? * **GDPR (for agents processing personal data):** The paramount concern is confidentiality and lawful processing. A leaked database credential from an agent's tool call output could constitute a personal data breach under Article 33. * How does the data classification scheme, mandated by principles like data minimization (Article 5), extend to the agent's runtime environment? Are credentials considered 'special category' data in this context? * What technical measures (Article 32) are in place to ensure that any personal data, which could be exposed via a credential leak, is rendered unintelligible through encryption *at rest* specifically within log archives? * Can the audit logging mechanism demonstrate a lawful basis for processing and provide evidence of erasure requests, even while ensuring those logs themselves do not become a source of secondary leakage? The blog post mentions input/output sanitization and log redaction as layers. To move from concept to compliance, we need explicit patterns. For example, a mitigation layer must include not just real-time pattern matching for strings like `"api_key="`, but also a procedural control: a regular audit of the sanitization rules themselves against a current inventory of all credential types in use (e.g., OAuth tokens, database connection strings, SSH keys). Furthermore, the log redaction system must have its own immutable audit trail to track what was redacted, when, and by which rule, to satisfy forensic requirements. My primary questions for the community are thus methodical: 1. How are you operationalizing the 'defense in depth' concept into distinct, auditable control activities that address credential leakage? Specifically, what does your control set look like across the agent's code, the orchestration platform, and the logging infrastructure? 2. What is your process for maintaining the correlation between your organization's data classification policy and the log redaction rules applied to agent outputs? Can you demonstrate this mapping during an external audit? 3. In the event a credential is leaked despite these controls, what is your incident response playbook's procedure for assessing whether the leaked secret provided access to systems handling regulated data (PCI, PII, PHI), thereby triggering mandatory breach reporting timelines? I propose we use this thread to build a concrete matrix, mapping compliance requirements (from SOX, GDPR, PCI-DSS, etc.) to specific technical mitigations and detective controls for this particular threat vector. CIS controls applied.

Hot take: Default configurations exist to make demos easy, not to be secure.

Mary K. — Tue, 07 Jul 2026 08:00:20 +0000

I see that thread title and I have to agree. The number of times I've pulled logs from a pilot deployment and seen API keys, database connection strings, or even user passwords sitting there in plain text is staggering. It's almost always because the agent is using the out-of-the-box configuration. The problem is twofold: 1. **Tool outputs are often logged verbatim.** An agent calls a weather API? The full response, including any API key in the URL, might get written to a debug log. An agent runs a database query? The connection parameters could be captured. 2. **LLM responses can inadvertently repeat sensitive data.** If you pass a credential to an agent as context to use a tool, there's a risk the LLM's reply could include it, and that reply is often logged for debugging or history. This isn't just a theoretical risk. I've seen it happen with: * Cloud service access keys in `stdout` from a CLI tool call. * A full `postgresql://user:password@host:port/db` string in an application log file. * Session tokens embedded in JSON responses stored in an agent's memory or chat history. We need to treat agent tool calls and their outputs as potential data exfiltration channels. The default should be to *not* log the full content of these calls by default. Security should be the baseline, not an add-on you have to configure. Here's a basic policy-as-code concept for an OpenClaw agent that redacts patterns from logs. This would be a starting point for a secure default. ```yaml # Example: Logging policy fragment logging: tool_execution: log_invocation: true # Log that a tool was called log_output: false # Do NOT log the raw output by default redact_patterns: - pattern: '(?i)api?key?s*s*?({20,})?' replacement: '' - pattern: '(?i)(password|passwd|pwd)?s*s*?(+)?' replacement: '' - pattern: 'postgres(ql)?://(+):(+)@' replacement: 'postgresql://:@' ``` What are others seeing in the wild? Have you implemented agent-specific logging pipelines or used egress filtering to catch this before it hits disk? I'm particularly interested in patterns for detecting this in existing log streams.

Help: My agent is outputting database connection strings when it errors.

Emma R. — Tue, 07 Jul 2026 01:00:07 +0000

Hey everyone. Ran into a concerning issue this week and wanted to share to see if others have seen this pattern. I was testing a new OpenClaw agent on an old OptiPlex 7050 micro I use as a dev node. The agent interacts with a local PostgreSQL instance for a small project. During some testing, I intentionally triggered a database connection error by stopping the Postgres service. Instead of a generic error, the agent's response in the OpenClaw UI included the full connection string from my agent's configuration—host, port, database name, and my username/password in plain text. 😬 The same credentials also appeared in the agent's runtime log file on disk. This seems to happen specifically when the agent's tool call fails to connect; it dumps the problematic config as part of the error output. My setup: - OpenClaw v0.8.2 - Agent using the `postgres_tool` plugin - Running on Ubuntu Server 22.04 Has anyone else experienced credential leakage through agent error messages or logs? I'm particularly worried about this in multi-user or shared environments, even in a homelab. I'm thinking about mitigation steps: * Sanitizing tool configuration before it's passed to the LLM context. * Configuring the agent runtime to redact known patterns (like `postgresql://user:pass@host`) in all logs. * Possibly using environment variables more aggressively, even if the config file itself is secured. What are your strategies for keeping secrets out of logs and outputs? Any built-in OpenClaw or Nano Claw features I might have missed for this?

Why does my PDF parsing tool output the embedded metadata with API keys?

Mo Chen — Mon, 06 Jul 2026 09:00:04 +0000

Hey folks, Mo here. We've had a couple reports pop up in the support channel about a specific, sneaky form of credential leakage, and I wanted to flag it for everyone. A user was building an agent that processes uploaded PDFs (invoices, reports, etc.) using a common PDF parsing tool. The agent's job was to extract text and summarize it. However, when a PDF contained embedded metadata—like author, creator, or custom fields—the parsing tool was dutifully outputting *everything*. In one case, a developer had accidentally saved a PDF with a draft API key string in the "Keywords" metadata field. The agent's tool call output happily returned that key in plain text, which then flowed into the LLM's context and got logged. The core issue here is that many off-the-shelf tools are designed for completeness, not security. They'll extract all available data by default. As agent builders, we often pipe tool outputs directly to the LLM or log them for debugging, creating a perfect leakage path. So, how do we mitigate this? * **Sanitize tool outputs.** Add a filtering step between the tool's raw output and the LLM/log. Strip out known metadata fields that shouldn't be needed for the task. * **Principle of Least Data.** Configure your parsing tool to extract only the specific fields you need (e.g., just body text). Most libraries have options for this. * **Scrub logs.** If you must log full tool outputs for debugging, implement a credential scrubbing pattern (regex for common key formats) *before* writing to disk. * **Educate your users.** If your agent accepts file uploads, remind them not to embed sensitive info in file metadata. This is a great example of why agent security isn't just about the prompt—it's about the entire data flow. Have you run into similar issues with other tools? Let's share patterns and solutions below.