home / skills / openclaw / skills / gog-safety

gog-safety skill

safe

This skill helps you build and deploy safety-profiled gog binaries with compile-time command removal to enforce restricted AI agent permissions.

npx playbooks add skill openclaw/skills --skill gog-safety

Review the files below or copy the command above to add this skill to your agents.

Files (8)

SKILL.md

3.0 KB

---
name: gog-safety
description: Build and deploy safety-profiled gogcli binaries with compile-time command removal. Use when setting up gog for an AI agent with restricted permissions — choosing between L1 (draft only), L2 (collaborate), or L3 (standard write). Covers building from PR #366, deploying to remote hosts, and verifying blocked commands.
---

# gog Safety Profiles

Build and deploy `gog` binaries with compile-time command removal. Commands that are disabled don't exist in the binary — no runtime bypass possible.

## Quick Start

### 1. Choose a safety level

| Level | Use case | Can send email/chat? |
|-------|----------|---------------------|
| **L1** | Email triage, drafting, inbox organization | No |
| **L2** | L1 + commenting, RSVP, collaborative work | No |
| **L3** | Full write access, no dangerous admin ops | Yes |

For full details: `references/levels.md`

### 2. Build

```bash
# Build for current platform
./scripts/build-gog-safe.sh L1

# Cross-compile for Linux ARM64 (e.g., AWS Graviton)
./scripts/build-gog-safe.sh L1 --arch arm64 --os linux

# Custom output
./scripts/build-gog-safe.sh L2 --output /tmp/gog-l2
```

Requires: Go 1.22+, git. First run clones the PR #366 branch (~30s).

### 3. Deploy

```bash
# Deploy to a remote host via SSH
./scripts/deploy-gog-safe.sh spock /tmp/gogcli-safety-build/bin/gog-l1-safe

# Deploy with verification (tests blocked + allowed commands)
./scripts/deploy-gog-safe.sh spock /tmp/gogcli-safety-build/bin/gog-l1-safe --verify
```

The deploy script:
- Backs up the existing `gog` as `gog-backup`
- Installs the new binary
- Verifies version output
- Optionally tests that blocked commands are gone and allowed commands work

### 4. Rollback

```bash
ssh <host> 'sudo mv /usr/local/bin/gog-backup /usr/local/bin/gog'
```

## How It Works

Uses gogcli's compile-time safety profiles feature (PR #366 on `steipete/gogcli`). A YAML file specifies which commands are enabled (`true`) or removed (`false`). The build system generates Go source files with only the enabled commands, then compiles. The resulting binary's version is tagged with `-safe`.

## YAML Profiles

In `references/`:
- `l1-draft.yaml` — Draft & Organize
- `l2-collaborate.yaml` — Draft & Collaborate
- `l3-standard.yaml` — Full Write (No Admin)

Custom profiles: copy any YAML, edit the `true`/`false` flags, pass to `build-gog-safe.sh`.

## Verification

After deployment, verify with:
```bash
ssh <host> "gog --version"                     # Should show -safe suffix
ssh <host> "gog gmail send --help 2>&1"        # Should fail (L1/L2)
ssh <host> "gog gmail drafts create --help"    # Should work (all levels)
```

## Known Edge Cases

- **Filter forwarding:** `gmail settings filters create` is allowed at L1+ for inbox organization. A filter with a forward action could auto-forward email. Accepted risk for v1.
- **Drive sharing:** `drive share` is allowed at L1+ because sharing grants access without sending a message notification. The shared user sees it in "Shared with me" but doesn't get an email.

Overview

This skill builds and deploys safety-profiled gogcli binaries that remove commands at compile time so disabled operations cannot be invoked at runtime. It provides L1 (draft-only), L2 (collaborate), and L3 (standard write) profiles and tooling to build, verify, deploy, and roll back safe binaries. Use it when you need an agent-facing gog with restricted permissions and provable command removal.

How this skill works

The build scripts consume a YAML safety profile that marks individual commands true/false. The generator emits Go source for only enabled commands and compiles a binary tagged with a -safe version suffix so removed commands are not present in the final artifact. Deploy scripts back up the existing gog, install the new binary, and optionally run verification checks that blocked commands are absent and allowed commands work.

When to use it

Deploying gog for an AI agent with restricted permissions
Isolating drafting and inbox organization from send/write capabilities (L1)
Providing collaborative but non-sending access for assistants (L2)
Granting full write access while blocking dangerous admin ops (L3)
Setting up reproducible, auditable command removal for compliance or audit reviews

Best practices

Choose the least-permissive profile that still enables required workflows (principle of least privilege).
Verify the deployed binary shows the -safe suffix and run allow/block command checks immediately after deployment.
Keep custom YAML profiles in version control and document why each command is enabled or disabled.
Use the provided rollback command in automated deployment pipelines to ensure fast recovery.
Test edge cases such as filter forwarding and sharing behaviors before granting profiles to production agents.

Example use cases

Create an L1 binary for an assistant that drafts email and organizes inboxes but cannot send or forward messages.
Build an L2 binary for human-in-the-loop workflows where the agent can comment and collaborate but still cannot transmit messages.
Deploy an L3 binary for trusted automation that needs write access but must not perform dangerous admin operations.
Cross-compile an L1 binary for ARM64 hosts (e.g., Graviton instances) when deploying agent runtimes to cloud VMs.
Run verification after remote deployment to confirm blocked commands return help/failure and allowed commands function as expected.

FAQ

How do I customize which commands are removed?

Copy an existing YAML profile from references/, edit the true/false flags for specific commands, and pass that file to the build script.

Can blocked commands be re-enabled at runtime?

No. Commands disabled at compile time are not present in the binary, so runtime re-enablement is not possible.