gog Safety Profiles

intent

Build and deploy gog binaries with compile-time command removal for restricted AI agent execution. Choose from three safety levels (L1 draft-only, L2 collaborative, L3 standard write) to lock down which commands exist in the binary itself. Use this skill when you need hard permission boundaries that can't be bypassed at runtime because the commands literally aren't compiled in.

inputs

External Dependencies

• Go 1.22 or later
• git
• SSH access to target deployment hosts
• sudo privileges on target hosts (for binary installation in /usr/local/bin)

Repository & Build Artifacts

• steipete/gogcli repository with PR #366 branch (auto-cloned on first run)
• Build scripts: ./scripts/build-gog-safe.sh and ./scripts/deploy-gog-safe.sh
• Safety profile YAML files in references/:
  • l1-draft.yaml (draft and organize only)
  • l2-collaborate.yaml (draft, organize, and collaborative ops)
  • l3-standard.yaml (full write except admin operations)

Environment Setup

• SSH key or password auth configured for target hosts
• Write access to build output directory (default: /tmp/gogcli-safety-build/bin)
• Write access to backup location on target host (backup written as gog-backup)

procedure

1. Select a safety level based on agent use case:

   • L1: email triage, drafting, inbox organization. no external comms.
   • L2: L1 capabilities plus commenting, RSVP, collaborative work. no external comms.
   • L3: full write access including email/chat send, no dangerous admin ops.

2. Build the safety-profiled binary by running:

   ./scripts/build-gog-safe.sh <LEVEL> [--arch <ARCH>] [--os <OS>] [--output <PATH>]
   

   Input: safety level (L1, L2, or L3), optional target architecture (arm64, amd64, etc.), optional target OS (linux, darwin, etc.), optional output directory. Output: compiled binary at <output-dir>/gog-<LEVEL>-safe (default output: /tmp/gogcli-safety-build/bin/gog-<LEVEL>-safe). Binary tagged with -safe suffix in version output. Note: First run clones the gogcli repo, takes approx 30 seconds.

3. Verify the local build by running version check and spot-testing a blocked command:

   /tmp/gogcli-safety-build/bin/gog-l1-safe --version
   /tmp/gogcli-safety-build/bin/gog-l1-safe gmail send --help 2>&1
   

   Input: path to built binary. Output: version string should contain -safe; blocked commands should error with "command not found" or similar.

4. Deploy to remote host by running:

   ./scripts/deploy-gog-safe.sh <HOST> <BINARY-PATH> [--verify]
   

   Input: target hostname or IP, full path to built binary, optional --verify flag. Output: binary installed to /usr/local/bin/gog on target host; prior binary backed up as /usr/local/bin/gog-backup.

5. Verify remote deployment (if --verify flag used during deploy, this is automatic; if not, run manually):

   ssh <HOST> "gog --version"
   ssh <HOST> "gog gmail send --help 2>&1"
   ssh <HOST> "gog gmail drafts create --help"
   

   Input: target hostname. Output: version shows -safe suffix; blocked commands fail; allowed commands show help text.

6. Rollback if needed by reversing the backup:

   ssh <HOST> 'sudo mv /usr/local/bin/gog-backup /usr/local/bin/gog'
   

   Input: target hostname. Output: prior gog binary restored.

decision points

• If using a custom safety profile: copy any YAML profile from references/, edit the true/false flags to enable or disable specific commands, then pass the custom file path to the build script via --profile <PATH>. The build system reads the YAML and compiles only enabled commands into the binary.

• If the build script cannot clone the gogcli repo (network timeout or auth error): manually clone git clone --branch feature/safety-profiles https://github.com/steipete/gogcli.git to a local directory and point the build script to it using --repo-path <PATH>. The script will use the existing clone instead of fetching.

• If deployment to a remote host fails with SSH timeout or connection refused: verify SSH connectivity to the host first (ssh <HOST> echo ok), confirm SSH key is loaded in the agent, and check that the target hostname is correct. Re-run the deploy script once connectivity is confirmed.

• If the deploy script fails with "Permission denied" when writing to /usr/local/bin: confirm that the SSH user has sudo privileges without password prompt, or run the deploy with explicit sudo wrapping (requires passwordless sudo configured on the target host).

• If a blocked command still executes on the target after deployment (runtime bypass suspected): this indicates the binary was not built with the safety profile applied. Verify the binary file matches the expected output from step 2 and re-run deployment with the --verify flag to test blocked commands.

• If the result set is empty (no commands enabled at the chosen level): this is a misconfiguration of the YAML profile. Verify the profile YAML has at least one command set to true and rebuild.

output contract

Build Output

• Single executable file at <output-dir>/gog-<LEVEL>-safe (e.g., /tmp/gogcli-safety-build/bin/gog-l1-safe)
• File is statically linked, portable across hosts with the same OS and CPU architecture
• Running gog-l1-safe --version outputs a version string containing the substring -safe

Deployment Output

• Binary installed to /usr/local/bin/gog on target host, owned by root, executable by all users
• Prior binary backed up as /usr/local/bin/gog-backup (same directory)
• No configuration files or env vars required; safety level is baked into the binary

Verification Output (if --verify flag used)

• Stdout lists blocked commands tested and confirms they are not found in the binary
• Stdout lists allowed commands tested and confirms they execute without error
• Exit code 0 if all tests pass; nonzero if any test fails

outcome signal

The skill worked when:

• gog --version (run on the target host after deployment) outputs a version string that includes -safe
• Running a blocked command for your chosen safety level (e.g., gog gmail send --help on L1) returns a "command not found" error, not a help message
• Running an allowed command for your chosen safety level (e.g., gog gmail drafts create --help on L1) returns the expected help text without error
• The backup gog-backup exists on the target host and can be restored if needed

Known limitations: filter forwarding at L1+ can forward email if a filter with forward action is created (accepted risk). Drive sharing at L1+ grants read access without email notification to the shared user (accepted risk).