At 6:40 on a Friday evening, your secret scanner flags an API key committed to a public GitHub repository. The key belongs to inventory-sync, a service that reconciles stock levels between your warehouse system and your e-commerce platform. Rotating the key takes your on-call engineer four minutes. Answering the next question takes the rest of the weekend: what could someone holding that key have reached during the nine hours it sat in public? The service account behind it turns out to carry read-write access to four production databases, plus a grant to the payments API that a contractor added during an integration project two years ago. The contractor is gone. The engineer who built the service moved to another team. Nobody can say which of those permissions inventory-sync still uses.
That weekend reveals a gap that most identity programs carry without knowing it. Your team found the leaked secret fast and rotated it fast, which means the credential side of your non-human identity management program works. What failed was control over what the identity could do once someone held the credential. The service had broad, static grants assigned years earlier, and no system evaluated whether any given call made sense at the moment it happened.
Machine access control fills that gap by deciding, for each request a service, workload, script, or agent makes, whether that specific identity should take that specific action on that specific resource right now. It sits on top of the inventory, vaulting, and rotation work your non-human identities (NHIs) program already does, and it changes the answer to the Friday night question from “everything the role allowed” to “whatever policy permitted, which you can look up in a decision log.”
Why machine identities outgrow controls built for people
Gartner puts the ratio of machine identities to human identities at 82 to 1. Those identities include service accounts, API keys, OAuth clients, workload identities in Kubernetes, CI/CD pipeline tokens, RPA bots, and a fast-growing population of AI agents. Each one authenticates to something and holds permissions to act, often against your most sensitive systems.
Human identity controls rest on assumptions that machines break. A person joins through HR, gets provisioned by role, signs in with MFA, and gets deprovisioned when they leave. A machine identity gets created by a developer in a Terraform file or a pipeline script, authenticates with a long-lived secret or certificate, and has no HR record to trigger offboarding. Machines can’t respond to an MFA prompt, so the strongest login control you have for people doesn’t apply. Nobody runs a quarterly access certification for the 14,000 service accounts in your cloud estate with any rigor, because no reviewer can judge whether a service named svc-recon-07 needs write access to a ledger table.
Permissions drift as a result. A developer grants a broad role so the service works on the first deploy and moves on to the next ticket. Over time, integrations pile new grants onto existing accounts, and none get removed, because removing a permission from a production service risks an outage at 3 a.m. You end up with thousands of identities holding standing access that nobody can explain, and an attacker who steals one credential inherits the full set.
What non-human identity management covers, and where it stops
The non-human identities (NHIs) management category has matured quickly, and the core disciplines are well defined. You discover machine identities across cloud providers, SaaS platforms, and code repositories. You vault secrets instead of hardcoding them, rotate credentials on a schedule, assign each identity a human owner, and decommission identities that go dormant. Posture tools layer on top, flagging over-privileged accounts, stale keys, and risky configurations. PlainID’s overview of what posture management tools can see covers how that visibility layer works.
All of that work answers questions about the credential. You learn which identities exist, whether their secrets are healthy, who owns them, and which ones look risky. None of it answers the question your incident responder faced on Friday night: whether a given call from inventory-sync to the payments API should succeed at the moment it arrives. A posture tool can tell you the payments grant looks excessive. Removing it still requires an engineer to edit a role in the payments system, test the change, and hope nothing else depended on it, so the finding sits in a backlog for months.
Non-human identity security needs both halves. Management keeps credentials discoverable, owned, and rotated. Authorization decides what each identity can do with them, evaluates each request, and records the reason. Enterprises that invest only in the first half end up with an excellent inventory of identities that still hold standing access to everything.
Machine access control starts with identity context
You can’t write a sensible policy for svc-recon-07 if all your authorization layer knows is its name. Each machine identity needs attributes that policy can evaluate: the owning team, the application it belongs to, its environment (production, staging, development), the data classifications it’s approved to touch, and its business function. Much of this data already lives somewhere in your stack, in your cloud tags, your CMDB, your IdP, or the workload identity framework your platform team runs. Your authorization layer needs to read it at decision time.
Calling chains matter as much as the identity itself. A large share of machine traffic happens on behalf of a person. A customer opens a mobile app, the app calls an API gateway, the gateway calls an orders service, and the orders service queries a database. If the orders service decides access using only its own service account, every customer request gets the service’s full permissions, and one customer can reach another customer’s orders through a crafted request. Propagating the end user’s identity through the chain, usually through enriched tokens, lets each hop make a decision that accounts for both the service and the person it serves. PlainID makes this case in its piece on authorization for machines and agents, where delegated access becomes the default pattern.
Some machine traffic has no human behind it. A nightly reconciliation job or a fraud-scoring service acts on its own authority, and your policies should handle that case directly, with rules scoped to the job’s function and schedule. A reconciliation job that suddenly queries customer contact data at noon on a Tuesday falls outside both, and a policy that knows the job’s attributes can deny the request even though the credential is valid.
Replace static roles with policies evaluated per request
The machine identities in your environment hold permissions that someone decided once and nobody revisits. Fixing that requires a different model, and the middle of this problem is where most programs stall. Discovery and secrets hygiene leave you with an accurate list of identities still carrying standing grants. The work that changes your risk posture comes next: externalizing authorization into policy, enforcing it where machines reach data, and shrinking standing access without breaking production.
Role-based access control struggles with machines for a structural reason. Roles bundle permissions for a job function, and services don’t have job functions in the way people do. Each service touches its own mix of APIs and tables, so you either create a role per service, which multiplies into thousands of roles nobody can audit, or you share broad roles across services, which over-provisions all of them. Comparing RBAC, ABAC, ReBAC, and PBAC side by side shows why policy-based models scale better here.
Policy-based access control writes rules that combine identity attributes, resource attributes, and context. Your policy might say that production services owned by the payments team can write to tables classified as payment data, only from the production environment, and only for transactions tied to the customer in the propagated token. One rule covers every current payments service and every one your team builds next quarter, since new services inherit it through their attributes instead of through a hand-assigned role. A service tagged for the inventory domain matches no payment-data rule, so the contractor’s two-year-old grant to the payments API stops mattering once the policy layer governs that API.
Externalized policy also changes who can fix things. Access logic that lives inside each service’s code requires a developer and a release to change. Policy managed centrally can be reviewed by security architects, read by auditors, and changed without touching application code. These are decisions made at request time, so a policy change takes effect on the next call instead of the next deploy.
Enforce where machines reach data
Policy only matters at the point where a request meets a resource, and machine traffic reaches resources through a few predictable layers. API gateways handle north-south traffic between clients and services, so gateway enforcement can evaluate each call against policy before it reaches a backend. PlainID’s guide to locking down APIs with dynamic authorization walks through the gateway patterns.
Service-to-service traffic inside your environment usually flows through a service mesh. Sidecar proxies such as Envoy sit beside each workload, which gives you a natural place to check whether the orders service may call the refunds service with these parameters for this customer. Running enforcement inside an Istio mesh means your platform team adds authorization without modifying service code.
The data layer needs controls of its own. A service with a legitimate reason to query the customer table still shouldn’t see every row and column. Row and column filters applied in the query path let the analytics service read aggregated purchase data while masking contact details, and let a regional service see only customers in its region. Fine grained controls at the data layer close the gap that API-level enforcement leaves open, since a service that clears the gateway can otherwise read anything its database credential allows.
Consistency across these layers matters more than any single enforcement point. If your gateway, mesh, and database each run their own rule engine with their own policy language, you’re back to scattered logic that nobody can audit. A single policy layer with distributed enforcement keeps the rules in one place while the checks happen wherever the traffic flows.
Shrink standing access without breaking production
Zero standing privileges for machines means a service holds no broad persistent grant. Its credential proves who it is, and a policy decision at runtime determines what each request may do. Short-lived tokens help, and many platform teams already issue them through workload identity frameworks. Token lifetime alone doesn’t solve the problem, though. A token that lives for fifteen minutes but carries full read-write on four databases still gives an attacker fifteen minutes of unrestricted access.
The fear that stops most teams is breaking production. A payments service that gets denied a legitimate call at month-end close causes an incident, and nobody wants to be the person who caused it. Reduce that risk by running new policies alongside existing grants first. Log what the policy would have decided for each request, compare those decisions against actual traffic for a few weeks, and adjust rules where they would have blocked legitimate calls. Once the would-deny count for real traffic reaches zero, switch the policy to enforcing and remove the old broad grant. You end the exercise knowing which permissions inventory-sync uses, a question nobody could answer on that Friday night.
Break-glass access still has a place. Incidents happen, and an operator sometimes needs a service to do something unusual. Write that path into policy with tight conditions, an approver, and a short expiry, so emergency access shows up in your decision records instead of happening through a manual role edit nobody remembers to revert. PlainID covers how this fits into a broader architecture in its piece on the authorization layer Zero Trust needs.
Prove control when an auditor or incident responder asks
Return to the leaked key. With runtime authorization in place, your responder opens the decision records for inventory-sync and filters to the nine-hour exposure window. Every call the credential made appears with the resource requested, the policy evaluated, and the result. Calls from the expected warehouse integration show as permitted under the inventory policy. Any call to the payments API shows as denied, because no policy grants inventory-domain services access to payment data. The responder can tell the CISO what the credential could have reached and what it did reach, with evidence, before the weekend starts.
Auditors ask the same kinds of questions on a slower clock. They want to know which machine identities can reach regulated data, who approved that access, and whether each access followed an approved policy. Decision records that capture the identity, its attributes, the calling chain, the policy version, and the outcome answer those questions directly. A relationship view that connects identities to applications, APIs, and data lets you answer chain questions too, such as every service that can reach cardholder data through any path. Tools focused on mapping which identities reach which resources give you that view before an auditor asks for it.
Explainability matters here. “Denied: service inventory-sync, domain Inventory, not authorized for resource category Payment Data under policy PAY-002 v5” reads as an audit answer. A raw dump of evaluated attributes needs an engineer to interpret it, and auditors notice the difference.
Where AI agents fit in the machine identity picture
AI agents are machine identities with an unusual property: their behavior changes with each prompt. A conventional service calls the same APIs in the same order every time, which makes its access pattern predictable even when its permissions are too broad. An agent decides at runtime which tools to call and which data to retrieve, so the gap between what it can do and what it does on any given request grows wider.
The controls in this guide apply to agents, with extra requirements layered on top. Agents need composite identity evaluation that binds the agent to the human it acts for. They also need enforcement at the prompt, retrieval, tool call, and output stages of their workflow. Running agents and services through the same policy layer keeps one set of rules for data categories across your entire machine estate. PlainID goes deeper on the agent side of this problem in a dedicated guide.
How PlainID controls machine access
PlainID is a Runtime Authorization Platform that governs human identities, non-human identities, and AI agents under one policy layer. It extends the non-human identities (NHIs) management and IAM tools you already run instead of replacing them. PlainID consumes identity data from Entra ID, Okta, Ping Identity, and your other identity sources, and integrates with governance platforms, including working alongside SailPoint governance, so the attributes those tools maintain feed every authorization decision.
Policies live in PlainID’s centralized policy management layer, written in plain language or as code, versioned, and evaluated with policy-based access control across identity, resource, and context attributes. Enforcement runs through pre-built Authorizers at the points where machines reach resources. These include API gateways such as Apigee, Kong, AWS API Gateway, and Azure API Management, service mesh and proxy layers such as Envoy and Istio, and data platforms including Snowflake, Databricks, Google BigQuery, and SQL databases, with row and column level controls. Token enrichment carries delegated user context through service chains. Decisions return in milliseconds, and policy changes reach every enforcement point in under 60 seconds without a development cycle.
For audit and incident response, PlainID’s Authorization Graph maps identities to applications, APIs, agents, tools, and data as a relational graph of access decisions, and it explains each decision in business language. PlainID is recognized as KuppingerCole’s leader in policy based access, holding both Product Leader and Market Leader positions, and appears in multiple Gartner reports covering authorization management and IAM for agents. The platform secures over 35 million identities, processes billions of authorization decisions daily, and runs under a 99.99% uptime SLA for Fortune 500 customers in financial services and other regulated industries. PlainID’s coverage by identity type shows how the same platform handles each segment.
A rollout sequence for machine access control
Start with the machine identities that touch your most sensitive data. Payment services, services reading customer PII, and pipelines that write to financial ledgers carry the highest blast radius when a credential leaks, and auditors ask about them first. Pull their attributes from your non-human identities (NHIs) inventory, map their calling chains, and write category-based policies for the data they reach. Run those policies in parallel with existing grants, compare decisions against real traffic, and switch to enforcement once the comparison comes back clean.
Expand by data category after that. Once your payment-data policies exist, any new service that touches payment data inherits them through its attributes, and your platform team stops hand-crafting roles for each deployment. Move enforcement outward through the gateway, the mesh, and the data layer as each category comes under policy. Bring agents onto the same policy layer as your teams deploy them, so data categories keep one set of rules regardless of what kind of machine is asking. PlainID’s guide to building an authorization roadmap in stages offers a sequencing model your architects can adapt.
Measure progress by the question from that Friday night. Pick a machine identity at random each month and time how long your team takes to state what it can reach, what it reached last week, and which policy allowed each access. The first time you run the exercise, the answer may take days. Once machine access runs through runtime authorization, the same answer comes from one query against the decision records, and the payments grant nobody could explain no longer exists.
