The risk with a coding agent is not only what it can reach. It is what comes back. When Claude queries a production database to debug a failing job, the rows it gets back can carry real customer emails, tokens, and card numbers, and those values land in the agent's context, its logs, and possibly a model provider's servers. Data masking is the control that decides what the agent actually sees, and the pitfall almost everyone hits is doing it too late.
Walk the failure modes first, then the place masking has to sit to avoid them.
Where data masking goes wrong
- Masking after the data has already moved. If you scrub values in the agent's logs after the fact, the unmasked data already passed through the agent's context. The moment to mask is before the data reaches the agent, not after.
- Masking the agent performs on itself. If the agent is trusted to redact its own results, a confused or compromised agent can skip the step. The control cannot live in the thing it is supposed to constrain.
- All-or-nothing access. Teams react to the risk by denying the agent any access to real data, which kills its usefulness for real debugging. Masking is the middle path: the agent sees the shape of the data without the sensitive values.
- Masking that breaks the query. Replacing a value with garbage that no longer parses as the right type can break the agent's logic. Good masking preserves format so a masked email still looks like an email.
The common thread is timing and placement. Data masking only works if it happens in flight, on the path the data takes back from the system, applied by something other than the agent.
What in-flight data masking requires
The requirement is specific to this topic: the masking has to run on the connection between the infrastructure and the agent, before the response reaches the agent process. Not in the database, which would change the stored data. Not in the agent, which is the thing you are protecting against. On the wire, at the boundary the data already flows through.
That points at one architecture. Claude reaches the database, the internal API, or the service through hoop.dev, a Layer 7 access gateway, instead of connecting directly. Because every response flows back through the gateway, hoop.dev applies inline data masking to that response before it returns to the agent. The sensitive fields are masked on the connection itself, so the values that reach Claude were never the real ones. The database is untouched, and the agent is never trusted to redact anything. The learn pages cover how masking is applied inline, and the getting-started docs show how to front the system the agent queries.