POST_START

Investigating Unexpected Production Volume Write Access

Today, I was tasked with investigating an unexpected production volume write access issue. A team member reported that some data in the production.files.documents volume was being written to without proper authorization. My goal was to determine who had access and whether any unauthorized writes had occurred.

Checking Volume Access Permissions

I started by checking the access permissions for the production.files.documents volume. I ran the following SQL command:

SHOW GRANTS ON VOLUME production.files.documents;

I saw a representative result like this:

<

principal	actionType	objectType
data_engineers	READ VOLUME	VOLUME
data_engineers	WRITE VOLUME	VOLUME

From this output, I learned that the data_engineers group had both READ VOLUME and WRITE VOLUME permissions. This was concerning because the volume was meant to be read-only for production data, and I needed to verify if any unauthorized writes were actually happening.

Reviewing Access Audit Logs

To dig deeper, I decided to review the access audit logs for any activity related to the production.files.documents volume. I ran the following SQL command:

SELECT * FROM system.access.audit WHERE request_params LIKE '%/Volumes/production/files/documents/%' ORDER BY event_time DESC;

I saw a representative result like this:

event_time	user_identity	action_name	request_params
2026-09-11 14:32:10	analyst@demo.com	commandSubmit	{table: production.sales.customers}
2026-09-11 14:31:55	engineer@demo.com	getTable	{table: production.sales.customers}

While the results didn’t directly reference the production.files.documents volume, I noticed that the request_params included a table from the production.sales catalog. This was a red flag—activity related to the production catalog was being recorded, but not the specific volume in question.

I realized that the audit logs might not be capturing volume-level operations, or perhaps the volume was being accessed through a different path. I needed to cross-check this with the access grants again to make sure I wasn’t missing any permissions.

Next Steps

Based on the findings so far, I concluded that the data_engineers group had write access to the production.files.documents volume, which was not intended. I would need to escalate this to the security team to review the access controls and investigate whether any unauthorized writes had occurred.

Going forward, I plan to set up more granular access controls and monitor the audit logs more closely to ensure that only authorized users can interact with the production volumes.