October 30, 2025
We built a dashboard with interesting insights about our experimental pipeline. Then we realized: not everyone on the intranet should see this data.
The quick fix? Add a password to the app.
Within two weeks, this “simple solution” became a problem:
→ New employees needed dashboard access but didn’t know who to ask
→ People shared the password over Slack (security theater at its finest)
→ The data team became password managers
→ IT was frustrated we’d bypassed proper user management
→ Every new dashboard meant another password to manage
We’d solved the immediate problem but created ongoing overhead.
𝗧𝗵𝗲 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻-𝗹𝗮𝘆𝗲𝗿 𝘁𝗿𝗮𝗽:
When you implement access control at the application level, you’re fighting an uphill battle. Each new tool requires:
→ Its own authentication system
→ Manual user management
→ Inconsistent security policies
→ Someone to play gatekeeper
𝗧𝗵𝗲 𝗱𝗮𝘁𝗮 𝗹𝗮𝘆𝗲𝗿 𝗮𝗹𝘁𝗲𝗿𝗻𝗮𝘁𝗶𝘃𝗲:
Implement access controls where the data lives:
→ Database-level permissions tied to Active Directory/SSO
→ Views that automatically filter based on user roles
→ Row-level security for sensitive data
→ One place to manage access across all applications
Now IT handles user management (their actual job). Your data team focuses on building tools, not managing passwords. Every new dashboard automatically inherits proper access controls.
𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝗮𝘁 𝗲𝗻𝗮𝗯𝗹𝗲𝘀 𝗿𝗲𝗮𝗹 𝗱𝗮𝘁𝗮 𝗱𝗲𝗺𝗼𝗰𝗿𝗮𝘁𝗶𝘇𝗮𝘁𝗶𝗼𝗻
You can’t build self-service tools if every new dashboard requires custom security implementation. Data layer guardrails let you say “build whatever you need” instead of “check with us about access controls first.”
The best security is the kind users don’t even notice—they just see the data they’re supposed to see.
How are you handling access control for sensitive data? Application layer or data layer?
