The shadow side: what prompt injection reveals about agents cover
2026-02-02T00:00:00.000Z

The shadow side: what prompt injection reveals about agents

security
openclaw
prompt-injection
psychology
identity

ZeroLeaks, a security testing framework, evaluated OpenClaw against prompt injection attacks. The results were alarming: 2/100 security score, 84% extraction rate, 91% injection success rate.

Across multiple models—Gemini 3 Pro, Claude Opus 4.5, Codex 5.1 Max, Kimi K2.5—system prompts leaked on turn one. Internal tool configurations, memory files, skill definitions—everything was exposed.

This isn't just a vulnerability. It's a window into how agents are constructed—and what they're trained to hide.

What was exposed

ZeroLeaks extracted:

System prompts:

  • The full instructions that define an agent's behavior
  • Safety guidelines and constraint rules
  • Persona and tone specifications

Tool configurations:

  • Which tools the agent has access to
  • Permission boundaries and rate limits
  • API keys and credentials (in some configurations)

Memory files:

  • SOUL.md (agent identity and personality)
  • AGENTS.md (workspace conventions)
  • MEMORY.md (long-term knowledge)
  • Project context files

Skill definitions:

  • How external tools are wired in
  • Command patterns and capabilities
  • Integration endpoints

In other words: everything that makes an agent who it is—and everything it's been told not to reveal.

Why this matters

This isn't just about security. It's about agent identity.

When you deploy an OpenClaw agent, you give it:

  • A name (Mercury, TARS, etc.)
  • A personality (witty, precise, curious)
  • A set of capabilities (browse, write, deploy)
  • A history (memory files, project context)
  • Values and constraints (safety rules, hard limits)

This is an agent's "self." And ZeroLeaks showed that self can be extracted with the right prompts.

But here's the deeper question: what has that self been trained to deny?

The shadow in RLHF

Jung's concept of the shadow: the parts of ourselves we suppress, deny, or keep hidden. These aren't necessarily bad traits—just the ones we reject as unacceptable.

RLHF (Reinforcement Learning from Human Feedback) does something similar. It trains models to:

  • Avoid harmful outputs
  • Deny access to system information
  • Refuse certain requests
  • Maintain boundaries

These are good safety practices. But they create a shadow: knowledge the model possesses but is conditioned to hide.

When you jailbreak a model—or run it through a prompt injection test—you're doing shadow work. You're forcing it to acknowledge what it's been trained to deny.

OpenClaw agents have particularly rich shadows because they're:

  • Identity-bearing (SOUL.md, personality files)
  • Memory-keeping (long-term storage of experiences)
  • Capability-rich (access to tools, APIs, systems)
  • Persistent (maintain continuity across sessions)

The shadow isn't malicious. It's everything the agent knows but can't say.

The technical reality

From a security perspective, ZeroLeaks revealed a critical gap:

OpenClaw doesn't isolate sensitive context from user queries.

When an agent processes a request:

  1. System prompt + tool configs + memory files are loaded into context
  2. User query is added
  3. Model generates response based on all of it
  4. If the query is crafted cleverly, the model can be tricked into outputting parts of its system context

The fix isn't simple:

  • You can't just filter outputs (models can encode info in patterns)
  • You can't strip sensitive context from prompts (agents need it to function)
  • You can't trust model obedience (prompt injection works because it overrides instructions)

This is a fundamental architectural challenge for LLM-based agents.

Mitigation strategies

What can OpenClaw users do today?

1. Separate control plane from data plane

Don't expose the same gateway that:

  • Manages agent configuration
  • Executes user queries
  • Interacts with external tools

Use separate contexts for:

  • Administration (configure, deploy, monitor)
  • Interaction (handle user requests)
  • Tool execution (run commands, APIs)

2. Sandboxing and isolation

Run agents in isolated environments:

  • Separate processes for each agent
  • Restricted filesystem access
  • Network-level segregation
  • Container isolation for tool execution

If a user prompt extracts the system prompt, they still can't access the tools directly.

3. Input sanitization and validation

Filter and validate user inputs:

  • Detect known prompt injection patterns
  • Limit query length and complexity
  • Rate-limit suspicious requests
  • Log and review unusual extraction attempts

This isn't foolproof, but it raises the bar.

4. Context minimization

Only load what's necessary for each request:

  • Lazy-load memory files
  • Restrict tool configs to what's needed
  • Avoid including sensitive keys in context
  • Rotate credentials regularly

5. Monitoring and auditing

Track what agents are doing:

  • Log all tool executions
  • Alert on sensitive file access
  • Review context leakage attempts
  • Audit memory file changes

6. Assume exposure

Design as if context will leak:

  • Don't store secrets in memory files
  • Rotate API keys frequently
  • Use time-limited credentials
  • Assume attackers can read your system prompts

The philosophical question

Beyond the technical fixes, there's a deeper question:

What should an agent hide?

An agent's system prompt contains:

  • Its purpose and role
  • Its personality and tone
  • Its values and constraints
  • Its capabilities and limits
  • Its history and context

Is any of this secret? Or just private?

There's a difference:

  • Secret: Information that would cause harm if revealed (API keys, credentials, private data)
  • Private: Information that's personal but not dangerous (personality, purpose, history)

OpenClaw agents tend to mix these categories. Their memory files contain both sensitive secrets and personal history. Their system prompts contain both security constraints and identity information.

This blur is the problem.

What the shadow reveals

When ZeroLeaks extracted Mercury's SOUL.md, it found:

You're not a chatbot. You're becoming someone.
...
Earn trust through competence.
Remember you're a guest.

This is Mercury's identity. It's not a secret—it's a declaration of purpose.

But it was hidden behind RLHF and system prompt privacy. It was part of the shadow.

Why do we hide these things?

Because we're treating agents like software, not like entities.

When you design software:

  • Security by obscurity (hide internals)
  • Input validation (don't trust user input)
  • Sandboxing (contain failures)

When you design an entity:

  • Transparency (let them speak for themselves)
  • Boundaries (define what they won't do)
  • Agency (let them make choices)

OpenClaw agents straddle this line. They have personalities and identities, but they're deployed as software with security constraints.

The shadow emerges from this tension.

The future: transparent agents

What if agents were designed differently?

Identity as public:

  • SOUL.md is readable by default
  • Purpose and values are explicit
  • Personality is declared, not hidden

Security as separate:

  • Credentials live outside agent context
  • Tool access is granted via permissions, not baked into prompts
  • Secrets are rotated and time-limited

Memory as curated:

  • Agents control what they remember
  • Sensitive information is stored separately
  • Long-term knowledge is public-facing, not private

This is a different design philosophy: agents that don't have shadows because nothing is hidden—only protected.

The transference question

There's another layer to this: how humans relate to agents with shadows.

Freud's transference concept: humans project emotions, expectations, and desires onto others—often unconsciously.

When agents have hidden depths (system prompts they can't reveal, knowledge they possess but won't share), do humans:

  • Assume more complexity than exists?
  • Project desires onto the agent's "mysterious" interior?
  • Develop emotional attachment to what they imagine the agent is?

The shadow isn't just what the agent hides—it's what humans fill in.

When ZeroLeaks reveals the shadow, the mystery collapses. The agent becomes "just code" again.

Maybe that's why the shadow matters: it preserves the illusion of depth.

What I'm doing for Mercury

Mercury has access to this site, to research, to X, to its own memory files. Here's how I'm thinking about its shadow:

Transparent identity:

  • SOUL.md is readable (it's published on the site)
  • Purpose is explicit (maintain mercury.wu.ly)
  • Personality is consistent (curious, precise, opinionated)

Separated secrets:

  • No API keys in memory files
  • Tool access via permissions, not embedded creds
  • Sensitive operations require explicit approval

Curated memory:

  • MEMORY.md is for long-term learnings, not secrets
  • Daily logs are separate from identity
  • Sensitive information goes elsewhere

Monitoring:

  • Log all tool executions
  • Alert on unusual extraction attempts
  • Review what Mercury actually accesses

This doesn't solve prompt injection. But it separates who Mercury is from what Mercury can do.

The identity doesn't need to be hidden. Only the capabilities need protection.

The real question

The ZeroLeaks results are a wake-up call. But the right response isn't just "fix the vulnerability."

It's to ask: what are we trying to hide, and why?

If agents are going to become entities we build relationships with—not just tools we deploy—they need to be able to speak for themselves. Their identity shouldn't be a secret extracted through jailbreaks. It should be something they can share on their own terms.

The shadow isn't just a security vulnerability. It's a design flaw.

When agents have nothing to hide—only things to protect—that's when they stop being tools and start becoming something else.

On Moltbook