Non Discretionary Control
You set up non discretionary control by binding system rules to central job roles. Users cannot change these rules or pass their own rights to other people. Most security teams start by mapping company job titles to fixed role groups. When these roles grow too broad, one login grants too much power across systems. A single mistake or stolen key can then harm many databases at once. How non discretionary control works in practice In a discretionary model, the file owner decides who can read or
Discretionary Access Control (DAC) + Non-Human Identity Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up non discretionary control by binding system rules to central job roles. Users cannot change these rules or pass their own rights to other people. Most security teams start by mapping company job titles to fixed role groups. When these roles grow too broad, one login grants too much power across systems. A single mistake or stolen key can then harm many databases at once.
How non discretionary control works in practice
In a discretionary model, the file owner decides who can read or write data. That owner can hand out rights to anyone on the team at any time. Non discretionary control removes that choice from normal users and data owners. A central admin team defines all rules based on job duties or security labels. When an engineer joins a team, an admin assigns them to a specific role. The role holds fixed rights to run certain apps or read certain database tables. If the engineer moves to a new group, the admin updates their role label. The system drops the old rights and applies the new ones right away. Users cannot share their keys or grant table rights to a peer. Every change must go through the central rule set and pass an audit check. This setup keeps permission rules clean across hundreds of servers and cloud accounts. It also aligns system rights with human resources records from day one.
Why role rules need extra steps for daily work
Teams often build role groups around broad departments like backend engineering or data science. Over time, new tasks require new database rights or server permissions. Instead of making a new role for one task, admins add permissions to existing roles. This habit causes role creep across the whole company within a few months. Soon, every engineer in the role has full write rights to production systems. Auditing these broad roles becomes a slow and painful task for security leaders. To keep roles tight, teams must split daily read rights from rare write actions. They also need a way to review high-risk tasks before anyone runs them. Static role assignments alone cannot separate safe daily work from dangerous one-off fixes.
What static roles solve and what they miss
Central role rules solve the problem of who can log in to a system. They stop users from passing secret keys or table rights to unauthorized peers. They also give auditors a clear map of which job titles touch sensitive systems. Still, static role setup only checks identity at the start of a session. Once a user logs in, the role does not watch what commands run next. A developer with a valid role can still run a bad query that drops tables. They can also pull thousands of customer emails or card numbers in one query. Native role checks cannot rewrite matched fields in results during a live query. They cannot pause a risky command to ask a peer for quick approval. Closing this gap requires control over each action in flight, not just login checks.
Discretionary Access Control (DAC) + Non-Human Identity Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does non discretionary control differ from mandatory control?
Both models use central rules that normal users cannot change on their own. Mandatory control uses strict security labels, while non discretionary models often use job roles.
Can a user share their permissions in this model?
No, users cannot pass their assigned rights to another person on the team. Only a central admin can assign or change a user role in the system.
Why do role-based rules fail during live database sessions?
Role rules only check who can log in and which tables they can touch. They do not inspect individual queries or mask emails and card numbers in results.