Dac Database
A dac database uses discretionary rules so object owners decide who reads or writes data. You set this up by creating tables, assigning owners, and granting permissions to roles. Engineering teams often group permissions into shared roles to speed up daily work. Over time, these shared roles grow too broad and expose private tables to everyone. When one developer account gets compromised, an attacker can read or delete critical records. How a dac database manages permissions In a dac database
Database Access Proxy: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A dac database uses discretionary rules so object owners decide who reads or writes data. You set this up by creating tables, assigning owners, and granting permissions to roles. Engineering teams often group permissions into shared roles to speed up daily work. Over time, these shared roles grow too broad and expose private tables to everyone. When one developer account gets compromised, an attacker can read or delete critical records.
How a dac database manages permissions
In a dac database, every table, view, or schema has a clear owner. The account that creates an object becomes its owner by default. That owner holds full control over the data inside that specific object. Owners can pass specific read or write privileges to other users or group roles. Most engines like PostgreSQL and MySQL use this discretionary model as their baseline.
To keep setup simple, database admins group users into job roles like analyst or engineer. Admins then grant table permissions to the group role instead of individual accounts. When a new developer joins the team, the admin adds them to the group. The developer logs in and inherits every permission attached to that shared role.
Some setups also allow owners to pass along grant rights to other users. When a user gets grant rights, they can share access with third parties on their own. This makes sharing fast for small teams that build new features every day. Still, central security teams soon lose track of who holds rights to which tables.
Why native ownership rules fall short in production
Native discretionary controls solve basic permission grouping for static apps and small teams. They verify who logs in and check basic table rights before a query runs. Still, native controls do not inspect what individual queries do while in flight. Once a user holds read rights on a table, they can pull every column by default.
A single query can return thousands of customer emails, phone numbers, and card numbers. Native database grants cannot rewrite matched fields in results without complex custom views. Maintaining extra views for every table and role creates heavy toil for admins. Teams often skip view creation and give developers raw read rights on production tables.
Database Access Proxy: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Broad write roles create another serious risk during live incidents and routine maintenance. An engineer who needs to fix one row often gets full table update rights. One bad query without a filter can wipe out thousands of production rows. Native permissions only check if the role can run an update on that table.
Closing the gap in discretionary setups
To reduce risk without breaking apps, teams must control queries at the statement level. Instead of handing out permanent write roles, teams should require approval for risky statements. Reviewing specific updates before they run stops accidental drops and bad table alters. Admins also need clear audit logs tied to an individual user identity.
Shared database roles hide which person actually ran a specific query during an incident. Tying every query back to a single login makes security audits fast and clear. Adding field masking also rewrites emails and national IDs in query results on the fly. This lets developers debug live issues while keeping sensitive customer columns safe from exposure.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does DAC stand for in database security?
DAC stands for Discretionary Access Control in standard database security models. It means the owner of a table or view decides who gets permissions.
How is a dac database different from mandatory control?
In a dac database, object owners can grant permissions to other users freely. Mandatory systems use central security labels that individual object owners cannot change.
Why do discretionary permissions cause privilege creep?
Admins rarely remove old table grants when engineers change teams or finish projects. Over months, shared roles collect excess read and write rights across the whole system.