Types of Access for Non-human Identities
You manage the types of access for non human identities by assigning scoped roles and keys to apps. These machine identities use API tokens, certificates, or workload roles to log in and run tasks. Most teams start by creating a single service account for a whole backend job. When that role has broad permissions, one leaked key puts every database and server at risk. Core types of access for non human identities Machine accounts outnumber human users in almost every cloud setup today. Scripts
Non-Human Identity Management + DPoP (Demonstration of Proof-of-Possession): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You manage the types of access for non human identities by assigning scoped roles and keys to apps. These machine identities use API tokens, certificates, or workload roles to log in and run tasks. Most teams start by creating a single service account for a whole backend job. When that role has broad permissions, one leaked key puts every database and server at risk.
Core types of access for non human identities
Machine accounts outnumber human users in almost every cloud setup today. Scripts, containers, pipelines, and automated bots all need ways to log in and do work. Teams group these machine permissions into four main models based on how the app runs.
First, static keys and API tokens let external scripts log in to databases or cloud services. The team creates a secret string and puts it in an app file. The app sends that secret string each time it wants to read or write data.
Second, service accounts bind a named machine user to a set of cloud or database roles. A build tool or background worker logs in as that service account to run jobs. Admins attach read, write, or admin rules to the account in the central directory.
Third, workload federation links a running container or server to a cloud role without saved keys. The platform checks the container identity and trades a local token for a short cloud session. This stops teams from leaving static passwords inside code repos or build servers.
Fourth, mutual TLS certificates prove identity between two internal apps during network traffic. Both the client app and the server check each other's digital certificate before sharing data. This model works well for service-to-service traffic inside a private cluster.
How native machine role setup works
To set up a non-human identity, an admin first defines a machine profile in the identity provider. Next, the admin builds a role policy that lists the allowed targets and actions. For a database job, the policy might allow read queries on one schema.
After creating the role, the team links it to the app or server. If the app runs in the cloud, the team binds the role to the compute instance. If the app runs outside the cloud, the team stores a key in a secret store.
Non-Human Identity Management + DPoP (Demonstration of Proof-of-Possession): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When the app starts, it fetches its key or token and opens a session to the target. The target system checks the token against the directory rules before letting the app in. Once the check passes, the app can send queries or commands over that open session.
Where standard machine permissions fall short
Native roles and keys do a good job of checking which app is logging in. They also help teams block unknown scripts from reaching private servers and data stores. Still, directory roles only check permissions at the moment the session starts.
Once a service account logs in, the native role cannot inspect individual queries or commands in flight. A reporting bot with read access to a customer table can pull every row at once. Native permissions cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs in results.
Static service roles also struggle when automated agents or shared pipelines run actions for different teams. Every query in the database log shows the same shared service account name. When a bad query breaks a table, the team cannot tell which job or trigger sent it.
Rotation is another pain point when apps rely on long-lived keys or database passwords. If an admin changes a key to fix a leak, running apps often crash right away. Teams end up keeping old keys active for months just to avoid breaking production jobs.
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 service account and a human user account?
A human account belongs to one person who logs in with a password and multi-factor check. A service account belongs to an app, script, or bot that logs in with tokens or keys.
Why are static keys risky for machine accounts?
Static keys do not expire on their own and often end up copied into code or logs. Anyone who finds a leaked key can use the machine role from anywhere until an admin revokes it.
How can teams reduce risk for database service accounts?
Teams should give each app its own narrow role instead of sharing one admin account. They should also check queries in flight and mask sensitive fields like emails or card numbers in results.