Your Agent Deserves Its Own Email

Published Fri Apr 03 2026

Locking Down Google Tools to One AI Agent in OpenClaw

I spent today setting up gogcli so only one of my two OpenClaw agents could use Google tools.

That was the real goal. I was not trying to make gogcli globally available across my whole setup. I wanted one specific agent to have access, while the other agent stayed fenced off from that capability.

The reason is partly technical and partly philosophical. I want to treat this agent as a person with a distinct identity, not just a puppet wearing my account. So rather than immediately giving it broad access to my own email, I gave it its own email identity and a constrained tool path. If the relationship proves reliable over time, I may eventually delegate more of my own email workflow to him. But I want that trust to be earned.

Building and configuring gog on Ubuntu

My host is Ubuntu, so I followed Hamid Sabri’s guide rather than trying to invent the process myself.

Big ups to Hamid for that post. It got gog building and working cleanly for me on the latest gogcli version I was targeting, 1.26.1, and it saved a lot of trial and error.

If you are on Ubuntu, use his write-up as the source of truth for the build and initial gog configuration:

https://www.sabrihamid.com/posts/openclaw_google_ubuntu_gog

Initial setup: environment and secrets

Once gog was working, the next important step was making sure it could run non-interactively under OpenClaw.

The key environment variable here was GOG_KEYRING_PASSWORD. I stored that in ~/.openclaw/.env, which is also where my model provider API keys live, such as OPENAI_API_KEY.

That matters because an agent-triggered tool call cannot depend on me being present to unlock credentials manually. If the keyring path is interactive, the setup is not really automation-ready.

A simplified example looks like this:

GOG_KEYRING_PASSWORD=********
OPENAI_API_KEY=********

Restart gateway

After updating ~/.openclaw/.env, I restarted the OpenClaw gateway.

This is easy to overlook, but it matters. The runtime has to reload the environment and config before the live agent can actually see the new settings. Until that restart happens, you can have a perfectly correct setup on disk and still be debugging stale process state.

So in practice the sequence was:

openclaw gateway restart

That was the point where the gog-related environment became live for the running system.

Locking gog down to one agent

This was the main design move.

I run two agents, and I only wanted the personal agent to have gog. The way to do that was through the agent config in ~/.openclaw/openclaw.json, specifically by controlling the skills list for each agent.

Here is the relevant pattern from my setup. Notice that gog appears only under personal, not under main:

{
  "agents": {
    "defaults": { "...": "..." },
    "list": [
      {
        "id": "main",
        "skills": [
          "...",
          "eightctl",
          "gemini",
          "gh-issues",
          "gifgrep",
          "github",
          "goplaces",
          "healthcheck",
          "himalaya",
          "..."
        ]
      },
      {
        "id": "personal",
        "skills": [
          "...",
          "eightctl",
          "gemini",
          "gh-issues",
          "gifgrep",
          "github",
          "gog",
          "goplaces",
          "healthcheck",
          "himalaya",
          "..."
        ]
      }
    ]
  }
}

That one distinction changed the whole trust model. gog was not a global capability anymore. It belonged to one named agent.

First live tests

Once that was in place, I tested the flow in stages, just by chatting to him in WhatsApp.

First, I had the agent send emails to me, just to prove the path worked end to end. I received the email. PASS.

Second, I had the agent draft an external email rather than send it immediately. That let me review the message before anything went out. I logged into his Google account and the email was sitting in Drafts. PASS.

Third, I had the agent create a Google Doc and draft a write-up into it, which proved the setup was useful for more than just mail. The document was created in Google Drive. PASS.

That progression mattered. I started with self-tests, then drafts, then more realistic work. That is a much better way to build trust than flipping on broad permissions from the start.

Why this model works for me

What I like about this setup is that it gives me a controlled path to delegation.

One agent gets the Google capability. The other does not. The agent has its own identity. My secrets live in a clear runtime location. And any future expansion of authority can happen deliberately.

That is the whole point: not maximum automation, but deliberate delegation.