Agent Audit Log

Lightweight operational audit logging for AI assistants, agent workspaces, and personal automation systems. Use when you need a structured way to record high...

Security Scan

The skill is internally consistent: it provides local, lightweight audit logging, includes a safe initialization script, requests no credentials, and contains no unexpected network or privileged operations.

Purpose & Capability

Name/description (lightweight audit log) match the files and runtime instructions. All referenced files (schema, examples, risk model) are present and relevant; nothing in the manifest suggests unrelated capabilities or external services are required.

Instruction Scope

SKILL.md stays on-topic: it instructs how to structure logs, which local reference files to read, and to use the included init script. It explicitly warns not to store plaintext secrets. It does not instruct reading unrelated system files, environment variables, or sending data to external endpoints.

Install Mechanism

There is no install spec (instruction-only) and a single small bash script that only creates local directories/files. No downloads, package installs, or archive extraction are present.

Credentials

The skill requests no environment variables, no credentials, and no config paths. The schema includes event kinds such as 'config_secret_injection' but the documentation explicitly advises not to store plaintext secrets; this is a legitimate logging schema choice rather than credential access.

Persistence & Privilege

The skill is not forced always-on (always:false) and does not request elevated or cross-skill configuration changes. Its only persistence is creating local audit files in a logs/audit directory under a provided root — standard and scoped behavior.

Assessment

This skill appears safe and does what it claims: initializes a local audit directory and provides a schema and examples. Before use: (1) run scripts/init_audit.sh in a test directory to verify behavior; (2) ensure the audit directory is stored with appropriate file permissions and retention policies (logs can be sensitive); (3) never log plaintext secrets — follow the README guidance and redact or reference secrets rather than storing them; (4) be aware that other skills or workflows could later read or transmit these logs, so control which agents or services have access to the logs. If you need remote centralized logging, implement secure, explicit export steps rather than relying on this skill alone.

Create and maintain a lightweight audit trail for high-value actions.

Core rule

Log only actions that matter for safety, traceability, or later review. Do not turn the audit log into noise.

Default layers

1. Raw fact log (YYYY-MM-DD.jsonl)
2. Date summary (index.json)
3. Target/project index (by-target.json)
4. Risk index (by-risk.json)
5. Human-readable summary (latest.md)
6. Export-safety events (export_safety_check)
7. Open items (open-items.json)
8. Status transition history (open-items-history.json)

Read references as needed

• Read references/schema.md for the log schema and event fields.
• Read references/risk-model.md for how to classify low / medium / high risk.
• Read references/export-safety.md before logging publish/export actions.
• Read references/open-items.md when tracking unresolved risks or follow-up work.
• Read references/examples.md when you need concrete event, export-safety, or open-item examples.

Use scripts as needed

• Use scripts/init_audit.sh to create the basic audit directory and starter files.

Operating rules

• Do not store plaintext secrets in audit logs.
• Prefer concise, human-readable summaries.
• Record target, result, and non-sensitive references.
• Use warn when something needs attention but did not fail.
• Use open items for follow-up risk, not for routine noise.