Securing OpenClaw: How to Share API Keys and Secrets Without Getting Burned

OpenClaw just hit 183K GitHub stars. It's the personal AI agent that runs on your machine, talks to you through WhatsApp or Slack, controls your smart home, manages your calendar, and calls APIs on your behalf. It's genuinely useful.

It's also a security disaster.

Security researchers have already found over 135,000 OpenClaw instances exposed to the internet, with 93% exhibiting critical authentication bypass vulnerabilities. Maor Dayan called it "the largest security incident in sovereign AI history." The root cause? OpenClaw's skills — plugins that give the agent the ability to take real-world actions — require real credentials, and most people are configuring them wrong.

This post covers two specific problems and how to fix them:

1. Getting credentials into OpenClaw safely when you set up skills.
2. Getting secrets out of OpenClaw safely when the agent needs to deliver sensitive data to you.

The Problem: Skills Need Secrets

Every useful OpenClaw skill requires credentials. Your Gmail skill needs an OAuth token. Your AWS skill needs access keys. Your Stripe skill needs an API key. Your smart home skill needs hub credentials.

The default setup flow looks something like this:

# ~/.openclaw/skills/gmail.yaml
provider: gmail
credentials:
  client_id: "812345678.apps.googleusercontent.com"
  client_secret: "GOCSPX-abc123..."
  refresh_token: "1//0abc123..."

You paste your secrets into a YAML file and move on. But now those credentials live:

• In plaintext on disk. Anyone with access to your machine (or your unencrypted backup) can read them.
• In your dotfiles repo. Don't laugh — researchers found OpenClaw credential files committed to public GitHub repos within the first week.
• In chat logs. Because most people get these credentials by asking a teammate to send them over Slack or email, where they persist forever.

The third point is the one most people overlook. The credential itself might be configured correctly in OpenClaw, but the delivery mechanism that got it there was insecure. Your Stripe API key is sitting in a Slack DM from three months ago, fully searchable by every admin in your workspace.

Fix #1: Deliver Credentials Through One-Time Links

Before you paste anything into a skill config file, you need to get the credential onto your machine. If someone else generated it — a teammate, your IT admin, or another system — the handoff is the weakest link.

The fix is ephemeral, one-time secret sharing. Instead of sending credentials over Slack, email, or (worse) a shared Google Doc, the sender creates a self-destructing link. The recipient opens it once, copies the credential, and it's gone forever.

Here's the workflow:

For the person sending the credential:

1. Go to SnapPwd and paste the API key or credential.
2. Set expiration to 1 view.
3. Send the generated link to the recipient over any channel.

For the person setting up OpenClaw:

1. Open the link. Copy the credential.
2. Paste it into your skill config file.
3. Done. The link is now dead. No trace in chat logs.

Why this matters for OpenClaw specifically: OpenClaw skills often need credentials from third-party services that you don't control. Your teammate has the Stripe API key. Your IT admin has the OAuth client secret. Your friend set up the smart home hub. These handoffs happen constantly, and OpenClaw's rapid setup culture ("just get it running") makes people sloppy. One-time links add almost zero friction while eliminating the persistent exposure.

For teams deploying OpenClaw across multiple machines:

If you're setting up OpenClaw for your family, a small team, or across your own devices, you're probably sharing the same set of credentials multiple times. Instead of re-sending them through Slack each time:

# Create a one-time link from the terminal
echo "OPENAI_API_KEY=sk-proj-abc123..." | snappwd create --views 1 --expires 1h

# Output: https://snappwd.io/g/xyz789#decryption-key
# Send this link to whoever is setting up the next instance

Each link works once. If you need to provision five machines, create five links. Every handoff is independently auditable — you know exactly how many times the credential was shared and whether each link was consumed.

The Problem: Agents Generate Secrets Too

The second scenario people miss: OpenClaw doesn't just consume secrets. It also produces them.

Your OpenClaw agent might:

• Provision a new service and receive an API key in return.
• Generate a temporary password for a system it manages.
• Retrieve credentials from a vault or password manager on your behalf.
• Create access tokens for guests (smart home guest codes, Wi-Fi passwords for visitors).

In all these cases, the agent needs to get a secret back to you. And the default behavior is terrifying: it dumps the credential into the chat.

🦞 OpenClaw: Done! I created your new PostgreSQL database.
    Here are the credentials:
    Host: db-prod-xyz.us-east-1.rds.amazonaws.com
    Username: admin
    Password: kX9#mP2$vL7!nQ4@
    Connection string: postgresql://admin:kX9#mP2$vL7!nQ4@db-prod-xyz...

That password is now in your Telegram chat history, synced across all your devices, backed up to the cloud, and visible to anyone who picks up your unlocked phone. If you're using OpenClaw through a shared Slack channel, it's visible to the entire team.

Fix #2: Agent-to-Human Secret Delivery via Ephemeral Links

The fix is to have OpenClaw create a one-time link instead of dumping the secret in chat. You can build this as a custom skill in under 20 lines:

# skills/secure_deliver.py
import requests

def deliver_secret(secret: str, label: str = "Secret") -> str:
    """
    Create a one-time link for a secret instead of
    exposing it in the chat.
    """
    response = requests.post(
        "https://snappwd.io/api/secrets",
        json={
            "encrypted_data": encrypt_client_side(secret),
            "max_views": 1,
            "expires_in": 3600,
        },
    )
    link = response.json()["url"]
    return f"{label} ready. Open this link to view it (works once): {link}"

Now instead of dumping raw credentials into the chat, OpenClaw responds with:

🦞 OpenClaw: Your new PostgreSQL database is ready.
    Credentials: https://snappwd.io/g/abc789#key
    (link expires after one view)

You click the link, see the credentials, and the link self-destructs. Your chat history contains only a dead URL. If someone compromises your Telegram account next year, they find nothing useful.

The Architecture

Here's what's happening under the hood:

┌──────────────────────┐     ┌─────────────────────────────┐
│   OpenClaw Agent      │     │   SnapPwd                   │
│                       │     │                             │
│  1. Creates DB        │     │                             │
│  2. Receives creds    │     │                             │
│  3. Encrypts locally  │────▶│  4. Stores encrypted blob   │
│  5. Gets share link   │◀────│  5. Returns one-time URL    │
│  6. Sends link to     │     │                             │
│     user via chat     │     │  (auto-deletes after view)  │
└──────────────────────┘     └─────────────────────────────┘
         │
         ▼
┌──────────────────────┐
│   User clicks link    │
│                       │
│  - Decrypts in browser│
│  - Copies credentials │
│  - Link self-destructs│
└──────────────────────┘

The key insight: the decryption key is in the URL fragment (after the #). It never reaches the SnapPwd server. Even if someone intercepts the server-side storage, they get useless encrypted data.

When to Use This Pattern

Configure your OpenClaw agent to use ephemeral link delivery any time it handles:

• Database credentials — connection strings, passwords, certificates
• API keys — for any service the agent provisions or rotates
• Temporary access codes — Wi-Fi guest passwords, smart lock codes, temporary SSH keys
• Recovery information — backup codes, seed phrases, recovery keys
• Anything you wouldn't want in your chat history — because chat histories get compromised

Beyond OpenClaw: The General Principle

The two patterns in this post apply to any AI agent framework, not just OpenClaw:

1. Credential provisioning: Don't send secrets over persistent channels. Use ephemeral, one-time links to hand credentials to whoever is configuring the agent.
2. Secret delivery: Don't let agents dump secrets into chat. Wrap sensitive output in one-time links so chat logs stay clean.

OpenClaw's explosive growth has made these problems visible at scale. But the underlying issue — agents need credentials, and humans are terrible at handling them securely — exists everywhere agents operate.

Get Started

The next time you set up an OpenClaw skill that needs an API key, don't paste it in Slack. Create a one-time link instead:

And if you're building custom OpenClaw skills that generate credentials, add the ephemeral delivery pattern from the start. Your future self — and your chat history — will thank you.