Internal Support-Panel Tax-Data Firewall Automation: Three Layers, Because the First Two Will Eventually Fail

Building one careful, well-tested filter that removes sensitive fields before data reaches an internal tool is genuinely good engineering — but it concentrates all of the protection in exactly one place, and any single place can fail: a new field gets added somewhere the filter doesn't know about, a different code path assembles a response without going through the filter at all, or the filter itself has a bug nobody has found yet. A system that depends on one mechanism being perfect forever is making a much larger bet than a system that assumes any one mechanism will eventually have a gap, and builds a genuinely independent second and third check specifically for that moment.

The backend function serving Centriu's internal operations panel for the Income Tax module states its own design philosophy directly in its header comment, and it's worth repeating close to verbatim because the reasoning is the point: this function exists specifically so Centriu can operate the product — licenses, cost, failures, quality, versions, incidents — without reading anyone's income tax information, and it does this with three boundary layers, stated explicitly as all three needing to exist.

The first layer is structural, not a rule at all: the specific database tables this function is permitted to query simply have no column with the capacity to hold tax content — a deliberate schema decision from an earlier migration, not a runtime check that could be bypassed or forgotten. The second layer is an allowlist, implemented as a single exported list of every field name the panel is permitted to display, applied recursively to a response object at any nesting depth. The choice to build this as a positive list rather than a list of fields to remove is deliberate and explained directly in the code's own comment: a list of fields to STRIP protects exactly the fields someone remembered to write down and fails silently on a fourth, forgotten one; a list of fields ALLOWED to pass through fails toward safety instead — a new field added to some underlying table tomorrow simply doesn't appear on the panel until someone deliberately authorizes it, rather than appearing by default until someone notices and removes it.

The third layer is where the design becomes genuinely distinctive: after the allowlist has already run, a separate, independent function serializes the resulting response to its final JSON text and scans that finished text directly — checking for the literal presence of specific banned field names (things like a question's content, an answer, a document's stored path, a taxpayer's income figures, or a document identifier) and separately for text matching the shape of a Brazilian CPF or CNPJ number in any common formatting. If either check finds something, the ENTIRE response is refused outright, with a specific, named reason, rather than the offending piece being quietly stripped and the rest sent through. The code's own comment states the reasoning for that specific choice directly: a response that reaches this point still containing tax content indicates something read from the wrong table or assembled data outside the intended path, and the correct reaction to discovering that is to fix the underlying cause, not to clean up the symptom and let the response ship anyway.

What makes this a genuinely enforced guarantee rather than a described intention is architectural: every single code path in this backend function that returns a response to the panel funnels through one shared function, and that shared function is the only place the allowlist and the output-verification layer are invoked. There is no second, alternate way to construct a response from this endpoint that skips either layer — confirmed directly against the current source, where this remains true today.

A future code change to this backend function accidentally joins in a field from a table it wasn't meant to touch, and that field happens to carry a taxpayer's stored document identifier. Before reaching the panel, the allowlist alone would already exclude a field with that name if it isn't on the approved list — but if it somehow arrived under a permitted-sounding name, the output-verification layer's pattern check would still catch the CPF-shaped or document-shaped content in the finished response and refuse to send it, rather than quietly delivering a mostly-clean response with a sensitive fragment still inside.

Centriu's own operations team can manage the Income Tax module's licenses, investigate failures, and review costs and quality entirely through this panel, with a structural, an allowlist, and an output-verification guarantee — not just one filter — standing between that work and any individual's actual tax content. A mistake that gets past any one layer still has two more chances to be caught before a response ever leaves the function.

This mechanism protects what Centriu's own internal panel can see and display — it says nothing about a different organization's own internal access controls for its own staff using the Income Tax module's customer-facing features, which are governed by a separate set of controls. It is also specifically an internal operations boundary, not a general-purpose data-loss-prevention product feature offered to Centriu's own clients.

A single filtering step that removes known-sensitive fields and forwards the rest is a reasonable first layer, but it treats every gap it might have as invisible until someone happens to notice. Centriu Gauge's design adds a genuinely independent second opinion specifically for the moment the first layer has a gap — one that refuses the entire response outright rather than trying to salvage and ship it, on the stated reasoning that a bad response reaching that point is evidence of an upstream mistake that needs fixing, not a symptom to mask.