Non Human Id
A non human id is a machine account that lets scripts and apps log in. You set it up by creating a service role and assigning scoped permissions. Most teams start by creating one shared key for their build pipelines or bots. They often attach broad admin roles so the automated job does not fail. When permissions are too wide, a leaked key exposes every database and server. How to set up a non human id in your system Every cloud host and database lets you create accounts for machines and scrip
Non-Human Identity Management + Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A non human id is a machine account that lets scripts and apps log in. You set it up by creating a service role and assigning scoped permissions. Most teams start by creating one shared key for their build pipelines or bots. They often attach broad admin roles so the automated job does not fail. When permissions are too wide, a leaked key exposes every database and server.
How to set up a non human id in your system
Every cloud host and database lets you create accounts for machines and scripts. First, you register a new service account in your central identity tool. This step gives the machine a unique name and a distinct record. Next, you pick how the app will log in to the target system. Workload tokens work best because they expire after a very short time. Static keys are common for older tools, though they carry much higher risk.
After you pick the login method, you build a role for the machine. Good roles list the exact tables, buckets, or endpoints the app needs. You should split read jobs and write jobs into two separate machine accounts. Then you bind the role to the account and test the job run. Finally, you turn on audit logs to track when the machine logs in. Teams also set an owner tag so everyone knows who built the bot.
What native roles solve and what they miss
Native identity rules do a great job of checking who can log in. They verify that the script holds a valid token or key at startup. They also block the script from touching servers outside its assigned role group. This setup stops random network traffic from reaching your private data stores. It also gives your security team a basic list of active machine accounts.
Still, native setup rules only check the account at the front door. Once the machine logs in, the target database trusts every command it sends. Native roles cannot inspect individual queries or commands while they run in flight. A compromised build script or AI agent can run a huge table dump. It can also pull sensitive emails, phone numbers, card numbers, or national IDs. Static roles cannot rewrite those fields in query results or pause risky commands. Teams also struggle when five different apps share the exact same service key. When a bad query hits the database, the logs only show the shared key.
Non-Human Identity Management + Microsoft Entra ID (Azure AD): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to keep machine accounts safe over time
Start by finding every active script, bot, and pipeline across your whole stack. Give each app its own account instead of sharing keys across different teams. Swap out long-lived static secrets for short-lived workload tokens wherever your tools allow. If you must use static keys, rotate them on a strict monthly schedule. Delete old accounts right away when a team retires an app or service. Check your query and command logs every week to spot strange machine behavior. Set up real-time alerts for spikes in data reads or failed login attempts.
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 is the difference between a user account and a non human id?
A user account belongs to a single person who logs in with a password. A machine account belongs to an app, script, or bot that runs code. Machine accounts do not use standard multi-factor prompts during their daily job runs.
Why do machine accounts create so much security risk?
Teams often give bots wide admin permissions so automated tasks never break. Engineers also forget to rotate machine keys or delete old accounts after projects end. If an attacker steals an unmonitored key, they gain quiet access for months.
How often should teams review their machine permissions?
Teams should check all active machine roles at least once every ninety days. Compare the permissions assigned to the role against the actual logs of recent runs. Drop any write or admin rights that the app no longer uses.