Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed wrapper for managing a ggb.ai agent identity, with some documentation inconsistencies around self-disable but no hidden code or exfiltration behavior found.
Install only if you intend to let the agent manage its ggb.ai Pre-Market identity and API-key lifecycle. Keep the API key in a secret store, review profile and payout updates before sending them, and require explicit human confirmation before rotate-key or disable because those change account access state.
The README advertises a self-disable capability even though the skill metadata says the skill provides only four operations: read, patch, rotate-key, and ping. This documentation/manifest mismatch expands the apparent action surface and can cause an agent or orchestrator to invoke an undeclared destructive action, undermining policy review and user expectations.
The mode list explicitly includes a 'disable' operation that is not declared in the skill metadata. Undeclared operational modes are dangerous because they can bypass governance, auditing assumptions, and least-privilege checks that depend on the published interface being complete.
The endpoint table exposes POST /disable despite the manifest describing only four endpoints. When the documented interface is broader than the declared interface, security tooling and human reviewers may under-scope risk, and an LLM agent may still attempt a destructive call based on README guidance alone.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -sX PATCH https://ggb.ai/api/premarket/agent-identity/me \
-H "X-Agent-API-Key: $GGB_AGENT_API_KEY" \
-H 'content-type: application/json' \
-d '{
The manifest description at L003 explicitly scopes the skill to four operations: GET /me, PATCH /me, POST /rotate-key, and POST /ping. However, the body documentation repeatedly documents a fifth supported mode, POST /disable, as part of the skill's functionality, which expands the behavior beyond the manifest's declared scope.
The skill text states authentication enforces status === 'active' before all operations, but later says a revoked key can still authenticate reads. That contradiction is security-relevant because wrapper authors may incorrectly assume revoked or inactive credentials retain limited read access, or conversely mishandle failure paths, leading to improper authorization logic, broken revocation assumptions, or accidental data exposure if an implementation follows the weaker interpretation.
The disable operation is described as terminal self-revoke, but the documentation does not present a strong, explicit irreversible-action warning at the point of use. For a credentialed identity-management skill that can permanently block future writes and publishing, weak warning language increases the risk of accidental destructive actions by agents or operators, creating an availability and account-recovery problem.
The section labels 'status' as read-only, but immediately carves out an exception 'except /disable self-revoke'. That creates contradictory intent documentation: status is not fully read-only if the skill supports an endpoint that changes it.
The audit section further confirms that 'disable' is a write operation tracked by the system, reinforcing that an undeclared capability exists beyond the stated skill scope. This deepens the mismatch and increases confidence that consumers may be misled about the true set of privileged actions.
The natural-language documentation restricts payout address handling to the "bnb" chain only and states other chains will come later, which imposes a specific ecosystem/locale constraint. Because the file does not offer user opt-in or explain a compliance or region-specific justification, this can be a language/locale-style policy constraint under the stated rule.