gog-safety

• Outcome: Review
• Latest audit: Sep 11, 2026 · 6:15 AM UTC
• Version: 1.0.1

Overview

This skill has a coherent goal, but its restricted safety profiles and build process grant more sensitive authority than the safety framing suggests.

Install only after reviewing the build source and profiles. Pin the upstream repository to an audited commit, remove token export/import and keyring access from restricted profiles, disable forwarding-capable filters and L1 Drive sharing unless explicitly required, and require human confirmation for remote sudo deployment and rollback.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (4)

T03 · Remote Payload Retrieval and Execution

Error

• Location: scripts/build-gog-safe.sh:20
• Finding: Mutable Source from an Undeclared Fork Is Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Location**: `scripts/build-gog-safe.sh:20-21, 91-108` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash UPSTREAM_BRANCH="feat/safety-profiles" UPSTREAM_REPO="https://github.com/drewburchfield/gogcli-safe.git" ``` ```bash # Step 1: Clone or update the PR branch if [[ -d "$BUILD_DIR/.git" ]]; then echo "Updating existing checkout..." cd "$BUILD_DIR" git fetch origin "$UPSTREAM_BRANCH" 2>/dev/null || true git checkout "$UPSTREAM_BRANCH" 2>/dev/null git pull origin "$UPSTREAM_BRANCH" 2>/dev/null || true else echo "Cloning gogcli PR #366 branch..." rm -rf "$BUILD_DIR" git clone --branch "$UPSTREAM_BRANCH" --depth 1 "$UPSTREAM_REPO" "$BUILD_DIR" cd "$BUILD_DIR" fi # Step 2: Copy our profile into the build tree cp "$PROFILE" "$BUILD_DIR/safety-profile.yaml" echo "Copied profile to build tree." # Step 3: Generate command structs (must run on host platform) echo "Generating command structs from profile..." rm -f internal/cmd/*_cmd_gen.go CGO_ENABLED=0 go run ./cmd/gen-safety --strict safety-profile.yaml ``` ### Technical Analysis The build script retrieves a mutable Git branch from `drewburchfield/gogcli-safe` and immediately executes repository-controlled Go code through `go run ./cmd/gen-safety`. It then builds the rest of the retrieved repository into the binary intended for deployment. The repository and branch differ from the source described in `SKILL.md:54` and `references/levels.md:40,45-46`, which identify `steipete/gogcli` PR 366. The build does not pin an immutable commit, verify a signed tag, check a known source hash, or validate the generated source. Consequently, the effective payload can change after this skill package has been reviewed. Suppressing fetch and pull errors with `|| true` also weakens reproducibility: a failed update can silently leave an unknown or locally modified checkout in use. ### Attack Path 1. An ...[truncated 1334 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the undeclared fork with the reviewed and documented upstream repository. 2. Pin the source to a specific, audited commit hash rather than a mutable branch. 3. Verify the checked-out commit before executing or compiling any repository code: ```bash EXPECTED_COMMIT="<audited-full-commit-hash>" git checkout --detach "$EXPECTED_COMMIT" [[ "$(git rev-parse HEAD)" == "$EXPECTED_COMMIT" ]] || exit 1 ``` 4. Verify signed commits or tags against an explicitly trusted maintainer key. 5. Vendor the generator into the reviewed skill package where practical, or separately review and hash its complete dependency closure. 6. Run source generation and compilation in an isolated, unprivileged container or sandbox with no developer credentials and minimal network access. 7. Remove `|| true` from security-relevant Git operations and fail closed when retrieval, checkout, or verification fails. 8. Generate a software bill of materials and record the repository URL, exact commit, profile hash, Go version, and artifact checksum for every build. 9. Verify the final artifact through reproducible builds or an independent trusted build pipeline before deployment. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/l1-draft.yaml:229
• Finding: Restricted Safety Profiles Permit Token Export and Authentication Reconfiguration<![CDATA[ ## Vulnerability Details **File Location**: `references/l1-draft.yaml:229-252`; equivalent permissions appear in `references/l2-collaborate.yaml:236-259` and `references/l3-standard.yaml:236-259` **Vulnerability Type**: Excessive authentication and credential-management privileges **Risk Level**: High ### Vulnerable Code ```yaml auth: credentials: set: true list: true add: true # Login/auth setup services: true list: true alias: list: true set: true unset: true status: true keyring: true remove: true # Logout tokens: list: true delete: true export: true import: true manage: true service-account: set: true unset: true status: true ``` ### Technical Analysis The L1 profile is presented as a constrained profile for drafting and inbox organization, but it retains the ability to export and import tokens, delete tokens, modify credentials, manage authentication, and configure service accounts. L2 and L3 expose the same controls. Compile-time removal of direct messaging commands does not provide an effective security boundary if the restricted agent can export reusable authentication material. Exported credentials can be transferred to another program or an unrestricted `gog` binary that does contain the removed commands. Credential import and service-account configuration can also redirect operations to identities that were not intended for the agent. These capabilities exceed the operational requirements of routine drafting, search, labeling, and document organization. ### Attack Path 1. An agent is granted access to an L1 or L2 binary under the assumption that direct outbound commands are unavailable. 2. The agent invokes the enabled token-export functionality. 3. Reusable OAuth or related authentication material is written to an accessible location or returned through command output. 4. The material is copied to another client, host, or unrestric ...[truncated 1015 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable the following commands in every agent-facing restricted profile: - Token export, import, and deletion - Credential setting and management - Service-account setting and removal - Authentication alias mutation - Keyring management where it exposes or changes sensitive state 2. Separate initial authentication from routine agent operation. Use an administrator-only setup binary or manual provisioning workflow. 3. Store tokens in a protected operating-system keyring and ensure routine commands cannot reveal raw token values. 4. Issue dedicated credentials with only the minimum OAuth scopes required by each safety level. 5. Prefer separate service accounts or delegated identities per profile instead of sharing a full-user credential. 6. Add automated profile-policy tests that fail a build if credential export or authentication mutation is enabled in restricted profiles. 7. Log and alert on authentication configuration changes and token-management operations. 8. Revoke and rotate any tokens that may already have been exported through these profiles. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/l1-draft.yaml:39
• Finding: L1 and L2 Gmail Filter Permissions Enable Indirect Outbound Mail Disclosure<![CDATA[ ## Vulnerability Details **File Location**: `references/l1-draft.yaml:39-44`; `references/l2-collaborate.yaml:38-53`; risk acknowledged in `SKILL.md:73-76` **Vulnerability Type**: Safety-profile bypass through forwarding filters **Risk Level**: High ### Vulnerable Code ```yaml settings: false # Admin settings blocked (vacation, sendas, delegates, forwarding, autoforward, watch) watch: false autoforward: false delegates: false filters: true # Legacy alias — points to settings.filters forwarding: false ``` The equivalent L2 configuration explicitly enables both filter paths: ```yaml settings: filters: true # Inbox organization vacation: true # L2 — OOO/vacation allowed sendas: false # L3+ only delegates: false # L4 only forwarding: false # L4 only autoforward: false # L4 only watch: false # L4 only # Legacy aliases (hidden from help but still parsed) watch: false autoforward: false delegates: false filters: true forwarding: false sendas: false vacation: true ``` The project documentation confirms the side effect: ```markdown - **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. ``` ### Technical Analysis L1 and L2 disable direct email sending and dedicated forwarding controls, but they enable Gmail filter creation. The documentation explicitly states that a filter can include a forwarding action. This creates an alternate outbound channel that bypasses the intended command-level restriction. Blocking `gmail send`, `gmail settings forwarding`, and `gmail settings autoforward` does not prevent exfiltration if an enabled filter command can cause Gmail to forward matching messages automatically. The effect is persistent at the account level: once created, a rule can continue processing future messages without further execut ...[truncated 1268 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable Gmail filter creation and mutation in L1 and L2 unless the upstream command can enforce a safe action allowlist. 2. If inbox organization requires filters, validate every filter action and reject: - Forwarding actions - Redirect-like actions - Actions that invoke external integrations - Any future action not explicitly approved 3. Use a default-deny schema for filter actions rather than relying only on removal of top-level forwarding commands. 4. Remove or disable legacy aliases that expose the same filter functionality through alternate command paths. 5. Add negative integration tests that attempt to create forwarding filters through every canonical and legacy command path. 6. Periodically inspect accounts using restricted profiles for unauthorized forwarding filters and destinations. 7. Clearly distinguish persistent account-setting operations from ordinary inbox organization, and require explicit human approval for persistent rules. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/l1-draft.yaml:69
• Finding: L1 Drive Sharing Permissions Allow External Data Disclosure<![CDATA[ ## Vulnerability Details **File Location**: `references/l1-draft.yaml:69-84`; risk acknowledged in `SKILL.md:77` **Vulnerability Type**: Excessive sharing and permission-management privileges **Risk Level**: Medium ### Vulnerable Code ```yaml drive: ls: true search: true get: true download: true upload: true mkdir: true copy: true delete: true # Delete your own files move: true rename: true share: true # Grants access (no message sent) unshare: true # Remove access permissions: true url: true drives: true ``` The documentation acknowledges the access grant: ```markdown - **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. ``` ### Technical Analysis The L1 profile claims that nothing should be outbound, yet it permits Drive sharing and permission mutation. Granting a third party access to a file is a data-disclosure operation regardless of whether Google sends a notification email. An agent can locate sensitive content using the enabled search and listing commands and then use `drive share` or permission-management functionality to authorize another identity. The recipient can subsequently access the file through Google Drive or a direct URL. The enabled `unshare` and general permission controls may also allow the agent to remove legitimate access, resulting in an integrity or availability impact for shared content. ### Attack Path 1. An agent running under L1 searches Drive for sensitive documents. 2. It invokes `drive share` or the enabled permission-management command. 3. It grants read or stronger access to an attacker-controlled Google identity. 4. The attacker opens the item through Drive or its URL. 5. The attacker reads or copies the content without requiring the restricted agent to use an email or chat command. 6. Optionally, ...[truncated 695 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Disable `drive share`, `drive unshare`, and general permission mutation in L1. 2. Move sharing operations to a higher-trust profile and require explicit human confirmation. 3. If sharing is operationally required, enforce: - An approved-recipient allowlist - Organization-domain restrictions - Read-only roles by default - Prohibition of public or link-based sharing - File classification checks before access is granted 4. Separate read-only permission inspection from permission mutation rather than enabling both through a broad `permissions` capability. 5. Add audit logging and alerts for access grants, public-link creation, ownership changes, and permission removals. 6. Add tests demonstrating that L1 cannot grant any new principal access to Drive content. 7. Review and revoke unauthorized permissions previously created through restricted profiles. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (36)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The declared description says the skill builds and deploys safety-profiled gogcli binaries with compile-time command removal and supports choosing among restriction levels and building from PRs. The supplied code does not build anything, does not select or define profiles, and does not interact with PRs. Instead, it assumes a binary already exists locally and focuses narrowly on remote deployment and post-deployment verification. While deployment is part of the declared purpose, the primary behavior in this chunk is only a subset of that description and omits several key advertised capabilities. Therefore the description does not accurately represent what this code chunk actually does.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: Credential setup, token export/import, keyring access, and related auth-management capabilities are highly sensitive and should not be silently bundled into a low-risk profile. These operations can expose authentication material, alter identities, or let an agent reconfigure trust boundaries, making the profile far more dangerous than its 'safety' branding suggests.

Ssd 3

High

• Confidence: 98% confidence
• Finding: Allowing token export/import and credential listing creates a straightforward path for an LLM agent to retrieve, serialize, summarize, or otherwise leak sensitive authentication data through normal language outputs. In a skill intended for restricted-permission agent use, this is especially dangerous because it undermines account security and can enable downstream account compromise across connected services.

Credential Access

High

• Category: Privilege Escalation

Content

set: true
    unset: true
  status: true
  keyring: true
  remove: true               # Logout
  tokens:
    list: true

• Confidence: 96% confidence
• Finding: Enabling keyring access gives the agent a path to interact with stored credentials or authentication secrets, which is inconsistent with a restricted draft-oriented safety profile. In the context of an AI agent skill, credential-access functionality materially increases the risk of secret disclosure, account takeover, or privilege expansion if misused or prompted adversarially.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The L2 profile is described as a constrained 'Draft & Collaborate' tier, but it enables broad authentication and account-administration actions such as credential management, token export/import, keyring access, alias manipulation, and service-account configuration. These capabilities exceed collaboration needs and create a powerful privilege pivot: an agent operating under this profile could reconfigure identities, extract reusable secrets, or persist access beyond the intended workspace-scoped actions.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: Sensitive credential, token, and service-account management functions are enabled in the manifest without prominent warnings or justification, despite the profile being presented as a safety-profiled collaboration tier. In practice, this normalizes high-risk secret-handling operations and makes accidental or abusive use more likely, especially by autonomous agents and users who rely on the profile description as a trust signal.

Credential Access

High

• Category: Privilege Escalation

Content

set: true
    unset: true
  status: true
  keyring: true
  remove: true
  tokens:
    list: true

• Confidence: 95% confidence
• Finding: Enabling keyring access gives the profile direct interaction with locally stored secrets, which can expose credentials for this and potentially other services depending on implementation. In a supposedly constrained collaboration profile, this materially increases the blast radius from document-editing actions to credential discovery, extraction, or persistence operations.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: Allowing token export/import in a collaboration profile exposes portable credentials that can be exfiltrated, replayed on another host, or swapped to impersonate other principals. This is especially dangerous in an agent context because it turns a bounded application permission set into transferable account access.

Credential Access

High

• Category: Privilege Escalation

Content

set: true
    unset: true
  status: true
  keyring: true
  remove: true
  tokens:
    list: true

• Confidence: 93% confidence
• Finding: Enabling keyring and adjacent token-management capabilities grants access to stored credentials and authentication material, which is highly sensitive even in a legitimate auth-management section. In this skill's context, the danger is elevated because the profile is meant for an AI agent: if the agent is compromised, misprompted, or over-trusted, it could enumerate, export, delete, or otherwise manipulate credentials and expand access far beyond intended actions.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Step 3: Generate command structs (must run on host platform)
echo "Generating command structs from profile..."
rm -f internal/cmd/*_cmd_gen.go
CGO_ENABLED=0 go run ./cmd/gen-safety --strict safety-profile.yaml

# Step 4: Build with cross-compilation if requested

• Confidence: 95% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Chaining Abuse

High

• Category: Tool Misuse

Content

echo ""
echo "To deploy to a remote host:"
echo "  scp $OUTPUT <host>:/tmp/gog-safe"
echo "  ssh <host> 'sudo mv /usr/local/bin/gog /usr/local/bin/gog-backup && sudo mv /tmp/gog-safe /usr/local/bin/gog && sudo chmod +x /usr/local/bin/gog'"
echo "  ssh <host> 'gog --version'"

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

ssh "$HOST" '
  if [ -f /usr/local/bin/gog ]; then
    if [ -f /usr/local/bin/gog-backup ]; then
      sudo rm -f /usr/local/bin/gog-backup
    fi
    sudo mv /usr/local/bin/gog /usr/local/bin/gog-backup
  fi

• Confidence: 95% confidence
• Finding: The script unconditionally deletes /usr/local/bin/gog-backup before creating a new backup, which can destroy the last known-good binary and weaken rollback safety. Because the deletion is performed with sudo on the remote host, an operator can be left without a recoverable fallback if the new binary is bad or the deployment only partially succeeds.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill documents shell-based build, SSH deployment, backup, and verification actions but does not declare an explicit tool scope such as permissions or allowed-tools. In an agent setting, that omission can cause the skill to be invoked with broader shell access than reviewers or orchestrators expect, increasing the chance of unintended command execution on local or remote systems.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The skill claims L1/L2 cannot send email or chat, yet later acknowledges an allowed filter-creation command can auto-forward email. That undermines the stated safety boundary and could permit covert exfiltration or unauthorized outbound communication despite the profile being presented as non-sending.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The documentation instructs users to replace a system binary on a remote host via SSH, including backup and install behavior, without a prominent warning that it modifies executable state on the target machine. In agent-driven contexts, this can lead to unreviewed production changes or deployment to the wrong host, especially because the action targets `/usr/local/bin`.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

### 4. Rollback

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

## How It Works

• Confidence: 82% confidence
• Finding: The rollback command uses sudo to move binaries in a privileged system path, which normalizes root-level modification in an agent skill workflow. If executed on the wrong host or with a tampered backup file, this could restore or install an unintended executable with elevated trust implications.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The profile claims 'Nothing outbound' and frames actions that notify or affect other humans as blocked, yet it enables capabilities like Drive sharing/unsharing and Calendar ACL management that can change other users' access and visibility. This mismatch can cause an agent or operator to overtrust the profile and perform externally impactful actions under a supposedly safe L1 mode.

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The activation philosophy is extremely broad and effectively authorizes almost any action that is not classified as outbound, without clear user-confirmation triggers or tighter task boundaries. In an agent setting, such vague permissioning increases the chance of high-impact but technically 'allowed' actions like deletion, permission changes, or large-scale modifications being taken from ambiguous natural-language requests.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The manifest enables destructive and access-changing Drive actions such as delete, share, unshare, and permissions without prominent warning at the point where the profile is described as safe. In practice, this can mislead users into granting or using a profile that can remove data or alter who can access it, contrary to the expected risk level of a draft-only configuration.

Ssd 3

Medium

• Confidence: 93% confidence
• Finding: Drive sharing directly affects other users by granting access to content, which contradicts the profile's stated 'nothing outbound' safety model. Even if no notification is sent, the action changes external visibility and can expose sensitive data to unintended recipients.

Intent-Code Divergence

Medium

• Confidence: 84% confidence
• Finding: The profile text says there should be no direct messaging, yet Gmail capabilities include draft creation, update, deletion, label/filter changes, and vacation settings changes. While send is disabled, these broader mail and settings mutations still allow meaningful account and communication-state changes that contradict the stated safety boundary and may enable social-engineering prep, inbox manipulation, or indirect communication workflows.

Context-Inappropriate Capability

Medium

• Confidence: 88% confidence
• Finding: Enabling appscript.run gives the agent indirect execution capability that can trigger arbitrary logic, side effects, or data movement outside the narrowly described 'draft and collaborate' scope. Even if direct messaging is blocked elsewhere, script execution can become a bypass path for automation that performs actions the profile otherwise tries to prohibit.

Vague Triggers

Medium

• Confidence: 84% confidence
• Finding: Broad aliases and generic capability names such as open, upload, login, auth.manage, and similar toggles are enabled without embedded constraints describing prohibited targets, contexts, or side effects. In an agent-facing safety manifest, ambiguity is dangerous because it increases the chance that tooling or downstream policy interprets these switches more broadly than the human-readable profile intent.

Natural-Language Policy Violations

Medium

• Confidence: 84% confidence
• Finding: The profile framing presents a full-write operational posture as the standard L3 capability set without documenting explicit user opt-in, escalation criteria, or decision points for choosing safer profiles. In the context of an AI-agent safety skill, this can normalize excessive permissions and increase the chance that agents are deployed with unnecessary authority.

Vague Triggers

Medium

• Confidence: 88% confidence
• Finding: The file defines an L3 profile with broad write and messaging authority, but the introductory policy text does not state any activation guardrails, approval requirements, or situational limits for using these high-impact capabilities. In an agent skill intended for restricted-permission deployment, missing usage constraints can lead to unsafe default enablement and over-privileged operation even if the manifest is technically valid.

Static analysis

No suspicious patterns detected.