Every vendor demo has the same magic trick. Someone logs in as “admin,” clicks around a dashboard full of other people’s detection logic, credentials, and deployment buttons, and nobody in the room asks the only question that matters: who *else* has this exact login. In most detection engineering tooling the honest answer is “everyone with a browser and a Slack invite,” because access control got treated as a v2 feature, then a nice-to-have, then a thing the security vendor’s own security posture apparently doesn’t require of itself. We’ve watched detection platforms hand L1 analysts the same permissions as the person who owns the SIEM deployment credentials, then act surprised when someone fat-fingers a rule change straight into prod. That’s not an access model. That’s a shared Google Doc with better branding.
The flat-access anti-pattern, named and shamed
Here’s the failure mode we keep seeing in the wild, unnamed because nobody wants to admit they built it: RBAC theater. You get a role dropdown in the settings page — Admin, User, maybe “Power User” if someone was feeling fancy — and every one of those roles can see, edit, and deploy every object in the tenant. The dropdown exists so the compliance checklist has something to point at during the audit. It does not exist to actually stop your Tier 1 SOC hire, three weeks into the job, from opening the credential vault that authenticates to your Sentinel workspace. Nobody designed that outcome. Nobody has to design an outcome for it to happen — flat access is the default state of software, and defaults win unless someone deliberately fights them.
The tell is always the same: ask “can a read-only user accidentally deploy a detection rule to production,” and watch the founder’s face change. Or ask “who is allowed to configure the Defender API credentials,” and get the answer “well, technically, anyone who’s logged in.” That’s not a hypothetical for us — that’s a summary of half the detection-as-code tooling landscape we’ve had to work around before building our own.
What HEFAISTOS actually enforces
We didn’t invent role-based access control, obviously — nobody gets a trophy for that. What we did is refuse to let it be cosmetic. HEFAISTOS ships seven roles, and each one means something specific and enforced, not aspirational:
- ADMIN — owns organization settings, integrations, credentials, and Detection-as-Code deployment for their org. Full authority, full blast radius, fully scoped to their organization.
- ANALYST — builds and manages detection rules through their lifecycle. Creates. Doesn’t get to touch the platform credentials that actually push a rule to Sentinel or Defender.
- REVIEWER — approves rules for deployment. Governance role. Can say no to a bad rule without needing deployment credentials to do it.
- VIEWER — read-only. The manager auditing your detection coverage doesn’t need write access to see what you built, and giving it to them anyway is how “I was just looking” turns into an incident report.
- ELONE — L1 support. Restricted to the L1 Portal, Knowledge Base, and Pain Points. Not because L1 analysts are less trustworthy as people, but because their job is triage and escalation, not editing detection logic they didn’t write and don’t own the context for.
- BOT_AUDITOR_ORG / BOT_AUDITOR_GLOBAL — dedicated read-only service accounts for automation and audit tooling, scoped to one org or the whole platform. Because your CI pipeline querying rule status should never be one config typo away from also being able to edit rule status.
Here’s the part that actually matters and the part most platforms skip entirely: platform credentials and Detection-as-Code deployment are admin-only, full stop. An ANALYST can write a beautiful detection. A REVIEWER can bless it. Neither of them can hold the keys that push it live against Defender, Sentinel, Splunk, QRadar, or Wazuh. That’s not us being precious about hierarchy — that’s us refusing to let “I have an account on this platform” quietly become “I can authenticate to your production SIEM.” Those are supposed to be different levels of trust. Most tools collapse them into one because separating them is more engineering work than a role dropdown, and dropdowns demo well.
The ELONE confession: we almost got this wrong too
We’ll own the part where we didn’t have this fully right from day one. Early on, L1-facing accounts had more visibility into the platform navigation than they should have — enough that an L1 hire could technically browse into surfaces that had nothing to do with their job, just because nobody had bothered building the redirect. The fix wasn’t a permissions checkbox buried three menus deep, it was making ELONE a first-class role with its own navigation boundary: L1 Portal, Knowledge Base, Pain Points, My Profile. Full stop. The frontend actively redirects ELONE users who try to wander outside that surface, because “technically possible to view” and “supposed to be visible” are not the same thing, and pretending otherwise is how L1 support ends up able to see ACH analyses they have zero context for and zero business editing.
Organizations are boundaries, not vibes
The other half of this that gets skipped: a normal human user belongs to exactly one organization. Not “mostly one organization, with some cross-tenant visibility if the UI happens to leak it.” One. Your rules, your workbenches, your credentials, your MISP settings, your SMTP config — all organization-scoped, all invisible to a different tenant unless that tenant is under the same entity and sharing has been explicitly configured. We’re not going to pretend multi-tenant boundary enforcement is exciting content for a blog post. It isn’t. It’s also the difference between a platform you can put an MSSP’s twelve clients on and a platform where client fourteen’s analyst can accidentally browse client three’s detection logic because someone forgot a `WHERE organization_id =` clause somewhere.
Why this is a detection engineering problem, not just an IT hygiene problem
Access control failures in a DE platform aren’t abstract compliance risk. They’re operational risk with a blast radius measured in false negatives and production incidents. An L1 analyst who can silently edit a detection rule can silently break coverage nobody notices until the thing it was supposed to catch walks straight through. A read-only viewer with accidental write access is how “I was just checking the ACH matrix” becomes “why did this analysis get modified two weeks before the incident.” A flat-access detection platform doesn’t just fail an audit — it fails the thing detection engineering exists to do, which is produce detections you can actually trust weren’t tampered with by someone who didn’t understand what they were touching.
We built the role model boring on purpose. Boring means enforced. Boring means your L1 hire can’t fat-finger a production credential on day three, your reviewer can gate deployment without needing the keys to the SIEM, and your MSSP can run twelve tenants without praying nobody notices the tenant boundary is decorative. Access control that only shows up in the settings dropdown and nowhere else in the actual permission checks isn’t a feature. It’s a liability with a nice UI.
Good riddance, flat access.
Featured image generated using Artificial Intelligence (EU AI Act transparency notice).