Manual Account Management
You handle manual account management by creating local users and roles on each system. Admins then assign permissions to those accounts by hand for every request. Most teams start with a ticket queue where engineers ask for database or server credentials. Admins log in to the target system and grant a role to that user. When teams rush, they often grant broad roles that stay active forever. How manual account management works in practice In a manual setup, every database or server keeps its o
Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You handle manual account management by creating local users and roles on each system. Admins then assign permissions to those accounts by hand for every request. Most teams start with a ticket queue where engineers ask for database or server credentials. Admins log in to the target system and grant a role to that user. When teams rush, they often grant broad roles that stay active forever.
How manual account management works in practice
In a manual setup, every database or server keeps its own list of users. When a new developer joins the team, they need credentials for these systems. They file a ticket with the ops team to get a login account. An admin reads the ticket and checks if a manager said yes. Next, the admin logs into the database or server console as a superuser. They create a new local account and set up a password or public key. Then they attach a role that defines what the user can read or write. The admin sends the login details back to the developer through a chat or vault. The developer puts those credentials into their local client app and logs in. When the developer changes teams or leaves, an admin must delete the account by hand. The admin also has to check every system to remove old keys and passwords. This cycle repeats for every database, server, and internal tool the company runs.
What native roles solve and where they fall short
Native roles let a database or server check who is logging in at the start. They also let the system block a user from reading whole tables or folders. This setup works well when you only have a few systems and stable teams. Still, manual provisioning creates big gaps as your team and system count grow. First, admins often copy existing broad roles instead of writing tight rules for one task. Second, nobody remembers to remove access after a bug fix or incident ends. Accounts pile up across servers with write permissions that nobody needs anymore. Most of all, static roles only decide who can open a session at login time. They do not inspect what individual queries or commands do while the session runs. A user with read access can still pull a whole table of customer emails. A user with write access can drop rows by mistake without a second check. Static roles also leave you with scattered logs that do not show clear user names. When five engineers share one admin account, the system log cannot tell them apart.
Steps to reduce risk in manual workflows
If you still manage accounts by hand, start by cutting down shared admin logins. Give each person a named account so the system log shows who ran what. Group permissions into small roles based on common tasks like reading logs or fixing data. Write down a strict schedule to check active accounts at the end of each month. Delete any account that has not logged in during the past thirty days. Require a ticket number for every permission change so auditors can track the reason. Move away from permanent write roles and set an end date for every upgrade. Even with these habits, manual checks take hours of admin time every week. Teams also need controls that work inside the session, where commands and queries run. For sensitive fields like phone numbers or card numbers, masking rewrites matched fields in results.
Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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
Why do teams still use manual account management?
Small teams use it because built-in database and server users need no extra tools. It only becomes slow and risky when the number of engineers and servers grows.
What is the biggest risk of managing accounts by hand?
Forgotten accounts and overly broad roles are the biggest risks in a manual setup. Old logins stay active with write access long after a task or project ends.
How can we track what users do after they log in?
Native account tools only check logins and do not track every query well. You need command-level logging to see the exact statements each engineer runs in a session.