As cloud services, automation, APIs and AI agents expand enterprise operations, software is gaining the ability to obtain and exercise authority at machine speed. Here are five factors every technology leader should consider when securing machine actors, with expert commentary from Justin Henkel, CISO at SolarWinds.
The identity population is expanding—and becoming more ephemeral
Cloud services, automation, APIs and AI agents are expanding the population of machine actors in enterprise environments. Some are long-lived service identities; others are short-lived workloads or delegated agents. Technology leaders need to know what exists, why it exists, what authority it holds and how safely it can be created, monitored and retired. That visibility should support proportionate controls throughout each actor’s lifecycle, from creation to retirement and documented recovery.
Justin Henkel, CISO at SolarWinds, says: “The security challenge is not simply that machine identities are multiplying. Software can now obtain and exercise authority at machine speed, across platforms, applications and data stores, often without a person approving each action. That population includes durable service identities, ephemeral workloads, deployment pipelines, third-party integrations and AI agents acting through delegated permissions. Many are created automatically by infrastructure tools or application code, so they may bypass employee-focused identity processes. Leaders need discovery, but inventory alone is not control. Each actor should be linked to a purpose, an accountable owner, an originating workload and a defined set of permissions. The priority is to reduce authority and limit the damage if one identity, credential or agent is compromised. A programme measures not only how many actors exist, but their privilege, reach, credential lifetime, provenance and revocation path. This moves the discussion from identity sprawl to controlled, observable automation across the enterprise.”
Authority, not just identity, determines blast radius
Machine actors often need access to multiple systems to complete an automated process, but broad permissions can turn one compromise into a larger incident. Technology leaders should distinguish authentication from authorisation, apply least privilege and limit access by action, resource, environment and time. They should also review standing administrative rights and remove permissions that are no longer necessary. The goal is safe, purposeful automation, not merely fewer identities in operation.
Justin Henkel, CISO at SolarWinds, says: “Over-privileged machine identities can expand the blast radius of an incident. A deployment account with write access across environments may allow an attacker to alter software, retrieve sensitive data, or create credentials after one secret is compromised. The risk is not determined by the identity label alone; it depends on the authority granted and the trust boundaries that authority can cross. Technology leaders should separate read, write, administrative and identity-management permissions, then constrain each by workload, environment, resource and transaction. Just-in-time elevation can support exceptional tasks without creating permanent privilege. Policy should also account for context, such as an approved release, a deployment pipeline or a production emergency. Continuous monitoring is useful, but detection is not a substitute for prevention. Teams should measure standing privilege, actions, cross-zone access and time to revoke. This produces a view of blast radius and helps security teams focus remediation where it reduces impact most.”
Ownership and provenance must be designed in
Machine identities are created across applications, cloud platforms, pipelines and business units, making ownership difficult to maintain. Some remain active after their original purpose ends, while others are generated too quickly for manual registration. Organisations need discovery, provenance and accountable ownership so they can understand what each actor does, who sponsors it and how it should be retired. That chain should survive reorganisations, platform changes and incident response events too.
Justin Henkel, CISO at SolarWinds, says: “Visibility is necessary, but discovery alone does not establish that a machine actor is legitimate or safe. Ownership should be designed into architecture, procurement, software engineering and deployment workflows. A service, pipeline or AI agent should carry metadata describing its purpose, risk tier, technical custodian, business sponsor, data owner and parent application. Ephemeral workloads can inherit accountability from that parent, rather than receiving an assigned owner for every instance. Provenance should also connect actions to the deployment, source version, environment and policy that authorised them. This evidence makes incident investigation faster and helps distinguish an approved release from an unexpected process using the same platform. Cross-functional ownership matters because security may discover the identity, engineering may operate it, and a product or data owner may accept its business risk. The objective is an accountability chain from design through runtime, suspension and retirement, not simply a larger inventory of machine identities.”
Replace static secrets with verifiable workload identity
Machine actors may use passwords, API keys, certificates, tokens and other credentials to authenticate to enterprise resources. Poor storage, sharing or long lifetimes can give attackers persistent access. Leaders should prefer federation and workload identity where supported, protect remaining secrets centrally, rotate them safely and monitor their use and expiry. Leaders should know where credentials exist, how they are used, who can issue them, and how they can be disabled.
Justin Henkel, CISO at SolarWinds, says: “Hardcoded and long-lived credentials remain recurring attack paths because a stolen secret can provide persistent access without further human verification. Secrets may be exposed in source code, configuration files, build logs, images or shared integration accounts. Centralised vaults help, but storage is only one part of the control. Organisations should prefer federated or workload identities, short-lived tokens and attestation that verifies the workload requesting access. Where static credentials remain necessary, issuance, scope, rotation, revocation and use should be managed together. Rotation must be tested because an expired certificate or failed deployment can create an availability incident and encourage teams to bypass controls. Security teams should also monitor unusual use, such as a credential appearing in a new environment, or accessing resources outside its normal purpose. Identity providers, vaults and policy services are critical dependencies and require recovery plans, emergency access and resilience testing. Expiry should always remain visible to owners.”
Governance must operate at machine speed
Identity governance has traditionally focused on employees and contractors, but machine actors also require accountability across creation, authorisation, monitoring and retirement. The workflow should not copy human processes exactly. It should provide equivalent assurance through automated controls, risk-based human decisions, runtime evidence and reliable revocation. The control objective is the same: prevent inappropriate access, detect misuse quickly, preserve evidence, and recover safely when systems or business conditions change over time.
Justin Henkel, CISO at SolarWinds, says: “Human identity governance cannot simply be copied onto machine actors. Employees have HR events, interactive authentication and periodic reviews; workloads and agents can be created in bulk and act in milliseconds. Human decisions belong at the right control points. People should approve business purpose, risk tolerance, sensitive data access and exceptional authority. Platforms should enforce those decisions programmatically through provisioning policies, workload attestation, tool allowlists, transaction limits, runtime monitoring and automated suspension. AI agents require additional safeguards because an identity can still be directed by malicious content or make an unsafe tool call. High-risk actions should preserve delegated context and require policy checks or human confirmation. Governance should also support safe deprovisioning, evidence retention and break-glass procedures. This creates equivalent accountability without forcing every machine event through a manual workflow. The result is governance that operates at machine speed while keeping humans responsible for purpose, authority, risk acceptance and recovery.”
Conclusion
As machine actors gain access to cloud services, data and business processes, technology leaders need bounded authority, trustworthy provenance, protected credentials and accountable lifecycle controls. Governance should combine automation with risk-based human decisions so organisations can adopt AI and cloud services without creating unmanageable operational or security exposure over time.
Justin Henkel, CISO at SolarWinds, says: Securing machine actors is no longer an IAM cleanup exercise. It is an enterprise control problem spanning software supply chains, cloud platforms, data access, AI governance and operational resilience. The objective is not to eliminate automation or force every workload into a human identity workflow. It is to ensure that each automated actor has a defined purpose, bounded authority, trustworthy provenance, observable behaviour and a tested path to revocation. That requires discovery across cloud and application environments, clear accountability inherited through services and deployment pipelines, and authorisation policies that limit actions by resource, context and time. Credentials should become shorter-lived and less exposed, while identity providers, vaults and policy engines receive the resilience expected of critical infrastructure. AI agents require additional controls for delegated authority, tool use, prompt-driven manipulation and high-impact actions. Leaders should measure progress through privilege reduction, owner coverage, credential lifetime, provenance of sensitive actions, stale identity removal and time to revoke. Done well, machine identity governance does more than reduce risk: it enables repeatable automation, safer cloud agility and more accountable AI adoption across the enterprise. This is a measurable operating discipline, not a one-time compliance project, because authority and software behaviour change continuously across the enterprise.”
