Audit logging
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill audit-loggingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Record security-relevant events in a tamper-evident, append-only log that answers who did what and when. Use when building or reviewing logging for authentication, authorization, privilege changes, or access to sensitive data.
SKILL.md
2.9 KB, as published. Nobody here has run it
Audit logging
An audit log is the record you reach for after the fact: a breach, a dispute, an auditor asking who touched an account. It fails two ways, by never capturing the event or by letting the attacker edit it on the way out. A method has to close both, so the log is complete and any change to it announces itself.
Method
- Capture the full sentence per event: actor (user id plus how they authenticated), action, target resource, timestamp in UTC ISO 8601, source (IP and request id), and outcome. On a denial, add the reason. A record missing the actor or the outcome cannot answer the question you will ask.
- Split the audit stream from application logs. Send it to a dedicated append-only sink: an S3 bucket with Object Lock (WORM), AWS CloudTrail, or a write-only topic. Operational logs rotate and get pruned for cost, and audit records must never share that fate.
- Chain entries by hash so edits show. Each record stores the SHA-256 of the previous record concatenated with its own payload, so deleting or altering one entry breaks every link after it. Re-verify the chain on a schedule and alert the instant a link fails to match.
- Give the writer INSERT and nothing else. The account that appends audit rows holds no UPDATE or DELETE grant. Retention and expiry run as a separate job under separate credentials, so the path that writes cannot also rewrite.
- Log the events that carry weight: authentication success and failure, authorization denials, role and privilege changes, secret access, configuration changes, and data export. Leave out high-volume routine reads unless the resource read is itself sensitive.
- Keep the secret out of the record. Log that a password changed, not the new password; that a token was read, not its bytes. Mask personal data down to what an investigator genuinely needs to see.
- Make timestamps trustworthy. Run NTP on every host, store UTC, and record both event time and ingest time so a backdated or delayed entry stands apart instead of blending in.
Checks
- Can you answer "who deleted this record, and when" from the audit log alone, with no help from the application database?
- Does altering a single past entry get caught within one verification cycle?
- Is the sink genuinely append-only, writable but not deletable by the runtime role the application actually uses?
Boundaries
Audit logging proves what happened; it neither prevents the action nor serves as your general operational log, which structured-logging covers. Retention periods and mandated formats (SOX, HIPAA, PCI DSS) come from compliance and legal, not from this skill.