DEV Community: Victor B Vieira

When a Legal Requirement Turns Into an Authorization Problem

Victor B Vieira — Fri, 02 Oct 2026 17:06:00 +0000

At first, the requirement sounded almost trivial:

Employees need a way to submit anonymous reports.

Build a form. Store the report. Give HR an admin panel.

Done.

Except it wasn't.

Once we started breaking the requirement down, a simple reporting form became an authorization problem, then a privacy problem, then a governance problem.

And most of the difficult parts had very little to do with the form itself.

The requirement

In Brazil, Law No. 14,457/2022 introduced several requirements for companies that maintain a CIPA — the country's Internal Commission for Accident and Harassment Prevention.

One of them is particularly interesting from a software perspective.

Companies need procedures for receiving and following up on reports, investigating what happened, and potentially applying sanctions while guaranteeing the anonymity of the person submitting the report.

That's a legal requirement.

But someone eventually has to turn it into software.

And that's where the ambiguity starts.

Who is allowed to see a report?

Imagine the first version of the application.

You have:

a public reporting form;
an authenticated dashboard;
attachments;
comments;
report statuses;
an audit history.

Pretty standard internal software.

Then this report arrives:

My manager has been harassing me.

Now suppose that manager also has administrative access to the reporting system.

Suddenly, the permission model is wrong.

It doesn't matter that the reporter's name is hidden if the person being reported can open the case, see its contents, or infer where it came from.

So we get a new rule:

Someone mentioned in a report should not be able to manage that report.

That sounds obvious after you hear it.

It isn't necessarily obvious when you design the first database schema.

`admin` stops being useful pretty quickly

A lot of internal software begins with something like:

user
admin

For this kind of system, that abstraction falls apart almost immediately.

You might have:

HR;
compliance;
company directors;
external investigators;
organization administrators;
members of the CIPA.

Different roles can see different things.

But even that isn't enough.

Because access can depend on the content of the report itself.

Alice may normally be allowed to see every report.

Unless Alice is mentioned in this one.

So authorization becomes something closer to:

can_access =
    has_permission
    && !is_involved_in_report

Which means this is no longer just classic RBAC.

The authorization decision now depends on context.

And once you go down that path, a lot of other questions show up.

Who determines that someone is involved?

Can another administrator override the restriction?

What happens if every person with the appropriate role is mentioned?

Who can see that access was revoked?

Should the database enforce this, or should the application?

A requirement that originally sounded like "add an anonymous form" is now shaping the authorization model.

Anonymous to whom?

"Anonymous" is another word that sounds simple until you have to define it.

The form not asking for a name is one thing.

The company administrator being unable to identify the reporter is another.

The infrastructure itself not retaining data that could later be correlated with that person is something else entirely.

A perfectly anonymous-looking form can still sit behind:

IP logs;
analytics scripts;
authentication middleware;
session identifiers;
reverse proxy logs;
third-party monitoring tools.

None of those systems are inherently bad.

Most are things we would add to a normal application without thinking much about them.

But privacy-sensitive products force you to ask a different question:

Do we actually need to collect this information?

Sometimes the safest data is simply data you never stored.

Then comes the messaging problem

Reports are rarely complete.

Someone submits something like:

My manager threatened me after the meeting.

For an investigation, that may not be enough.

Which meeting?

When?

Was anyone else there?

Is there a message or document related to it?

Normally, the obvious solution is:

Send the user an email.

Except you don't know who the user is.

And ideally you don't want to know.

So the identity model needs to change.

Instead of attaching the conversation to a person, you can attach it to the report itself.

Conceptually:

report_id
access_token

The reporter keeps a credential.

They can return later, see replies, provide additional information, and follow the status of the case.

The investigator talks to the holder of that credential without knowing who that person is.

Nothing particularly exotic is happening technically.

But a domain requirement completely changes how a very ordinary feature — messaging — has to work.

Trust is another part of the architecture

There's also a problem code alone can't solve.

You can build everything correctly.

You can avoid storing IP addresses.

You can minimize logs.

You can encrypt sensitive fields.

You can implement contextual access policies.

You can automatically remove someone from a case when they're involved in it.

And an employee can still look at the Submit report button and think:

Is this actually anonymous?

That's rational.

The person using the system isn't reading the source code.

They're not inspecting proxy configuration.

They're not reviewing database policies.

They're being asked to trust the system.

So technical decisions eventually become UX decisions.

Compare:

Your report is anonymous.

with:

We do not ask for your identity or store your IP address.

The second statement is more specific.

It explains something the system actually does.

That sort of explainability matters more than I originally expected.

The law defines an outcome, not an architecture

This is probably the part I find most interesting.

Brazilian Law No. 14,457/2022 doesn't tell developers to use PostgreSQL.

It doesn't say:

use row-level security
don't log IP addresses
implement contextual RBAC
require two administrators
use magic-link authentication

It defines obligations and expected outcomes.

The implementation is left to the organization building the system.

That happens a lot in B2B software.

A requirement arrives as:

We need to comply with X.

You start decomposing it.

And underneath that sentence you find decisions involving:

architecture;
permissions;
security;
privacy;
data retention;
UX;
auditability;
governance.

The regulation describes the destination.

Engineering has to figure out the road.

The form is probably the least interesting part

This:

<textarea></textarea>
<button>Submit report</button>

is easy.

The hard questions come afterward.

Who receives the report?

Who must never receive it?

Who audits access?

How do you communicate with someone you can't identify?

What should you log?

What should you intentionally not log?

How do you handle conflicts of interest?

And how do you explain all of this to the user well enough that they trust the system?

That's when something that originally looked like "an HR form" becomes a much more interesting engineering problem.

I'm particularly curious about one part of this:

If access to a record depends on whether the current user is mentioned inside that record, where would you enforce that rule?

Application layer?

Database policies?

A dedicated authorization layer?

Something else?

A note on this article

I work as CTO and co-founder at Sigilo, where we build privacy-first reporting and organizational feedback systems.

The examples and technical decisions discussed here come from problems we've encountered while designing these workflows.

I used AI assistance to help structure and refine the English version of this article. The technical reasoning, product experience, and final review are my own.

Anonymity Is Not a Checkbox: Lessons From Building a Whistleblowing System

Victor B Vieira — Thu, 24 Sep 2026 18:06:17 +0000

When we started building the whistleblowing channel at Sigilo Profissional, anonymity seemed like one of the simpler requirements.

Do not ask for a name.

Do not require an email address.

Do not force users to create an account.

Done, right?

Not exactly.

The deeper we went into the architecture, the clearer it became that anonymity is not a UI feature. It is a system-wide constraint.

Here are some of the problems we had to think about.

1. A Form Without a Name Can Still Identify Someone

A reporting page can display:

"Your report is 100% anonymous."

But the infrastructure behind it may still collect:

IP addresses
X-Forwarded-For
session identifiers
persistent cookies
User-Agent data
infrastructure logs
precise timestamps
analytics events

The problem is not always one individual data point.

It is correlation.

A report submitted at 14:37, for example, may become much less anonymous if someone can compare that timestamp with corporate VPN, Wi-Fi, firewall, or internal access logs.

This led us to a simple privacy principle:

If identifiable data is not required to provide the feature, why store it?

At Sigilo, whistleblowers do not need to create an account, provide a name, or enter an email address.

We also do not store their IP address.

Instead, reports can be accessed later through an independently generated protocol.

Which creates another interesting problem.

2. Continuity Does Not Require Identity

After submitting a report, the whistleblower may need to return later.

Maybe they want to check the investigation status.

Maybe the compliance team needs additional information.

Maybe they need to upload another document.

In a traditional application, the solution would probably be:

email + password

or a persistent authenticated session.

But the question we actually need to answer is not:

"Who is this user?"

It is:

"Is this person authorized to access this report?"

Those are different problems.

We can preserve continuity without establishing real-world identity.

Conceptually:

anonymous user
      ↓
random protocol
      ↓
specific report
      ↓
follow-up communication

The system knows that someone has the correct credentials to access a specific case.

It does not need to know who that person is.

That distinction between identity and continuity became one of the most interesting patterns in the product.

3. Uploaded Files Are Part of the Threat Model

Removing IP logging still does not make a system anonymous by itself.

Suppose someone uploads a .docx.

That file may contain:

author information
operating-system usernames
creation dates
software metadata
revision history

Images may contain EXIF metadata.

Spreadsheets can contain document properties.

Even screenshots may accidentally expose information the sender did not intend to share.

So the threat model cannot stop at the HTTP request.

User-generated files are part of the anonymity boundary too.

And there is another limitation no architecture can completely solve.

Imagine a report containing:

"Yesterday at 2 PM, during a meeting attended only by my manager, John, and me..."

The application can minimize technical traces.

It cannot prevent contextual inference.

Privacy engineering can reduce what the system leaks.

It cannot remove information voluntarily provided by the human.

4. Conflict of Interest Becomes an Authorization Problem

Another requirement that initially looked like a business rule quickly became an access-control problem.

Imagine three managers responsible for reviewing reports.

The first version of the workflow looks simple:

Report
   ↓
Responsible Group

Now imagine the report is about one of those three managers.

That person should obviously not receive access to the case.

So the workflow becomes closer to:

Report
   ↓
Responsible Group
   ↓
Detect involved reviewers
   ↓
Exclude them from the case
   ↓
Fallback route if necessary

In simplified pseudocode:

def can_access_report(reviewer, report):
    if reviewer.id in report.involved_people:
        return False

    return reviewer.id in report.assigned_reviewers

But then more questions appear.

What if every reviewer is involved?

What if a reviewer joins the group after the case was created?

Should access be retroactive?

What happens when someone leaves the investigation team?

How do we preserve an audit trail for every access change?

A seemingly simple workflow quickly becomes a problem involving authorization, auditability, segregation of duties, and conflict-of-interest management.

5. Technical Anonymity Is Not Enough

This is probably the part I find most interesting.

We can strip IP addresses.

Minimize logs.

Use strong access controls.

Avoid persistent identifiers.

Protect tenant boundaries.

But none of that automatically answers this question:

Why should the employee believe us?

The person using the system may be reporting their own manager.

Harassment.

Fraud.

Discrimination.

Something that could affect their career.

In that context, "Trust us, your data is safe" is not enough.

Some technical decisions become part of the product experience itself.

For example:

"We do not store your IP address."

That is an infrastructure decision.

But it is also information that helps the whistleblower understand why the system is designed to protect their anonymity.

This changed how I think about privacy-sensitive software.

The user's perception of safety is not separate from the architecture.

It is part of whether the product works at all.

💬 Community Question: When Is a System Truly Anonymous?

The biggest lesson for me has been that anonymity is not something you add at the end of development.

It affects infrastructure, data collection, authentication, authorization, file handling, UX, and even internal business processes.

So I would love to hear how other developers approach this:

At what point do you think a software product can legitimately describe itself as anonymous?

And which layer of the stack do you consider the hardest to protect against indirect identification?

Especially interested in edge cases from people working with privacy, security, or other sensitive-data systems.

Victor Vieira | CTO & Co-founder @ Sigilo Profissional

🔗 LinkedIn: Victor Vieira

Designing a Privacy-First Architecture for Sensitive Data: Zero-IP Logging, Postgres RLS, and AI Safety

Victor B Vieira — Mon, 14 Sep 2026 18:32:41 +0000

When building software that handles sensitive human data (like workplace feedback, satisfaction surveys, and compliance reports), security and privacy cannot be treated as optional features or mere legal disclaimers. They must be embedded into the core system design.

At Sigilo Profissional (sigiloprofissional.com.br), a B2B SaaS platform focused on Workplace Climate Surveys, eNPS, and Whistleblowing Channels compliant with ISO 37002 and GDPR / LGPD, privacy is the fundamental prerequisite for psychological safety. If employees do not trust the platform's anonymity, engagement drops to zero.

Here is a breakdown of the security architecture and privacy controls we implemented in our Python (FastAPI) and PostgreSQL stack.

1. Dual-Layer Multi-Tenancy (Application + PostgreSQL RLS)

To prevent cross-tenant data leakage, we enforce tenant isolation at two independent layers:

Application Layer: Every query filters by firm_id within SQLAlchemy.
Database Engine Layer: PostgreSQL Row Level Security (RLS) is enabled on all tenant tables. The application middleware sets SET LOCAL app.firm_id per database session.

-- Enforcing PostgreSQL Row Level Security (RLS)
ALTER TABLE tenant_complaints ENABLE ROW LEVEL SECURITY;

CREATE POLICY firm_isolation ON tenant_complaints
  USING (firm_id = current_setting('app.firm_id')::uuid);

Why both? Even if a bug or missing filter occurs in application code, the database engine natively blocks access to data outside the active tenant context.

2. Zero-IP Logging Policy & Anonymous Protocol Tokens

To ensure complete whistleblower anonymity:

Proxy-Level IP Stripping: NGINX and edge proxies strip X-Forwarded-For and client IP headers. No IP addresses are saved in NGINX logs, application memory, or database records.
Cryptographic Tokens: Anonymous reports are tracked strictly through random protocol tokens (e.g., SGL-2026-7X3K). Whistleblowers can check updates using their protocol token without ever creating an account or storing session cookies.

3. PII Anonymization for Responsible AI Features

We use Large Language Models (LLMs) to assist employees in structuring clear reports and to summarize qualitative eNPS sentiment for management.

To prevent sensitive Personally Identifiable Information (PII) from being sent to external AI models:

Requests pass through an intermediate LiteLLM proxy layer that sanitizes names, emails, phone numbers, and location metadata before dispatching prompts.
AI outputs are strictly used for guidance and categorization, never for autonomous decision-making.

4. Immutable Audit Trails

Compliance frameworks (such as ISO 37002) require full auditability for compliance officers. We maintain immutable audit logs for administrative actions (e.g., status updates, report triage) using cryptographic hashing, ensuring complete transparency without compromising whistleblower anonymity.

💬 Community Question: What Are We Missing?

As we continue scaling our engineering stack, we are reviewing our security roadmap.

We would love feedback from the Dev.to community:

What automated query auditing or key rotation strategies do you recommend for multi-tenant Postgres RLS at scale?
Have you implemented additional client-side payload encryption patterns that balance searchability with absolute zero-knowledge privacy?

Looking forward to your thoughts and suggestions in the comments!

Victor Vieira | CTO & Co-founder @ Sigilo Profissional
🔗 LinkedIn: Victor Vieira