T05 · Unauthorized Access and Privilege Escalation
- Location
scripts/gcp-roles.json:14- Finding
Excessive Project-Wide IAM Permissions Violate Least Privilege
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill appears to perform legitimate GCP compliance collection, but it asks users to grant broad project-wide read access and create a long-lived cloud key without enough scoping or credential-safety guidance.
Install only if you are comfortable granting this skill broad read visibility into the target GCP project and storing compliance evidence locally. Prefer keyless authentication or a tightly scoped custom role where possible; if you use a service account JSON key, keep it outside repositories, restrict file permissions, rotate it, and revoke it when no longer needed. Treat the local GRC database as sensitive compliance data.
scripts/gcp-roles.json:14Excessive Project-Wide IAM Permissions Violate Least Privilege
scripts/gcp_evidence.py:228Connection Test Reports Unexpected API Failures as Successful Access
The declared purpose emphasizes 'read-only checks,' but the skill also writes evidence and integration status into a local SQLite database and exposes a test-connection mode, while the documented check count/category mapping is inconsistent. This mismatch is dangerous because users and orchestrators may grant trust or permissions based on an incomplete description, leading to unexpected state changes, overbroad execution, or incorrect risk assumptions about what the skill actually does.
The markdown states that the skill runs checks against a GCP project and stores evidence in a shared database, which can affect user or organizational data handling. The description does not include any warning about what data is collected, persisted, or the implications of writing compliance evidence to shared storage.
The skill advertises executable behavior and explicitly depends on environment variables and shell-invoked setup/usage commands, but it does not declare an explicit tool scope such as allowed-tools or permissions. That creates an authorization and transparency gap: an agent or reviewer cannot easily constrain or reason about what external capabilities the skill may exercise, increasing the chance of unintended command execution or environment access.
The setup guide instructs users to create a long-lived service account JSON key and place it on disk, but it provides no warning about secret sensitivity, storage protections, rotation, or safer alternatives. Service account keys are highly valuable credentials; if leaked through logs, backups, shell history, shared filesystems, or misconfigured file permissions, an attacker could gain ongoing read access to the GCP project and potentially pivot further depending on granted roles.
The manifest describes the skill as performing '12 read-only checks' across GCP services, which suggests observational behavior. However, this script not only runs checks but also inserts evidence records and updates integration status in a SQLite database, making persistent state changes outside the read-only checking scope described in the manifest.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
"--file-content", json.dumps(result, default=str),
]
proc = subprocess.run(cmd, capture_output=True, text=True)
if proc.returncode != 0:
return _store_evidence_direct(db_path, check_name, result)
The function retrieves application default credentials and immediately uses them to call the Cloud SQL Admin API. While this is consistent with the check's purpose, the file contains no user-facing print/log statement or explicit warning that it will use ambient GCP credentials and contact Google APIs.
This code instantiates a GCP KMS client and enumerates key rings across the project, which is a network/API operation that transmits project context to an external cloud service. While the function has an internal docstring, there is no user-facing prompt, logging, or warning indicating that cloud KMS inventory data will be queried.
This JSON manifest includes actionable setup commands for creating a service account, granting roles, and generating a key, but it does not describe when these commands should or should not be invoked. In a manifest-scoped file, the lack of trigger scope or negative examples can make activation or use conditions ambiguous for automation that consumes the manifest.
The connection test treats many unexpected exceptions as successful access, which can produce false 'ok' results even when APIs are unreachable, misconfigured, or failing for non-permission reasons. This can mislead operators into trusting broken monitoring or evidence collection, reducing visibility and potentially causing missed compliance or security issues.
Dynamic getattr() with a non-literal attribute name can access arbitrary object attributes, potentially bypassing access controls.
for service_name, module_path, class_name, method_name, kwargs in optional_probes:
try:
mod = importlib.import_module(module_path)
client_class = getattr(mod, class_name)
if method_name:
client = client_class()
method = getattr(client, method_name)
Dynamic getattr() with a non-literal attribute name can access arbitrary object attributes, potentially bypassing access controls.
client_class = getattr(mod, class_name)
if method_name:
client = client_class()
method = getattr(client, method_name)
list(method(**kwargs))
else:
client_class(project=project_id)
No suspicious patterns detected.