How to approach machine identity management for AI agents

Most identity programs were built around people. Joiners get accounts, movers get their access adjusted, leavers get disabled, and someone signs off on the access review each quarter. Machine identities now far outnumber them. CyberArk’s 2025 Identity Security Landscape found 82 machine identities for every human one, silently piling up across tenants and outliving the projects that created them.

AI agents are now landing on top of that foundation, and many of them authenticate the easiest way available, like a shared service account or a technician’s own credentials. That becomes a real problem the moment an agent can take action, because whatever identity it borrows defines the limit of what it can do. The fix is giving every agent its own verifiable machine identity, with scoped permissions, short-lived credentials, and a lifecycle someone actually owns.

Why AI agents inherit the machine identity problem

AI agents often don’t arrive in a clean environment. Instead, they get deployed into tenants that already contain years of service accounts, app registrations, API keys, and scheduled scripts, many of which nobody has looked at since they were created.

An 82:1 ratio of machine to human identities doesn’t mean 82 tidy service accounts for every employee. The machine side is spread across:

• Service principals
• Managed identities
• Application registrations
• Certificates
• API credentials
• CI/CD pipelines
• Integrations
• Automation scripts
• Bots
• AI agents

Most were created because a workload needed to authenticate at a specific point in its life, but many of them weren’t retired when that need ended.

That makes machine identities much harder to govern than human ones. A workforce has joiner, mover, and leaver processes, and HR tells IT when someone leaves. Machine identities can be created automatically, copied between environments, embedded in code, and owned by a team rather than a person. When the team reorganizes or the project ends, the identity often stays exactly where it was, with the same permissions it had on day one.

» Here are the differences between automation and Autonomous IT

How orphaned credentials outlive the systems they served

The most dangerous machine identities are often the ones attached to something that no longer exists. According to Dominique Locksley, Linux System Administrator at Adapt IT Holdings Limited:

That script connected directly to a banking system over SFTP to deposit financial transaction files and collect the responses. Since the credentials were hardcoded in the script, anyone who got hold of them could have authenticated to the bank with a legitimate, trusted identity and accessed sensitive financial data. The application might have disappeared, but the authentication path was still there.

Why AI agents raise the stakes

AI agents add to this problem in two ways:

First, they multiply the number of non-human identities, and they tend to be spun up quickly by teams trying to prove value. Under that pressure, the easiest authentication path wins.

Second, agents act. A script runs the same commands every time, but an agent interprets a request and decides what to do with whatever access it has. When that access comes from a shared or human identity, several things break at once:

• Attribution: Actions can’t be traced to a specific agent when several workloads authenticate as the same account.
• Least privilege: Permissions can’t be reduced for one agent without breaking every other workload that shares the identity.
• Revocation: Retiring the agent doesn’t retire the credential.

What machine identity management looks like for AI agents

Good machine identity management for AI agents comes down to a few principles applied consistently. Every agent is a distinct, accountable identity. It authenticates without a reusable secret. And it holds elevated authority only as long as a task needs it.

The foundation is separation. Every AI agent should have its own machine identity, never a shared service account, a developer’s credentials, or an identity borrowed from another workload. That identity needs four things recorded against it:

• A documented owner
• A clear purpose
• Permissions scoped to the resources the agent actually needs
• A lifecycle that ends when the agent is retired

Everything else depends on this. Infrastructure monitoring, auditing, credential rotation, and least privilege all assume that one identity maps to one workload. When several agents operate behind the same account, each of those controls is weakened at the source.

» Here’s how to find out if AI agents are actually autonomous

How short-lived credentials replace static secrets

A dedicated identity still fails if it authenticates with a static API key or client secret. That secret can be copied into a config file, a pipeline variable, or a script, and it stays valid wherever it ends up.

Workload identity federation removes the stored secret entirely. In Microsoft Entra, a federated identity credential establishes trust between the agent’s identity and the platform where it runs, based on token claims such as issuer, subject, and audience. When the agent needs access, its runtime presents a signed token from that trusted platform, and Entra exchanges it for an access token only if the claims match the configured trust.

The resulting token is temporary.  By default, Entra access tokens last roughly an hour, so the agent has to prove its identity again soon after. Nothing reusable lives in source code or the software deployment pipeline. The security model shifts from protecting a secret to verifying the workload every time it needs credentials.

Warning: Removing the federation trust stops the agent from obtaining new tokens, but it doesn’t automatically invalidate tokens already issued. Those can remain usable until they expire, so revocation and token lifetime are two separate controls.

Why short-lived tokens aren’t the same as least privilege

A token that expires after an hour doesn’t limit what the agent can do during that hour. If the underlying identity permanently holds a privileged role, every fresh token carries that privilege with it. Short-lived credentials make authentication temporary, so the agent’s authority needs to be temporary and narrow too. In practice, that looks like this:

• Standing permissions stay minimal: The agent’s everyday identity holds only what its routine tasks require, never a high-privilege role kept just in case.
• Elevation is granted per task, for a set window: Service principals can’t hold eligible PIM roles and activate them the way human admins do. Agent JIT runs through an external approval or authorization process that grants a time-bound active assignment, which expires on its own.
• Attributes narrow the scope further: Azure role assignment conditions restrict permitted actions based on attributes of the identity, resource, or request, and AWS IAM offers comparable condition keys and tag-based policies.
• Permission changes are tied to specific operations: When a least-privilege policy blocks a legitimate task, the fix is the exact operation that failed, not a broader role that makes the error go away.

According to Locksley:

This limited which API actions the role could call, not which SSM documents or instances it could target. That’s a real improvement over AdministratorAccess, but it isn’t full least privilege. Where a resource boundary is still wider than intended, it should be recorded as remaining hardening work.

How to build machine identity management into IT operations

Knowing what good looks like doesn’t fix the identities already in your tenants. Getting there takes three pieces of ongoing work: an audit, a cleanup process, and a standard that every AI agent has to meet.

Each of the three matters more once agents are involved, because an agent that borrows an unmanaged identity inherits every weakness described above.

Here’s how:

Audit non-human identities from both directions

An identity provider can tell you what identities exist, but not everything those identities are used for. A reliable audit works from the IdP outward and from the infrastructure back. Follow these steps:

1. Inventory every non-human identity in your IdP: In Entra ID, that means service principals, managed identities, app registrations, and user accounts being used as service accounts. In Okta, include service apps, API service integrations, API tokens, and any accounts running unattended processes. Flag every identity an AI agent uses, and note whether it is dedicated to that agent or shared.
2. Record the context for each identity: Capture its owner, purpose, authentication method, assigned permissions, credential age or expiry, and last observed activity.
3. Review sign-in and audit logs: Look for identities that should be inactive but keep authenticating, unexpected source locations or target resources, privilege changes, and activity that doesn’t match the documented purpose. Entra keeps service principal sign-ins separate from user sign-ins, which makes this easier to isolate.
4. Audit from the infrastructure back toward the IdP: Check scheduled tasks, services, automation platforms, CI/CD pipelines, scripts, configuration files, secret stores, application servers, and legacy shares for credentials and account references. In Atera, Network Discovery’s scheduled scans can surface devices missing from your inventory. You can then deploy scripts remotely across devices or device groups to list scheduled tasks and services running under non-default accounts, and AI Copilot can generate that script from a plain-language description.
5. Reconcile the two lists: Every mismatch is either an identity nobody is tracking or a tracked identity that nothing legitimately uses anymore.

Automated discovery tools handle the first three steps well, but they can’t establish operational context. These are the blind spots that need manual verification:

• Dormant accounts with live credentials: An account can look unused while its password sits embedded in an old script, waiting for the next scheduled run.
• Misleading names: An account named after a former employee may actually be running a production service.
• Orphaned service principals: A valid service principal can survive long after the application it was created for has been decommissioned.

For each identity, manual verification has to confirm the technical or business owner, the workload actually consuming it, the resources it can reach, and what breaks if it’s disabled. An identity is only fully accounted for when all of those can be connected.

» Looking to automate? Don’t miss this AI agent stack

Clean up high-risk identities without breaking production

Not every stale identity carries the same risk, so start with the ones that could do the most damage. Prioritize identities holding broad application permissions such as:

• Mail.*
• Directory.*
• Privileged Entra roles
• Azure RBAC assignments

Pay particular attention to EWS.AccessAsUser.All and full_access_as_app , and remember that no recent sign-ins doesn’t make a privileged identity harmless. For dormant identities, check for:

• Active secrets or certificates
• Recently added credentials
• Historic OAuth consent grants
• Changes in ownership
• Role or permission assignments that could make the identity useful to an attacker again

Deleting everything that looks stale is how cleanups cause outages. Instead, follow this controlled sequence:

1. Remove permissions the identity no longer needs
2. Revoke unused secrets and certificates
3. Disable the identity where practical
4. Monitor for failures. Anything that breaks points to a dependency your audit missed
5. Delete the identity once dependencies and ownership are resolved

Where access is still legitimate, reduce it to the minimum required scope and replace long-lived credentials with short-lived ones wherever the platform supports it.

Pro tip: Before trusting the inventory, review the audit history for application creation, credential changes, consent grants, and role assignments that happened outside your normal processes. The inventory is only complete when both sides agree. Every identity maps to a workload and an owner, and every workload that authenticates maps back to a known identity.

Hold every AI agent to the same identity boundaries

The same discipline applies to AI agents you adopt from vendors, not just the ones you build. The first question to ask about any AI IT agent is whose authority it uses when it acts. An agent should never decide for itself who a user is or what that user is allowed to do. Authentication and authorization belong to your existing identity control plane, and the agent’s interpretation of a request should never become an authorization mechanism.

When evaluating an agent, look for clear answers to these questions:

• Requester verification: Does the agent verify the requesting user before it changes anything?
• Respect for identity changes: Does it immediately honor disabled accounts and role changes made in the IdP?
• Privilege separation: Can privileged actions require additional verification or human approval?
• Attribution: Can every action be traced to both the requesting identity and the agent that executed it?
• Scoping: Can permissions be restricted by user, group, action, site, or resource?
• Auditability: Can the full decision and execution trail be exported for investigation?

Here is how Robin by Atera approaches them. Robin is an AI technician that remediates Tier-1 and complex Tier-2 technical incidents end to end by autonomously taking real actions on devices, servers, mainframes, and networks, without needing a technician in the loop. Because it acts, it needs to sit inside your identity boundaries, and several of these controls are built in.

Every request starts with smart intake, which verifies the user before anything changes: Robin can answer questions and read device state, but it can’t run a self-service action or install software until the user completes two-factor verification.

Robin acts autonomously, within your rules: pre-approved software, scripts an admin has explicitly enabled for it, and Cloud Actions that connect it to approved third-party tools through their APIs. Where a decision needs a person, Playbooks help you build approvals into the workflow.

Identity is the boundary for every AI agent

The forgotten identity in this post had a problem common to most of them: nobody owned it once its original job changed. AI agents raise the stakes because they actually act, so giving each agent its own identity, short-lived credentials, time-bound elevation, and a lifecycle that ends when the agent does turns machine identity management from a cleanup exercise into a design decision.

The same standard applies to the AI agents you bring in from vendors. Robin is built to work inside your identity boundaries rather than around them. Its actions stay aligned with the roles and permissions in Entra ID, Okta, or Google Workspace, resolutions are logged, and escalations carry full context. Autonomy grows as Robin proves itself in your environment.

» Ready to run your own audit? You can try Atera for free