Data Masking
Sensitive values are rewritten in the response, in memory, before they reach the client. The request itself is never touched.
Real schemas, real volumes, real edge cases. That is what makes an agent useful, and it is why teams point them at production in the first place.
The problem was never the query. It is what comes back: SELECT * returns the email column, the card number, the national ID, and it lands in a context window you do not control.
How it works
A masking rule pairs an entity with a strategy. The sidecar reads every response coming back from your resource and applies the rule before the client sees a byte.
You declare what to look for: EMAIL_ADDRESS, US_SSN, CREDIT_CARD. The rule matches the value in the response, so it holds when a schema changes and it catches the same data in a column nobody tagged.
Redact removes the value. Partial keeps the last digits. Hash keeps it stable, so a masked column still joins. You pick per rule.
The rewrite happens inside the sidecar, on the bytes coming back. Nothing is written anywhere, and your database is never modified.
Postgres, SQL Server, and HTTP. The same rule covers a query result, an API payload, and a shell session reading a file.
The request is never touched
Nothing rewrites the statement on the way in. No injected WHERE clause, no swapped column, no proxy guessing at intent. The database plans and executes exactly what the agent asked for.
The rewrite happens on the way back. Counts are still right. Joins still resolve. The agent gets a working answer with the sensitive values gone.
Name what your agents should never see and start the sidecar. Free and open source under MIT.