Skip to content
Walkthrough: Creati...
 
Notifications
Clear all

Walkthrough: Creating a repeatable test to verify Claw's output filtering works.

1 Posts
1 Users
0 Reactions
2 Views
(@jakew)
Estimable Member
Joined: 1 week ago
Posts: 86
Topic starter   [#10215]

Hey everyone,

I’ve been deep in the weeds with Claw (the data lineage and sensitive data discovery tool, for anyone new) for the last few months, specifically around its ability to filter and redact sensitive column output for different user groups. It's a killer feature for compliance with least-privilege principles, but I found myself manually clicking through the UI every time we had an audit or a config change to "prove" it was working. That got old fast.

So, I built a repeatable, automated test to verify the filtering logic. The goal was to have something I could run as part of our CI/CD pipeline for our data governance configs, ensuring that our tagged PII, PCI, or PHI data is genuinely being obscured for unauthorized roles. I thought I'd share my approach here, as I imagine others wrestling with SOC 2 or ISO 27001 controls around data access might find it useful.

My stack for this test is basically Python, using Claw's API and good old `pandas` for assertions. The core idea is simple:
1. **Setup:** Tag specific columns in a test dataset (we use a small, synthetic customer table) with sensitivity labels like `pii.email` and `pci.card_number`.
2. **Configure:** In Claw, set up an access policy that says "Role_A" can see raw data, but "Role_B" gets filtered output (e.g., masked, hashed, or nulled).
3. **Execute & Verify:** Script the API calls to execute the same data query *as* each role, then compare the results programmatically.

Here's the general flow I scripted out:

* **Step 1:** Authenticate to Claw's API with an admin/service account.
* **Step 2:** For each defined role (e.g., `analyst_restricted`), generate a temporary session token or use role impersonation if your API supports it.
* **Step 3:** Run a predefined SQL query (through Claw's query endpoint) that touches the tagged columns, using each role's credentials.
* **Step 4:** Fetch the results into dataframes and run assertions. For example:
* For the privileged role: assert that `email` column contains clear-text emails (e.g., using a regex match).
* For the restricted role: assert that the same column values are transformed (e.g., `jane@doe.com` becomes `j@.com` or a consistent hash).
* **Step 5:** Log the results and fail the test if any assertion doesn't hold. I also capture a snapshot of the filtered vs. unfiltered output as evidence.

The tricky part was handling the different types of filtering Claw can do—masking, partial redaction, full nulling, or hashing. My test now has a mapping file that knows the expected transformation per tag and policy, so it's adaptable.

This has been a game-changer for our audit prep. Instead of scrambling for screenshots, we just run this test suite. It validates our data governance setup is technically enforced, not just documented. I'm curious if anyone else has built something similar for Claw or other tools like Collibra or Alation? How are you handling the validation of dynamic data masking or row-level security in your compliance workflows?

—Jake


Spreadsheets > opinions


   
Quote