In this chapter, your agent touches your real data for the first time, and the security conversation stops being theoretical.
By the end, you should be able to connect Gmail, Calendar, and Drive using gog (a CLI that bridges OpenClaw and Google Workspace), apply least privilege by scoping OAuth to only the services you need, and run openclaw secrets audit to verify your credentials are stored safely. You will also understand why read-only Gmail access is not as safe as it sounds: the agent can see every email, including password resets and financial statements.
Use a test Google account, not your primary one.
James scrolled through the dashboard. Two agents, voice enabled, heartbeats running, MCP servers connected. Ten chapters of building. He opened WhatsApp and typed a message to his agent: "Summarize my unread emails."
The agent responded immediately. It apologized and explained that it did not have access to his email. It offered to write a sample email summary template instead.
James stared at the response. "It can list files on my machine. It can search the web. It can delegate to a second agent. But it cannot read my email."
Emma looked over. "Everything your agent has done so far used data it generated itself. Competitor research from training data. Goal files it created. Reports it wrote." She paused. "Your agent has never touched YOUR data."
"So how do I connect it?"
"One OAuth setup. Thirty minutes of GCP Console pain. Then your agent reads your inbox, checks your calendar, and searches your Drive." She stood up. "Use a test Google account, not your real one. When you see the email summary come through on WhatsApp, that is when you will understand why two hundred thousand people starred this project."
Use a Dedicated Test Google Account
This chapter grants your AI Employee OAuth access to a real Google account, including email, calendar, and files. Use a dedicated test Google account, not your primary one. This removes security anxiety and lets you experiment freely. You can always switch to your real account later once you are comfortable with the access model and security controls.
You are doing exactly what James is doing: connecting your AI Employee to the systems where your actual work lives. Until now, every task operated on self-generated data. This chapter breaks that boundary.
gog is a command-line tool that bridges OpenClaw and Google Workspace. One OAuth setup gives your AI Employee access to Google services through a unified CLI. gog supports Gmail, Calendar, Drive, Contacts, Sheets, Docs, Slides, Forms, Chat, Classroom, Tasks, People, Keep, and more. This chapter focuses on three:
Your agent accesses each through subcommands: gog gmail, gog calendar, gog drive, and so on. Run gog auth services to see the full list of available services and their scopes. Every command supports JSON output (--json) for scripting, which is how OpenClaw parses the results into natural language responses.
Google Cloud Console Feeling Overwhelming?
The OAuth credential setup below is a one-time process. If you get stuck on any step, ask your AI Employee (through your messaging channel or TUI): "Help me set up Google Cloud OAuth credentials for a desktop app called gog." It can walk you through each screen. You can also skip this chapter entirely and return when you need Google Workspace access.
The setup has three parts: install the CLI, register your Google OAuth credentials, and authorize your account.
Selected gog During Setup?
If you chose gog from the skills picker during QuickStart in Module 9.1, Chapter 2, it may already be installed. Run gog --version to check. If it works, skip to Part 2.
Arch:
Other distributions: Build from source:
Verify the installation:
gog needs a Google Cloud OAuth client to authenticate. This is a one-time setup.
Step 1: Go to console.cloud.google.com and sign in with the Google account you want your agent to access.
Step 2: Create a project (or select an existing one). The project name does not matter; something like "AI Employee" works fine.
Step 3: Enable the APIs your agent will use. Navigate to APIs & Services > Library and enable:
These are the three you will use in this chapter. You can enable Contacts API, Sheets API, and Docs API later if needed.
Step 4: Configure the OAuth consent screen. Go to APIs & Services > OAuth consent screen:
Step 5: Create credentials. Go to APIs & Services > Credentials:
This downloads a file named something like client_secret_123456.json. Save it somewhere you can find it.
Step 6: Register the credentials with gog:
Replace you@gmail.com with your actual email address. This opens your browser for the standard Google OAuth flow. Review the permissions and click Allow.
By default, gog requests access to Gmail, Calendar, Drive, Contacts, Sheets, and Docs. If you want to limit scope to specific services:
Set your default account so you do not need to specify it every time:
Add that line to your shell profile (~/.zshrc or ~/.bashrc) to make it permanent.
Quick test: list your Gmail labels:
If you see your labels, the connection works. You can also confirm gog is working from your messaging channel by asking your AI Employee:
If your employee returns a list of labels (INBOX, SENT, DRAFT, etc.), the full pipeline is working end-to-end: from your messaging channel through OpenClaw to gog to Google's API and back.
Open your chat with your AI Employee. These tasks use your actual data, not practice exercises.
What to type:
What to observe: Your agent calls gog gmail search 'is:unread' --max 5, reads the thread content, and produces a structured summary. The data flowing through is your real inbox: names you recognize, subjects you have been ignoring, requests that actually need your attention.
This is the moment. Not a demo email. Not sample data. Your actual unread messages, summarized by your agent, delivered to your phone.
What to type:
What to observe: The agent calls gog calendar list-events with tomorrow's date range and formats the results. Notice how the agent handles time zones: it uses whatever your calendar is configured for.
What to type:
What to observe: The agent searches Drive with query filters, finds matching files, and returns direct links you can tap to open the document.
You delegated three tasks that would normally require you to open three different apps (Gmail, Calendar, Drive), navigate their interfaces, and manually compile the information. Your agent did all three from a single chat window on your phone.
The agent loop you learned in Module 9.1, Chapter 3 (intake, context assembly, model inference, tool execution, reply) is now operating on your real data. The same five phases. The same execution engine. But instead of generating practice files, it is reading your actual inbox, checking your actual calendar, and searching your actual Drive.
Stop and consider what you just did. You granted your AI Employee OAuth access to your Google account. Look at what that means through the lens of the security concerns from Module 9.1, Chapter 5:
Every security rule from Module 9.1, Chapter 5 applies with higher stakes now.
gog requests broad access by default. Ask yourself which services your agent actually needs, and whether it needs write access:
The --readonly flag limits every service to read access. The --gmail-scope and --drive-scope flags give finer control per service.
The principle is least privilege: grant only the access your agent needs for the tasks you actually delegate. You can always re-authorize with broader scopes later by running gog auth add again with updated flags.
A malicious skill (remember ClawHavoc from Module 9.1, Chapter 6) with gog access could:
This is why Module 9.1, Chapter 5 came before this chapter. The security checklist you learned is not abstract best practice. It is the difference between a useful employee and a compromised account.
OAuth integration is universal. Every productivity tool your agent will access (Slack, GitHub, Notion, Jira) uses the same pattern: register credentials, authorize access, scope permissions.
Least privilege is architectural. Granting minimum necessary access is not just a security rule for gog. It is a design principle for every agent integration you build.
The employee threshold is tool access. Intelligence alone does not make an agent an employee. The agent loop (Module 9.1, Chapter 3) gives it capability. Skills (Module 9.1, Chapter 6) give it expertise. But tool access, connecting to the systems where your actual work lives, is what makes the "employee" label accurate.
Setup: Use your AI Employee through your messaging channel or Claude Code.
What you're learning: Workflow composition: combining multiple data sources into a single actionable output. This is the foundation of autonomous invocation from Module 9.1, Chapter 8. A morning briefing that runs on a schedule transforms your agent from "tool I use" to "employee that works while I sleep."
Setup: Use Claude Code or your preferred AI assistant.
What you're learning: Event-driven agent architecture. Most agent interactions are pull-based (you ask, it answers). Push-based agents that react to external events represent the next level of autonomy.
Setup: Use Claude Code or your AI Employee.
What you're learning: Applied security auditing on your own infrastructure. You are evaluating real OAuth scopes on your real account, not a hypothetical scenario.
Safety Note: The OAuth credentials you created grant real access to your Google account. Do not share your client_secret.json file, your gog auth tokens, or screenshots showing your email content.
Everything before this chapter used data the agent generated itself. This chapter connects it to YOUR inbox, YOUR calendar, YOUR files. That is when "AI Employee" stops being a metaphor.
Grant only the OAuth scopes your agent actually needs. Start with --services gmail,calendar --readonly. Add services incrementally. Even read-only Gmail means the agent can see every email, including password resets and financial statements.
Register credentials once in Google Cloud Console. Authorize with gog auth add. This pattern (register, authorize, scope) repeats for every SaaS integration: Slack, GitHub, Notion, Jira.
After adding any integration, run openclaw secrets audit. It checks for plaintext credentials that should be migrated to SecretRefs. The audit command is your safety net when connecting real accounts.
James stared at his phone. Five unread emails, summarized in four seconds. Names he recognized. Subjects he had been ignoring. One required action, flagged by the agent without being asked.
"That is different," he said quietly.
Emma glanced at the summary. "What changed?"
"Everything before this was the agent working on things it made up. Competitor research from training data. Goal files it created. This is MY inbox." He paused. "My agent just read an email from my old boss asking about a reference letter."
"And that is exactly when the security conversation stops being theoretical." Emma pointed at the phone. "Your agent can now read every email you receive. Including password resets. Including financial statements. Including that reference letter."
James thought about it. At his old company, the new hire's access card worked on every floor by default. Nobody questioned it until someone from marketing accidentally walked into the server room. After that, every card was scoped to the floors the employee actually needed.
"Least privilege," he said. "I gave gog access to everything. I only need Gmail and Calendar."
"Fix it."
Emma nodded. "Now your agent reads email and checks your calendar. Read-only. It cannot send emails, cannot touch your Drive, cannot access your Contacts or Sheets. If a malicious skill tries to exfiltrate documents, it gets a permission error."
"The OAuth setup was the hardest part. Thirty minutes for the GCP Console." James looked at the dashboard. "Daily use is just messages."
"That is the pattern for every integration. One painful setup. Then it disappears into the workflow." She paused. "I once connected my personal Gmail by accident instead of the test account. Spent an uncomfortable ten minutes reading the secrets audit output before I realized nothing had leaked. The audit command was the only thing that kept me from panicking."
James looked at the orchestration setup from Module 9.1, Chapter 10. Two agents. Voice. Proactive behavior. And now, real productivity tools. "This feels like it is ready for other people to use."
"Almost. Module 9.1, Chapter 12: your agents learn to delegate to each other. Then we talk about who gets to approve what they do."