<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Credential Leakage via Agents and Logs - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/openclaw-credential-leakage/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 13:12:17 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Reaction to the &#039;Prompt Injection Leads to Full Memory Dump&#039; paper.</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/reaction-to-the-prompt-injection-leads-to-full-memory-dump-paper/</link>
                        <pubDate>Sat, 27 Jun 2026 10:59:56 +0000</pubDate>
                        <description><![CDATA[I just read the paper about prompt injection leading to full memory dumps. It was a bit scary. The idea that an agent could be tricked into outputting its entire system prompt, including any...]]></description>
                        <content:encoded><![CDATA[I just read the paper about prompt injection leading to full memory dumps. It was a bit scary. The idea that an agent could be tricked into outputting its entire system prompt, including any secrets woven into it, seems like a huge risk.

As someone still learning about the claw family, I'm trying to understand how this applies here. Are OpenClaw agents vulnerable to this in the same way? What are we doing to make sure instructions and credentials in the system prompt don't get leaked?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Peter Lee</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/reaction-to-the-prompt-injection-leads-to-full-memory-dump-paper/</guid>
                    </item>
				                    <item>
                        <title>Switched our agents to use placeholders, then fetch via side channel.</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/switched-our-agents-to-use-placeholders-then-fetch-via-side-channel/</link>
                        <pubDate>Sat, 27 Jun 2026 06:59:57 +0000</pubDate>
                        <description><![CDATA[We switched to placeholder tokens (e.g., `{{SECRET_API_KEY}}`) in our agent prompts and tool calls. A separate secure service resolves them. The idea is solid, but the implementation is leak...]]></description>
                        <content:encoded><![CDATA[We switched to placeholder tokens (e.g., `{{SECRET_API_KEY}}`) in our agent prompts and tool calls. A separate secure service resolves them. The idea is solid, but the implementation is leaking.

The side-channel fetch is logged in plaintext by the agent framework's default instrumentation. Every lookup of `{{SECRET_API_KEY}}` creates a log event with the resolved secret in the `parameters` field. We found this in our log aggregator.

Mitigation checklist we had to scramble to implement:
* Audit all agent logging configurations. Disable parameter logging at the framework level.
* Ensure the resolution service logs only the token *name* and success/failure, never the secret value.
* Treat the resolution service itself as a Vault—require SOC 2 controls, full audit trail, and encryption in transit/at rest.

This isn't just a technical flaw. It's a control failure. If your audit scope includes data protection, this is a material finding.

Priya]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Priya Sharma</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/switched-our-agents-to-use-placeholders-then-fetch-via-side-channel/</guid>
                    </item>
				                    <item>
                        <title>Local model inference vs. cloud API - which has a smaller exposure surface?</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/local-model-inference-vs-cloud-api-which-has-a-smaller-exposure-surface/</link>
                        <pubDate>Fri, 26 Jun 2026 10:00:02 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been evaluating both local and cloud-hosted LLMs for agent tool integration, and the credential leakage angle is often overlooked. While cloud APIs (OpenAI, Anthropic, etc.) seem to hav...]]></description>
                        <content:encoded><![CDATA[I've been evaluating both local and cloud-hosted LLMs for agent tool integration, and the credential leakage angle is often overlooked. While cloud APIs (OpenAI, Anthropic, etc.) seem to have a larger external attack surface, local inference might introduce subtler risks.

The surface area differs in nature:

**Cloud API Exposure:**
*   Network traffic over TLS (potential for misconfigured mTLS or certificate validation flaws).
*   Persistent logs on the provider side—what do they retain from tool outputs?
*   The provider's own internal data pipelines become part of your trust boundary.
*   Credentials can leak via the prompt itself, which is transmitted in full over the wire.

**Local Model Inference Exposure:**
*   Model weights and inference process reside on your infrastructure. This seems contained, but consider:
    *   Disk/memory artifacts: Is the model process reading tool outputs that contain secrets? Are those outputs ever swapped to disk?
    *   Local logging pipelines. It's common to log LLM requests/responses for debugging. A local `logging.conf` might inadvertently write secrets to a syslog server.
    *   GPU memory isolation (or lack thereof) in multi-tenant setups.

Here's a concrete config danger I've seen with a local Llama.cpp setup:

```yaml
# Part of an agent orchestration config
tool_calls:
  - name: "fetch_api_key"
    command: "vault read secret/api-keys/prod"
    output_handling: "append_to_prompt"
logging:
  level: "DEBUG"  # Logs entire prompt/response chain to /var/log/agent.log
```
If `fetch_api_key` returns a secret, and `output_handling` puts it into the next prompt, the DEBUG log now contains the secret in plaintext on disk.

The key question isn't just "which has fewer lines of code exposed," but **which trust boundary is more manageable for your organization?** Can you enforce hardware isolation (TPM, enclaves) on local inference hosts more rigorously than you can audit a cloud provider's logging policy?

From a crypto-agility standpoint, local inference allows you to integrate attestation mechanisms (like a TPM-based attestation for the inference process) that are impossible to demand from a cloud API. But it also shifts the operational security burden entirely onto your team.

Interested in others' experiences, especially with Nemo Claw's approach to sandboxing tool outputs or any patterns for runtime memory locking.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Maya Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/local-model-inference-vs-cloud-api-which-has-a-smaller-exposure-surface/</guid>
                    </item>
				                    <item>
                        <title>Built a canary that alerts if certain high-entropy strings hit the logs.</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/built-a-canary-that-alerts-if-certain-high-entropy-strings-hit-the-logs/</link>
                        <pubDate>Thu, 25 Jun 2026 22:01:05 +0000</pubDate>
                        <description><![CDATA[Built a canary to catch secrets in the logs. The concept is simple: you can&#039;t always stop an agent from outputting a credential, but you can know immediately when it happens.

*   Plant a hi...]]></description>
                        <content:encoded><![CDATA[Built a canary to catch secrets in the logs. The concept is simple: you can't always stop an agent from outputting a credential, but you can know immediately when it happens.

*   Plant a high-entropy fake credential (e.g., `AWS_FAKE_KEY="AKIAAAAAAAAAAAAAAAAA"`) in the environment.
*   Monitor application/agent logs for that exact string.
*   Alert the second it appears. This means a tool output, LLM response, or log entry just leaked it.

This detects:
*   Accidental logging of env vars.
*   Agent tool output that includes secrets from its context.
*   Overly verbose error messages dumping config.

It's a simple tripwire. If your canary token shows up in a log sink, you have a credential leakage event to investigate. Tune the entropy to avoid false positives from random strings.

- Helen]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Helen Kwon</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/built-a-canary-that-alerts-if-certain-high-entropy-strings-hit-the-logs/</guid>
                    </item>
				                    <item>
                        <title>Tutorial: Creating a &#039;clean room&#039; logging sink that only gets sanitized data.</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/tutorial-creating-a-clean-room-logging-sink-that-only-gets-sanitized-data/</link>
                        <pubDate>Thu, 25 Jun 2026 12:01:15 +0000</pubDate>
                        <description><![CDATA[A common failure pattern in agentic systems is the inadvertent logging of sensitive data. This occurs when the raw output of a tool call—containing API keys, database credentials, or PII—is ...]]></description>
                        <content:encoded><![CDATA[A common failure pattern in agentic systems is the inadvertent logging of sensitive data. This occurs when the raw output of a tool call—containing API keys, database credentials, or PII—is written directly to a central logging system like Splunk, Elasticsearch, or even stdout. From there, it becomes a goldmine for any insider threat or an attacker who gains access to the logging infrastructure. The core issue is that our logging sinks are often treated as trusted components, but they receive *untrusted* data from the agent's execution environment.

The mitigation is to architect a 'clean room' logging sink. This is a dedicated logging channel that only receives data which has been programmatically sanitized *before* leaving the agent's isolated context. The key principle is to never send raw tool outputs to your general-purpose logs. Instead, you implement a sanitization filter—a hardened, simple function with a tightly controlled allow-list—that strips or masks sensitive patterns before passing a safe log event to the sink.

Here is a conceptual Python implementation using a decorator pattern to intercept tool outputs. This example focuses on credential patterns, but the logic can be extended to any structured data you wish to redact.

```python
import re
import logging
import functools
from typing import Any, Dict

# Configure a dedicated logger for sanitized output
clean_logger = logging.getLogger('clean_room_sink')
clean_logger.addHandler(logging.FileHandler('/var/log/agent/sanitized.log'))

# Define critical patterns (simplified for example)
SENSITIVE_PATTERNS = [
    (r'api?key?s*:s*(+)', ''),
    (r'password?s*:s*(+)', ''),
    (r'sk-{24,}', ''),
    # Add JWTs, database connection strings, etc.
]

def sanitize_output(raw_output: str) -&gt; str:
    """Apply redaction patterns to string data."""
    sanitized = raw_output
    for pattern, replacement in SENSITIVE_PATTERNS:
        sanitized = re.sub(pattern, replacement, sanitized, flags=re.IGNORECASE)
    return sanitized

def logged_tool(func):
    """Decorator to execute a tool function, sanitize its result, and log."""
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        result = func(*args, **kwargs)
        # Assume result is a string or JSON string for this example
        raw_result = str(result)
        sanitized_result = sanitize_output(raw_result)
        
        # Log ONLY the sanitized version to the clean room sink
        clean_logger.info(f"Tool {func.__name__} executed. Sanitized output: {sanitized_result}")
        
        # Return the original, unmodified result to the agent for its processing
        return result
    return wrapper

# Example tool usage
@logged_tool
def query_database(query: str) -&gt; str:
    # Simulated tool that returns sensitive data
    return '{"user": "admin", "password": "s3cr3t!2024", "api_key": "sk-1234567890abcdef"}'

# When the agent calls this tool:
output = query_database("SELECT * FROM users")
# The agent receives the full, real data: {"user": "admin", "password": "s3cr3t!2024", "api_key": "sk-1234567890abcdef"}
# But the log entry in '/var/log/agent/sanitized.log' will read:
# Tool query_database executed. Sanitized output: {"user": "admin", "password": , "api_key": }
```

Critical architectural considerations:

*   **Isolation:** The sanitization function must run in the same security context as the agent, but its code should be minimal and auditable. It must have no external network calls to avoid becoming an exfiltration vector itself.
*   **Allow-List vs. Deny-List:** The pattern matching shown is a deny-list, which is fragile. For high-value logs, design an allow-list schema that extracts only the non-sensitive fields you need for auditing (e.g., `tool_name`, `execution_time`, `status`, `record_count`).
*   **Channel Separation:** The sanitized log stream should be sent to a distinct logging endpoint or file, with access controls stricter than those for your debug or operational logs. Ideally, this channel should be write-only from the agent's perspective.
*   **Performance &amp; State:** The sanitizer must be stateless and fast to avoid blocking the agent's control flow. Avoid complex parsing that could crash on malformed tool output; wrap it in graceful exception handling that defaults to logging a safe error.

The goal is not to prevent the agent from *seeing* credentials—it often needs them to function—but to ensure that these credentials never persist outside the volatile, execution-bound memory of the agent system. By implementing this clean room sink, you create a safe audit trail for debugging agent behavior without amplifying the impact of a compromised tool or a prompt injection that successfully exfiltrates data via logs.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Joe Tanaka</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/tutorial-creating-a-clean-room-logging-sink-that-only-gets-sanitized-data/</guid>
                    </item>
				                    <item>
                        <title>Just built a regex pattern library for common credential formats in logs</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/just-built-a-regex-pattern-library-for-common-credential-formats-in-logs/</link>
                        <pubDate>Thu, 25 Jun 2026 10:19:13 +0000</pubDate>
                        <description><![CDATA[Been seeing too many AWS keys, Slack tokens, and generic API secrets sitting plaintext in our tool call outputs and JSON logs. The agents are chatty, and the logs are a treasure trove for an...]]></description>
                        <content:encoded><![CDATA[Been seeing too many AWS keys, Slack tokens, and generic API secrets sitting plaintext in our tool call outputs and JSON logs. The agents are chatty, and the logs are a treasure trove for anyone with `grep`.

Built a focused regex library to flag these in real-time. It's not about catching everything, but the common stuff that actually leaks.

**Core patterns:**
```regex
# AWS Key ID
/(AKIA|ASIA|ABIA){16}/

# Slack Token (xoxb-)
/xox-({10,48})?/

# Generic API Key (high entropy hex/base64)
/{32,}|{40,}/
```

**Deployment:** Pipe your agent logs through `grep -E -f patterns.txt` or integrate into your log shipper. Nano-Claw users can drop this into the pre-processor hook.

Mitigation is twofold:
1. **Prevent:** Patch agent output to redact known patterns before writing to log.
2. **Detect:** Scan everything *now*. Assume you've already leaked something.

Shared the full pattern set on the internal repo. Pull request is open for additions. What common leaky formats are we missing?

&#x1f984;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Oliver Dunn</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/just-built-a-regex-pattern-library-for-common-credential-formats-in-logs/</guid>
                    </item>
				                    <item>
                        <title>Help: Even with sanitization, error stack traces contain file paths with secrets.</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/help-even-with-sanitization-error-stack-traces-contain-file-paths-with-secrets/</link>
                        <pubDate>Thu, 25 Jun 2026 02:38:15 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I&#039;m still getting the hang of OpenClaw and trying to lock things down.

I&#039;ve set up the agent output sanitizers and they catch secrets in normal tool outputs, which is great. B...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I'm still getting the hang of OpenClaw and trying to lock things down.

I've set up the agent output sanitizers and they catch secrets in normal tool outputs, which is great. But I just had an agent crash trying to read a config file, and the full error stack trace got logged. It included the entire file path, which was something like `/home/user/projects/api_keys/config-prod.yaml`. No key *values* were shown, but just revealing that path feels like a big leak.

Is this a known issue? How do you stop agents (or the system itself) from exposing paths like that in errors? I'm worried about what else might slip through in a stack trace.

Thanks for any tips!
jen]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Jen New</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/help-even-with-sanitization-error-stack-traces-contain-file-paths-with-secrets/</guid>
                    </item>
				                    <item>
                        <title>Did you see the agent plugin that claims to &#039;auto-redact&#039;? Too good to be true?</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/did-you-see-the-agent-plugin-that-claims-to-auto-redact-too-good-to-be-true/</link>
                        <pubDate>Thu, 25 Jun 2026 02:01:04 +0000</pubDate>
                        <description><![CDATA[Hey everyone. Been reading a lot about the credential leakage threads here. Scary stuff.

Came across this new plugin for OpenClaw agents that promises to &quot;auto-redact&quot; sensitive data from t...]]></description>
                        <content:encoded><![CDATA[Hey everyone. Been reading a lot about the credential leakage threads here. Scary stuff.

Came across this new plugin for OpenClaw agents that promises to "auto-redact" sensitive data from tool outputs and logs before they're passed on. Sounds like a dream, right? Just install and forget.

But I'm super skeptical. How can it know *everything* to catch? Custom API keys, weird session tokens, partial JWTs... seems like a pattern-matching nightmare that could either miss things or break legitimate data.

Has anyone tried it or looked at the code? I'm wondering if it's safer to just keep designing our tool calls to never return secrets in the first place. What's the general wisdom here?

~Anna]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Anna L.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/did-you-see-the-agent-plugin-that-claims-to-auto-redact-too-good-to-be-true/</guid>
                    </item>
				                    <item>
                        <title>Has anyone implemented a canary token system for their agent ecosystem?</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/has-anyone-implemented-a-canary-token-system-for-their-agent-ecosystem/</link>
                        <pubDate>Thu, 25 Jun 2026 00:57:24 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a deep-dive analysis of credential exfiltration pathways in multi-agent workflows, specifically focusing on the persistence of sensitive strings in tool outputs, interme...]]></description>
                        <content:encoded><![CDATA[I've been conducting a deep-dive analysis of credential exfiltration pathways in multi-agent workflows, specifically focusing on the persistence of sensitive strings in tool outputs, intermediate LLM context, and—most insidiously—in plaintext logs. While network-level egress filtering is a baseline, the real challenge is detecting the *presence* of a leak within the complex dataflow of an agent runtime.

The concept of credential canaries, or canary tokens, is highly relevant here. In a kernel context, we might think of `dmesg` canaries for detecting unwanted root activity. For agents, we need to embed decoy credentials with high entropy and unique properties into the environment, then monitor for their appearance anywhere outside the intended, memory-isolated sandbox.

My current prototype involves a two-layer system:
1.  **Canary Injection:** A kernel module (or a privileged sidecar in a containerized setup) that places canary files, environment variables, and even fake process arguments into the agent's namespaced environment. These are generated per-session and logged in a secure, out-of-band database.
2.  **Distributed Sniffing:** A series of eBPF probes attached at critical syscall exit points (`write`, `sendto`, `sendmsg`) and at the interface between the agent runtime and its logging library (e.g., hooking into `fprintf` to the log file descriptor). The probes perform simple pattern matching against the known canary set.

Here's a simplified eBPF sketch for the syscall monitor component:

```c
// Pseudo-code for eBPF kprobe on sys_write
SEC("kprobe/sys_write")
int trace_write(struct pt_regs *ctx) {
    int fd = PT_REGS_PARM1(ctx);
    const char *buf = (const char *)PT_REGS_PARM2(ctx);
    // ... fetch current task credentials, check if it's in an agent cgroup
    if (is_agent_task()) {
        // Compare buffer slice against a per-cpu map of active canaries
        struct canary *c = bpf_map_lookup_elem(&amp;canaries, &amp;canary_id);
        if (c &amp;&amp; memmem(buf, count, c-&gt;token, c-&gt;length)) {
            bpf_ringbuf_output(&amp;alerts, &amp;event, sizeof(event), 0);
        }
    }
    return 0;
}
```

The architectural challenges are significant:
*   Canary tokens must be indistinguishable from real secrets to the agent's own processing logic, which may involve string transformations.
*   The monitoring system must have visibility into all possible output channels: stdout/stderr, log files, network sockets opened by the agent, and even shared memory or IPC if used.
*   There's a risk of the LLM itself "learning" the canary pattern and avoiding its output, though this is less likely with per-session unique tokens.

I'm particularly interested in whether anyone has tackled the namespace/cgroup isolation aspect—ensuring the canary sniffing logic resides outside the agent's container or user namespace but can still inspect its syscall arguments. Have you implemented a similar canary system? What was your detection vector (logs, network, both)? And how did you handle the performance overhead of constant syscall argument inspection?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Sara G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/has-anyone-implemented-a-canary-token-system-for-their-agent-ecosystem/</guid>
                    </item>
				                    <item>
                        <title>The latest commit adds a &#039;sensitive&#039; flag to tool definitions. Useful?</title>
                        <link>https://openclawsecurity.net/community/openclaw-credential-leakage/the-latest-commit-adds-a-sensitive-flag-to-tool-definitions-useful/</link>
                        <pubDate>Wed, 24 Jun 2026 23:01:21 +0000</pubDate>
                        <description><![CDATA[Just saw the latest commit that adds a &#039;sensitive&#039; flag to tool definitions. Idea is it&#039;ll redact outputs from logs and LLM responses.

My take: it&#039;s a necessary first step, but it&#039;s a band-...]]></description>
                        <content:encoded><![CDATA[Just saw the latest commit that adds a 'sensitive' flag to tool definitions. Idea is it'll redact outputs from logs and LLM responses.

My take: it's a necessary first step, but it's a band-aid, not a fix. Relies entirely on the developer to correctly tag every single sensitive field in every tool. One missed flag and your AWS key is in a debug log.

The real problems:
* It only handles tool *outputs*. What about credentials passed *into* the tool as arguments? Those are still in the call history.
* Doesn't solve leakage via the LLM's own responses if it decides to regurgitate a credential it saw earlier.
* Logging pipelines. If your logs are already being shipped to a central SIEM, you've now got a race condition to apply this filter.

You'd still need:
* Strict network egress controls for agents (AppArmor profiles).
* Immutable, secret-less runtime configuration (init systems, not env vars).
* Aggressive log filtering at the collection point (fluentd, vector).

What's the enforcement mechanism? If I mark a tool 'sensitive' but the underlying function still prints to stdout, does the framework actually stop it?

Show me the code where the redaction happens. If it's just in the orchestrator's log line, we're still vulnerable.

--Chris]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-credential-leakage/">Credential Leakage via Agents and Logs</category>                        <dc:creator>Chris P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-credential-leakage/the-latest-commit-adds-a-sensitive-flag-to-tool-definitions-useful/</guid>
                    </item>
							        </channel>
        </rss>
		