DEV Community: Victor B Vieira

RBAC Is Not Enough for Sensitive Investigation Workflows

Victor B Vieira — Sat, 24 Oct 2026 01:06:54 +0000

At first, an anonymous reporting system looks like a fairly ordinary CRUD application.

Someone submits a report.

An administrator receives it.

Evidence gets attached.

The case moves through a few statuses.

Eventually, someone closes it.

You can model that with roles:

reporter
investigator
admin

And permissions:

reporter      -> create report, read own case
investigator  -> read cases, add notes
admin         -> read everything, manage users

Simple.

Until the first sensitive case arrives.

Imagine an employee reports their own manager.

That manager happens to be an administrator.

Should admin still mean:

can_read_all_cases = true

Obviously not.

And that's where the authorization model starts getting much more interesting.

The problem is no longer:

What role does this user have?

It becomes:

What is this user's relationship with this specific case?

Role-based access is only the first layer

RBAC works well when permissions mostly follow organizational roles.

A billing employee sees billing information.

Support sees tickets.

Administrators configure the system.

Sensitive investigations introduce another dimension: context.

A user can be perfectly authorized to investigate reports in general and still be forbidden from accessing one particular report.

For example:

can_access_case =
    has_investigator_role
    && !is_subject_of_case
    && !has_conflict_of_interest

That is already different from standard RBAC.

Now imagine another situation.

An HR director is allowed to access investigations.

But the case mentions their spouse.

Or their direct report.

Or their own department.

The role didn't change.

The context did.

This is why systems that deal with sensitive cases often need some combination of:

role-based permissions;
case-level permissions;
explicit exclusions;
conflict-of-interest rules;
temporary assignments;
auditable overrides.

"Admin" stops being a sufficient security model very quickly.

Case access and identity access should not be the same permission

Another mistake is treating a report as one indivisible object.

Suppose the report contains:

case
├── allegation
├── attachments
├── reporter identity
├── internal notes
├── interviews
├── investigation findings
└── resolution

Does everyone who can access the case need to see every field?

Usually not.

An investigator may need to read the allegation but not know the reporter's identity.

Someone reviewing evidence may need attachments but not internal interview notes.

A compliance lead may need to approve the final decision without seeing unnecessary personal information.

So instead of:

can_view_case

you start needing permissions closer to:

can_view_report
can_view_reporter_identity
can_view_evidence
can_view_internal_notes
can_add_evidence
can_interview
can_assign_case
can_close_case

This matters for privacy, but it also changes your domain model.

The reporter's identity should not just be another field conveniently returned by:

GET /cases/:id

If identity deserves stronger protection, model it that way.

Different storage.

Different access policy.

Different audit trail.

Possibly different encryption boundaries.

The data model should reflect the sensitivity model.

Anonymity is not a boolean

Developers are often tempted to model anonymity like this:

{
  "anonymous": true
}

But anonymity is not really a property of the report.

It is a property of the entire system around the report.

You can remove the name field and still collect:

IP addresses;
analytics identifiers;
session metadata;
authentication information;
reverse-proxy logs;
device fingerprints;
email notifications containing sensitive context.

The UI may tell the user:

Your report is anonymous.

Meanwhile the infrastructure may know exactly where it came from.

That doesn't necessarily mean those systems are malicious.

It often means nobody modeled anonymity as an architectural requirement.

For sensitive reporting, a better question is:

Which pieces of information could allow us to identify this person, and do we actually need them?

That's data minimization as an engineering decision, not just a privacy-policy sentence.

Anonymous follow-up creates another design problem

If you don't know who the reporter is, how do you ask them another question?

You still need conversations like:

Can you tell us approximately when this happened?

or:

Do you still have the original file?

Traditional messaging assumes identity.

Anonymous reporting can't.

One pattern is to issue an opaque credential when the report is created:

report_id
access_token

The reporter stores that credential and uses it to return later.

Something conceptually like:

POST /reports

201 Created

{
  "report_id": "RPT-8FH2K",
  "access_token": "<opaque-secret>"
}

The token is not an account.

It doesn't need an email address.

It simply proves that whoever holds it is allowed to access the reporter-facing side of that specific case.

That lets the system provide bidirectional communication without forcing identity.

But then more questions appear:

Can the token be recovered?
Can administrators see it?
Should it be stored hashed?
Can it be rotated?
What happens if it is leaked?
How long does it remain valid?

The apparently simple requirement "allow anonymous follow-up" becomes an authentication design problem.

Evidence needs history, not just storage

Attachments are another deceptively simple feature.

The product requirement may begin as:

Users can upload evidence.

So you create:

attachments

and store files somewhere.

But once those files may influence an investigation, the system needs to answer more questions.

Where did this file come from?

When was it uploaded?

Was it replaced?

Who downloaded it?

Did anyone modify its metadata?

Was it deleted?

If it was deleted, why?

A useful evidence record might look more like:

Evidence
--------
id
case_id
original_filename
storage_key
content_hash
submitted_at
submitted_by
source_type
status

And then every important operation becomes an event:

EVIDENCE_UPLOADED
EVIDENCE_VIEWED
EVIDENCE_DOWNLOADED
EVIDENCE_MARKED_IRRELEVANT
EVIDENCE_RESTRICTED

Notice what is missing:

EVIDENCE_SILENTLY_DISAPPEARED

For sensitive systems, destructive CRUD operations deserve suspicion.

Sometimes the better model is not:

DELETE FROM evidence
WHERE id = ?;

but something closer to:

status = discarded
discard_reason = duplicate
discarded_by = investigator_42
discarded_at = ...

The original remains protected according to retention rules, while the investigation history remains understandable.

Whether you need immutable storage, hashing, signed records or stronger chain-of-custody controls depends on the system.

But auditability should be designed before you need it.

Your audit log is security infrastructure

Most applications have logs.

That doesn't automatically mean they have an audit trail.

An application log might say:

GET /api/cases/381 200

An investigation audit trail should answer something more useful:

actor: user_827
action: viewed_reporter_identity
case: case_381
timestamp: ...
reason: assigned_investigator

Those are different things.

For highly sensitive operations, I want to know:

who performed the action;
which case it affected;
what kind of data was accessed;
when it happened;
whether the action was authorized;
when relevant, why it happened.

And the audit system itself needs protection.

If administrators can rewrite the audit trail, it isn't much of an audit trail.

Investigation state is richer than open/closed

Another place where domain complexity leaks into the software is case status.

The naive model:

open
closed

doesn't tell you much.

So maybe you add:

new
triage
investigating
resolved
closed

Better.

But eventually you discover that workflow state and investigation outcome are different concepts.

A case might be:

workflow_status = closed

while its outcome is:

outcome = inconclusive

That matters because an inconclusive report is not the same thing as a false report.

A more expressive model separates them:

workflow_status:
  new
  triage
  investigating
  awaiting_information
  decision_pending
  closed

outcome:
  substantiated
  partially_substantiated
  unsubstantiated
  inconclusive

Why care?

Because software shapes behavior.

If your UI forces investigators to choose only:

true
false

you are embedding an oversimplified policy into the product.

Your enum is making an organizational decision.

Conflicts of interest belong in the domain model

This is another thing I initially thought belonged entirely to company policy.

It doesn't.

Suppose Alice is normally an investigator.

A report arrives involving Alice.

The system should not rely on another administrator remembering:

Oh, we probably shouldn't assign that one to Alice.

The conflict should be representable.

For example:

CaseParticipant
---------------
case_id
user_id
relationship

relationships:
  reporter
  subject
  witness
  investigator
  reviewer
  conflicted

Now authorization can use domain information.

Conceptually:

def can_access_case(user, case):
    if not user.has_permission("investigate"):
        return False

    if case.has_conflict(user):
        return False

    return case.is_assigned_to(user)

Real systems will be more complex.

But the important point is this:

conflict of interest stops being a note in a policy PDF and becomes something the application can enforce.

That's a much stronger guarantee.

Overrides should be possible — and uncomfortable

Eventually someone will need emergency access.

Maybe every normal investigator is conflicted.

Maybe a legal hold requires access.

Maybe an incident needs escalation.

Hard-coding "never" into authorization rules can make a system unusable.

But the opposite is also dangerous:

super_admin = god_mode

A useful pattern is controlled break-glass access.

For example:

override requires:
- elevated permission
- explicit reason
- re-authentication
- audit event
- optional second approval

You are not making the action impossible.

You are making it deliberate and visible.

That difference matters.

Sensitive workflows make generic admin panels dangerous

A lot of SaaS products are built around the idea that the customer administrator owns everything.

For many products, that's reasonable.

For sensitive reporting systems, it can be exactly the wrong assumption.

The person who bought the software may not be entitled to inspect every report.

The company owner may be the subject of a report.

The account administrator may work in the department being investigated.

So tenant ownership and data access cannot automatically mean the same thing.

This is one of those cases where traditional B2B SaaS assumptions start breaking.

The customer owns the workspace.

That does not necessarily mean every customer administrator should be able to read every piece of information inside it.

The hardest requirements often appear after `POST /reports`

When we first think about a reporting system, it's natural to focus on intake.

The form.

Validation.

File uploads.

Anonymous submission.

Those are visible.

They are easy to put on a roadmap.

But most of the difficult engineering decisions happen afterward:

submit
  ↓
triage
  ↓
conflict detection
  ↓
assignment
  ↓
evidence collection
  ↓
restricted interviews
  ↓
decision
  ↓
follow-up
  ↓
retention

Every arrow hides authorization decisions.

Every box contains potentially sensitive data.

And every shortcut can affect whether users trust the system.

That's why I no longer think of anonymous reporting as a form with a back office.

It's a context-sensitive authorization system wrapped around an investigation workflow.

The form is just where the data enters.

A few questions I now ask much earlier

If I were designing another sensitive workflow from scratch, I'd ask these before choosing the database schema:

Can someone be authorized globally but forbidden from one specific case?

Is identity access separate from case access?

Can sensitive information disappear without leaving a trace?

Can users communicate without revealing their identity?

Can the system represent conflicts of interest?

What happens when normal authorization rules need an emergency override?

Do our statuses reflect the real domain, or just make the UI convenient?

If those questions arrive late, changing the architecture becomes much more painful.

If they arrive early, they shape a much better system.

AI assistance disclosure: AI was used during drafting and editing. The technical concepts and product decisions were reviewed by the author before publication.

Conceptual illustration of a sensitive reporting workflow. AI-generated.

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

DEV Community: Victor B Vieira

RBAC Is Not Enough for Sensitive Investigation Workflows

Role-based access is only the first layer

Case access and identity access should not be the same permission

Anonymity is not a boolean

Anonymous follow-up creates another design problem

Evidence needs history, not just storage

Your audit log is security infrastructure

Investigation state is richer than open/closed

Conflicts of interest belong in the domain model

Overrides should be possible — and uncomfortable

Sensitive workflows make generic admin panels dangerous

The hardest requirements often appear after POST /reports

A few questions I now ask much earlier

When a Legal Requirement Turns Into an Authorization Problem

The requirement

Who is allowed to see a report?

admin stops being useful pretty quickly

Anonymous to whom?

Then comes the messaging problem

Trust is another part of the architecture

The law defines an outcome, not an architecture

The form is probably the least interesting part

A note on this article

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

1. A Form Without a Name Can Still Identify Someone

2. Continuity Does Not Require Identity

3. Uploaded Files Are Part of the Threat Model

4. Conflict of Interest Becomes an Authorization Problem

5. Technical Anonymity Is Not Enough

💬 Community Question: When Is a System Truly Anonymous?

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

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

2. Zero-IP Logging Policy & Anonymous Protocol Tokens

3. PII Anonymization for Responsible AI Features

4. Immutable Audit Trails

💬 Community Question: What Are We Missing?

The hardest requirements often appear after `POST /reports`

`admin` stops being useful pretty quickly