T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:101
- Finding
- Persistent Plaintext Logging of Participant PII## Vulnerability Details **File Location**: `SKILL.md`, lines 101–105 **Vulnerability Type**: Persistent storage of sensitive personal data in plaintext logs **Risk Level**: Medium ```markdown ## Record Modification (Requires Austin Approval) When Austin instructs a record change (e.g., marking someone unsubscribed, updating last_contact): 1. Confirm the specific change with Austin before executing 2. Execute the PATCH request 3. Log the change in memory/logs/crm-writes/YYYY-MM-DD.md with: record name/email, field changed, old value, new value, Austin's instruction timestamp ``` ### Technical Analysis The Skill requires every approved record modification to be logged in a persistent Markdown file. The required log entry includes the participant's name or email address and the old and new field values. These values may contain sensitive information, including subscription, attendance, contact, or donation status. This duplicates personal data outside Airtable and its associated access controls. The instruction does not establish file permissions, encryption, redaction, access restrictions, retention limits, or secure deletion procedures. It therefore increases the number of locations where participant data is retained and broadens the potential exposure surface. The detailed identity and field values are not necessary for a minimal operational audit trail. An Airtable record identifier, field name, operation result, authorization reference, and timestamp would normally provide traceability without duplicating direct identifiers and sensitive values. ### Attack Path 1. An authorized user requests a participant record modification. 2. The Skill reads the participant's existing record and processes the requested update. 3. After issuing the Airtable PATCH request, the Skill writes the participant's name or email address and old and new field values to `memory/logs/crm-writes/YYYY-MM-DD.md`. 4. The plaintext log persists ...[truncated 1027 chars]
- Remediation
- ## Remediation Suggestions 1. Replace participant names and email addresses with the Airtable record ID or a non-reversible internal audit identifier. 2. Do not record old or new values unless they are strictly required for a documented compliance purpose. Prefer recording only the field name, operation type, result, timestamp, and approval reference. 3. Redact or classify sensitive fields such as email, phone number, donation status, attendance, and subscription status before logging. 4. Store audit records in a dedicated access-controlled location rather than general-purpose agent memory. 5. Apply restrictive file permissions so only the service identity responsible for auditing can read or write the logs. 6. Encrypt audit records at rest where detailed values must be retained. 7. Define a retention period and automatically delete expired records through a documented secure-deletion process. 8. Prevent logs from being included in source control, broad workspace synchronization, or unrelated backups. 9. Add an explicit rule prohibiting authentication credentials, API responses, phone numbers, and full record contents from being written to audit logs. 10. Document who may access the audit trail and periodically review that access.