TapAuth

• Outcome: Review
• Latest audit: Jun 23, 2026 · 9:54 PM UTC
• Version: 1.0.6

Overview

TapAuth is a disclosed credential-brokering skill, but users should treat its OAuth grants, manual secrets, and local grant cache as sensitive.

Install only if you are comfortable letting TapAuth broker access to the accounts and secrets you choose. Approve the minimum scopes needed, avoid broad scopes like GitHub repo, Vercel full integration access, or Apify full_api_access unless required, keep TAPAUTH_HOME in a private directory, and revoke or delete cached grants when access is no longer needed.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (15)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill clearly instructs the agent to execute shell commands and edit configuration, yet it declares no corresponding permissions. This creates a trust and review gap: downstream systems or users may approve the skill under the false assumption that it is non-executing, while it can invoke local scripts and trigger secret-resolution flows that fetch sensitive credentials.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The documented behavior minimizes risk by claiming tokens are not used directly at runtime, but the skill's broader behavior includes network interaction with a third-party service, local persistence of grant metadata, and a CLI mode that emits raw tokens to stdout. That mismatch is dangerous because operators may deploy the skill with an inaccurate mental model, underestimating exposure of secrets to logs, subprocesses, local disk, and an external service.

Missing User Warnings

Medium

• Confidence: 86% confidence
• Finding: The README explicitly promotes obtaining OAuth tokens and user-entered secrets for agent use, but it does not clearly warn that these credentials may grant broad account access and can be mishandled, logged, reused, or sent to downstream tools by the agent. In a skill whose core purpose is credential brokering, missing safety guidance increases the chance that users approve high-risk scopes or secrets without understanding the exposure.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The documentation instructs users to obtain and use an Apify token with the only available `full_api_access` scope, then immediately demonstrates running a remote actor. Because this scope grants broad control over actors, runs, datasets, stores, and schedules, the example normalizes high-privilege usage without warning about cost, data access, or state-changing effects, increasing the chance of over-privileged and unsafe use.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The documentation states that an Asana token grants access to all workspaces the user belongs to, but it does not warn operators or downstream agent authors about the risk of unintended cross-workspace data access. In this skill context, that omission matters because the provider is designed to supply tokens to agents automatically, increasing the chance that a token intended for one workspace is reused against another accessible workspace and causes over-collection or disclosure of data.

Missing User Warnings

Medium

• Confidence: 86% confidence
• Finding: The examples show how to obtain and use GitHub OAuth tokens with broad scopes such as `repo`, and the document also lists highly destructive scopes like `delete_repo`, but the example section does not prominently warn that these are user-acting tokens with potentially full repository impact. In an agent/integration context, this can normalize over-privileged token requests and lead users to grant excessive access that could be abused by downstream tools, prompts, or compromised agents.

Missing User Warnings

Medium

• Confidence: 86% confidence
• Finding: The documentation includes mutation examples that create issues and comments in a real Linear workspace, but it does not clearly warn that these examples are state-changing. In an agent/tooling context, users may copy or automate these commands assuming they are harmless examples, which can lead to unintended modifications, spam, or data integrity issues in production workspaces.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The documentation states that the grant ID and grant secret are saved locally in the script cache directory, but it does not prominently warn users that these are persistent credentials that require filesystem protection. Because these cached grant secrets can be reused to obtain fresh access tokens, local disclosure or weak permissions on the cache directory could lead to ongoing unauthorized access.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation explicitly states that the Vercel token carries the integration's full permissions, including access to environment variables, but it does not prominently warn that environment variables commonly contain secrets, API keys, and production configuration. In a token-provider skill, this omission increases the risk that users or downstream agents will treat the token as routine read access and unintentionally expose or overuse high-sensitivity credentials.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The example shows how to retrieve project environment variables without warning that the response may include sensitive secrets or confidential deployment configuration. Because this is actionable copy-paste documentation for an agent credential skill, the missing warning materially increases the chance of secret disclosure through casual inspection, logging, or reuse in subsequent tool calls.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The script decodes and prints the retrieved secret/token directly to stdout, which can easily leak into terminal scrollback, logs, calling process captures, CI output, or other observability tooling. In a credential-provider skill, this is especially sensitive because the whole purpose is to handle bearer tokens and user-supplied secrets, so accidental disclosure is a realistic risk.

External Transmission

Medium

• Category: Data Exfiltration

Content

scripts/tapauth.sh apify full_api_access

# 2. Run a web scraper actor
curl -X POST \
  -H "Authorization: Bearer $(scripts/tapauth.sh --token apify full_api_access)" \
  -H "Content-Type: application/json" \
  -d '{"startUrls": [{"url": "https://example.com"}]}' \

• Confidence: 84% confidence
• Finding: curl -X POST \ -H "Authorization: Bearer $(scripts/tapauth.sh --token apify full_api_access)" \ -H "Content-Type: application/json" \ -d

Credential Access

High

• Category: Privilege Escalation

Content

sorted_scopes=$(echo "$scopes" | tr "," "\n" | sort | tr "\n" "," | sed "s/,$//")
  safe_scopes=$(echo "$sorted_scopes" | tr '/:' '__')
fi
env_file="${TAPAUTH_DIR}/${provider}-${safe_scopes}.env"

TAPAUTH_GRANT_ID="" TAPAUTH_GRANT_SECRET="" TAPAUTH_EXPIRES="" TAPAUTH_APPROVE_URL="" TAPAUTH_STATUS="" TAPAUTH_TOKEN_B64=""
[ -f "$env_file" ] && parse_env_response "$(cat "$env_file")"

• Confidence: 95% confidence
• Finding: .env"

Session Persistence

Medium

• Category: Rogue Agent

Content

Follow these steps **in order**. Do not skip to step 3. Do not run `--token` yourself.

### 1. Create a grant and show the approval URL

Run the script **without `--token`** to create a grant. Set `TAPAUTH_HOME` so the grant cache is stored in a stable location that the exec provider can also find:

• Confidence: 81% confidence
• Finding: Create a grant and show the approval URL Run the script **without `--token`** to create a grant. Set `TAPAUTH_HOME` so the grant cache is stored in a stable location that the exec provider can also f

Session Persistence

Medium

• Category: Rogue Agent

Content

## How It Works

1. **One-time setup:** Run `tapauth.sh <provider> <scopes>` to create a grant and show the approval URL. The grant ID + grant secret are saved immediately in the script cache directory.
2. **Configure OpenClaw immediately:** Add one exec provider per grant with `jsonOnly: false`. Do not wait for the user to say "done." OpenClaw must use the same cache directory you used during setup, so forward `TAPAUTH_HOME` or `CLAUDE_PLUGIN_DATA` into the exec provider environment. OpenClaw then runs `tapauth.sh --token <provider> <scopes>` and waits while the user approves.
3. **Runtime:** OpenClaw resolves tokens at startup into an in-memory snapshot. `tapauth.sh --token` uses the cached grant to fetch a fresh token from the TapAuth API when OpenClaw starts.

• Confidence: 93% confidence
• Finding: create a grant and show the approval URL. The grant ID + grant secret are saved immediately in the script cache directory. 2. **Configure OpenClaw immediately:** Add one exec provider per grant with `

VirusTotal

60/60 vendors flagged this skill as clean.

Static analysis

Detected: suspicious.secret_argv_exposure

Instructions pass high-value credentials through process argv.

Critical

• Code: suspicious.secret_argv_exposure
• Location: SKILL.md:103