AuditClaw GRC
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If cloud integrations are invoked, the agent may access cloud or identity-provider accounts using credentials already present on the machine, which may surprise users expecting only a local GRC database.
The integration layer can use existing local/cloud credential chains and tokens. That is purpose-aligned for cloud evidence collection, but it is high-impact account access and is not fully surfaced by the registry metadata that declares no primary credential or env vars.
Default boto3 Session (env vars, ~/.aws/credentials, instance profile) ... Fallback: GITHUB_TOKEN env var ... DefaultAzureCredential (env vars, managed identity, CLI) ... google.auth.default()
Require explicit user opt-in per provider, document exact credential sources and scopes, declare optional credentials in registry metadata, and prefer least-privilege provider roles over default credential-chain fallbacks.
Users may underestimate the credential risk if they rely on the README's stronger authentication claims.
This README wording overstates the credential model: the provided auth_provider.py also supports stored AWS access keys, personal GitHub tokens/GITHUB_TOKEN, Azure client secrets, and service-account key files.
AWS: IAM Roles with AssumeRole (no static access keys) ... GitHub: GitHub App tokens (no personal access tokens) ... Azure: Certificate-based service principals (no client secrets) ... GCP: Service account impersonation (no key files)
Update the README and SKILL.md to accurately describe all supported credential modes, clearly label legacy/static-token fallbacks, and recommend least-privilege setup.
Incorrect or unintended agent actions could change local compliance records and reports.
The skill exposes commands that mutate the local compliance database. This is central to the stated GRC purpose, but audit and compliance records are business-sensitive.
`update-control --id 5 --status complete` ... `add-evidence` ... `add-risk` ... `add-vendor` ... `add-incident`
Confirm user intent before batch updates, incident/risk changes, evidence exports, or access-review decisions.
Setup runs local Python code and creates/updates files under the user's OpenClaw directory.
SKILL.md documents local setup commands that install a pinned Python dependency and initialize the database. This is purpose-aligned, but it differs from the registry statement that there is no install spec.
"install":{"pip":"scripts/requirements.txt","post":"python3 scripts/init_db.py"} ... `pip install -r {baseDir}/scripts/requirements.txt`Keep install metadata consistent with SKILL.md, and review scripts/requirements.txt and init_db.py before first use.
Compliance evidence and secrets could be exposed if the local account, backups, or filesystem are compromised.
The skill persistently stores compliance records, evidence metadata, and integration credentials locally. The storage location and permissions are disclosed, but the retained data can be sensitive.
Database: SQLite at `~/.openclaw/grc/compliance.sqlite` ... Credentials: Stored in `~/.openclaw/grc/credentials/` ... owner-only permissions
Protect the local profile, use disk encryption where appropriate, review retention/backup handling, and remove stored credentials when integrations are no longer needed.