Agdlp Model
You set up the agdlp model by putting user accounts into global groups first. Next, you nest those global groups inside domain local groups that hold resource permissions. Many teams skip these steps and give rights straight to single users. That shortcut creates messy rules that are hard to check or fix later. Over time, people switch jobs and keep old keys they do not need. Broad permissions let one bad script break a whole server or database. How the agdlp model works in practice The lette
Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up the agdlp model by putting user accounts into global groups first. Next, you nest those global groups inside domain local groups that hold resource permissions. Many teams skip these steps and give rights straight to single users. That shortcut creates messy rules that are hard to check or fix later. Over time, people switch jobs and keep old keys they do not need. Broad permissions let one bad script break a whole server or database.
How the agdlp model works in practice
The letters stand for Accounts, Global, Domain Local, and Permissions. Each step separates who a person is from what they can do. First, you create an account for each person or app on your team. Then you put accounts with the same job into a global group. For example, all backend coders go into one global group. This group reflects their team role, not the servers they touch.
Next, you make a domain local group for a specific task or resource. One domain local group might allow read rights on a sales database. Another domain local group might allow write rights on a file share. You grant the actual permissions only to these domain local groups. Finally, you put the global group inside the right domain local group. When a new coder joins, you add them to the global group once. They get all the right permissions right away without extra setup steps.
Naming rules that keep group setup clean
Good names make the agdlp model easy to read during a security check. Start global group names with a tag that shows the team or job. Start domain local group names with the resource name and the allowed action. This habit stops admins from mixing up job groups and permission groups. It also makes audits go much faster when you review who touches what.
Never put user accounts straight into a domain local group. Never put permissions straight onto a global group either. Stick to the four steps even when a quick fix feels tempting. Clean layers mean you can remove one person from a team in seconds.
Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory groups solve and what they miss
This group structure solves the problem of messy user lists on every server. Admins do not have to edit twenty servers when someone leaves the company. They just remove the user account from the global group in one place. It also keeps permission lists short and easy to read on each target system.
Still, directory groups only decide who can log in and open a session. They do not inspect what happens after the session starts. A user with read rights can still pull thousands of customer phone numbers. A user with write rights can still run a bad query that drops tables. Static groups also grant standing rights that stay active all day and night. If an attacker steals an account key, they get every group permission right away. Directory groups cannot mask emails or card numbers inside query results either. To control single commands and protect sensitive fields, teams need runtime checks on live sessions.
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
What does each letter in the agdlp model mean?
A is for user accounts, and G is for global job groups. DL stands for domain local groups, and P stands for resource permissions. Together, they form a chain from the user to the resource.
Why should you avoid giving permissions straight to global groups?
Giving permissions to global groups ties a job title to specific servers. When you add new servers, you have to rebuild your group rules. Keeping permissions on domain local groups lets you swap resources with less work.
Does the agdlp model stop bad queries inside a database?
No, directory groups only control who can log in to the system. Once a user logs in, the group model cannot check single SQL queries. It also cannot rewrite sensitive fields like national IDs in the output.