Non-human identity security is the work of controlling the accounts, credentials, roles, tokens, and certificates used by software rather than people. The label covers service accounts, cloud roles, Kubernetes service accounts, CI/CD runners, API clients, robotic process automation, integration connectors, and AI agents that call tools. These identities are easy to create and hard to govern because they often sit between application code, infrastructure, and security ownership.

The immediate problem is not a shortage of security products. It is that a machine credential can remain useful long after the project, pod, pipeline, or agent session that justified it. A static key copied into a repository may outlive several teams. A shared service account may hide which workload performed an action. An AI agent may hold a legitimate token while untrusted content influences the next tool call. The control plan has to cover both identity mechanics and the behavior that uses the identity.

This guide uses current documentation from OWASP, NIST, AWS, Google Cloud, Microsoft, Kubernetes, and OpenAI. It does not assume that one vendor’s identity feature transfers to another platform. The goal is a practical operating model that works across cloud workloads and agent systems while keeping product-specific claims tied to official sources.

What counts as a non-human identity

A non-human identity is a digital principal used by a workload, service, automation process, device, or software agent. The principal is not the same thing as its credential. A service account is an identity. A password, API key, private key, certificate, or signed token may be the credential used to authenticate it. Permissions then determine what the authenticated identity can do. Keeping those three concepts separate makes reviews much clearer.

A single application may involve several identities. Its build pipeline can exchange an OIDC token for cloud access. The deployed service can run under a workload role. A database proxy may use another identity. An AI agent inside the service can call a search tool and a ticketing API through separately scoped connections. Treating all of that as one “application secret” erases the boundaries that incident responders need.

AWS distinguishes human identities from machine identities and recommends temporary, limited-privilege credentials for programmatic access. Microsoft describes workload identities as applications, service principals, and managed identities. Kubernetes ServiceAccounts provide identities for processes running in pods. These terms differ, but the operating question is consistent: which software principal requested which resource, under what conditions, and for how long?

Official references: AWS identity and access management guidance, Microsoft Entra workload identity overview, and Kubernetes ServiceAccounts documentation.

Why old secret rotation advice is not enough

Rotation still matters, but a calendar reminder does not solve identity sprawl. Teams first need to know that a secret exists, which identity it authenticates, where it is deployed, who owns the workload, and what will break when the credential changes. Without that map, rotation becomes a risky maintenance event and usually gets postponed.

OWASP’s Non-Human Identities Top 10 for 2025 lists long-lived secrets as a distinct risk. Its description includes API keys, tokens, encryption keys, and certificates with distant expiration dates or no expiration. If one leaks, a long validity period gives an attacker more time to use it. OWASP also calls out identity reuse. A credential shared by multiple applications or environments makes containment harder and expands the impact of a compromise.

The better design removes a stored secret when the platform can issue temporary credentials from a trusted runtime identity. If that is not possible, the team should place the secret in an approved manager, restrict access to the smallest workload set, rotate it through a tested procedure, and alert on unexpected use. Rotation frequency alone is a weak metric. A ninety-day secret that nobody can attribute is worse than a short-lived token with a clear subject, audience, session, and owner.

Official references: OWASP on long-lived secrets and non-human identity reuse.

Build an inventory that can answer incident questions

An inventory should record more than a name and creation date. For each identity, capture the owning team, technical contact, business service, environment, authentication method, credential location, allowed resources, maximum session duration, last observed use, review date, and retirement trigger. Record whether the identity is shared. A shared identity should create a visible exception, not disappear into a generic label such as “automation.”

Start from systems that issue or authorize credentials: cloud IAM, identity providers, vaults, certificate authorities, Kubernetes clusters, CI/CD platforms, source control apps, SaaS integration catalogs, and agent connection stores. Then compare the inventory with runtime evidence. Cloud logs may reveal a role that no repository scan found. A repository scan may reveal a dormant key that has not appeared in recent logs. Neither view is complete by itself.

Ownership needs an expiration mechanism too. If the listed owner leaves or the service moves to another group, the record should enter a review queue. Link identities to deployable units and service catalogs where possible. That gives a reviewer something concrete to inspect and lets an incident responder contact the people who understand the workload.

Prefer federation and temporary credentials

Temporary credentials reduce the useful lifetime of stolen material. On AWS, workloads can receive credentials through roles, instance profiles, federation, and the Security Token Service rather than carrying long-term access keys. Google Cloud recommends Workload Identity Federation for external workloads when the external identity provider supports it. In Azure, managed identities and workload identity federation can remove the need to store a service principal secret in the workload.

Federation is not automatically safe. The trust policy still has to constrain issuer, audience, subject, repository, branch, environment, or other relevant claims. OWASP’s cloud deployment guidance warns that a CI/CD OIDC trust relationship can be too broad if token claims such as the subject are not restricted. A short-lived token issued to the wrong caller is still unauthorized access.

Make the trust relationship reviewable as code. Test positive and negative cases. The approved pipeline should obtain access. A fork, unapproved branch, different repository, unexpected audience, or altered environment should fail. Keep cloud permissions narrow after federation succeeds, because authentication only proves the caller matched the trust rule. Authorization determines the damage that caller can cause.

Official references: Google Cloud service account security practices and OWASP’s cloud deployment configuration guidance.

Give every workload its own useful boundary

One identity per logical workload and environment is a good default. Production should not reuse the development identity. A reporting job should not share the identity used by a deployment controller. Two pods with different duties should not inherit the same broad Kubernetes ServiceAccount merely because they run in one namespace.

Unique identities improve containment and attribution. If a batch processor is compromised, responders can disable its access without shutting down unrelated services. Logs can show which workload made the request. Permission reviews can remove rights from one component without negotiating a dangerous shared policy.

Least privilege has to include resources, actions, and conditions. A service that reads objects from one bucket does not need account-wide storage administration. A deployment job may need to update one application but not edit identity policies. A support agent may create a draft ticket while a separate approved action sends the customer response. Conditions such as source workload, audience, network context, resource tags, and session duration can narrow the path further.

Kubernetes service account choices matter

Kubernetes creates a default ServiceAccount in each namespace, and pods use a ServiceAccount unless another is assigned. That convenience can hide accidental sharing. Define purpose-specific ServiceAccounts, bind only required RBAC permissions, and set automountServiceAccountToken: false for workloads that do not need Kubernetes API access.

For workloads that do need a token, use the TokenRequest mechanism and projected volumes rather than manually created, long-lived service account token Secrets. Kubernetes documentation explains that projected tokens can carry an audience and an expiration, and the platform rotates them. External services must still validate the issuer, audience, signature, expiry, and relevant subject claims.

Do not confuse a short-lived Kubernetes token with permission safety. A pod that receives a renewable token and broad cluster rights can keep using those rights while it runs. Review RBAC, workload isolation, admission controls, and outbound access alongside token settings.

AI agents add a behavioral authorization problem

An AI agent is not secure merely because its tool connector uses OAuth instead of an API key. The connector may be well implemented while the agent chooses an unsafe action after reading hostile content. OpenAI’s agent safety guidance describes prompt injection as untrusted text attempting to override instructions, with possible outcomes that include private data exfiltration or unintended downstream tool calls.

The identity design should assume that model output can be wrong. Give the agent access to the smallest set of tools needed for the current workflow. Separate read tools from write tools. Keep consequential actions behind approvals. Pass structured fields between stages instead of letting arbitrary external text directly control a tool call. Validate identifiers and destinations on the server side rather than trusting prose generated by the model.

For a fuller treatment of permissions, traces, and guardrails, read PChatGPT’s AI agent runtime security guide. Users working with ChatGPT’s own security controls can also consult the ChatGPT Lockdown Mode guide. Those controls address different layers, so one should not be presented as a substitute for workload IAM.

Use task-scoped identities for agents

A long-running agent service may need a stable platform identity to start, but every task does not need the full authority of that service. Exchange the platform identity for a narrower session or task credential where the architecture supports it. Attach a purpose, audience, user or workflow context, and short expiry. The tool gateway should enforce those properties even if the model asks for something broader.

Delegated access also needs careful labeling. If a human asks an agent to act, logs should preserve both the workload identity and the initiating user or workflow. Do not collapse the event into the human’s name, because the software made intermediate decisions. Do not record only the agent’s service account, because responders then lose the delegation chain.

Tool approval is most useful at the point where a decision becomes an external effect. Reading a public page and deleting a production record are not equivalent. Approval policies can consider action type, data sensitivity, destination, transaction value, novelty, and reversibility. Requiring a person to approve every harmless read creates fatigue. Letting one early approval authorize every later write creates excessive standing authority.

Official reference: OpenAI’s safety guidance for building agents.

Logging should connect identity, decision, and effect

NIST’s zero trust implementation material includes a service-to-service use case for non-person entities and automated processes. It expects the enterprise to identify and authenticate the subject and resource, and it calls for successful and failed communications to be logged. That is a useful baseline for machine identity telemetry.

For each sensitive request, capture the authenticated principal, credential or session identifier, issuer, target resource, action, policy decision, time, source workload, and result. For an agent workflow, add the tool name, approved parameters, approval record when required, and a reference to the trace or task. Avoid dumping raw secrets, private prompts, or complete customer data into logs. Useful audit context and indiscriminate data collection are not the same thing.

Alerting should look for behavior as well as age. Examples include a dormant identity becoming active, access from a new workload, use outside a deployment window, repeated authorization failures, a production identity appearing in development, token use with an unexpected audience, bulk reads, unusual tool sequences, or an agent requesting a write after processing untrusted material. Baseline the expected workload before choosing thresholds.

Official reference: NIST’s service-to-service zero trust use case.

Plan rotation and revocation as production operations

Rotation needs a tested overlap procedure. Issue the replacement credential, deploy it to the intended workload, verify successful authentication, disable the old credential, monitor for callers that still use it, and then remove it. The overlap should be short and documented. If two valid credentials remain indefinitely, the rotation has doubled the attack surface instead of reducing it.

Revocation is different. During an incident, the team may need to stop access immediately. Test whether the platform can revoke sessions or only prevent new tokens. Know how cached credentials behave. Prepare a way to disable one identity without deleting unrelated resources, and document emergency dependencies so responders understand the operational effect.

Retirement should follow application decommissioning, environment deletion, connector removal, contract termination, and ownership loss. Disable first when a reversible pause is safer, observe for missed dependencies, then remove credentials, role bindings, federation trusts, and identity objects according to retention policy. An inactive identity with active trust or credentials is not retired.

A practical 90-day improvement plan

During the first month, establish scope. Inventory identities from major cloud accounts, clusters, CI/CD systems, vaults, and agent platforms. Mark shared identities, long-lived secrets, missing owners, dormant accounts, and broad permissions. Pick a small number of high-impact workloads for correction rather than promising complete coverage immediately.

During the second month, replace the riskiest static credentials with workload roles, managed identities, or federation. Give production and non-production separate principals. Narrow OIDC trust claims and permission policies. Create rotation and emergency revocation runbooks for credentials that must remain. Add identity fields to the service catalog and deployment templates.

During the third month, connect runtime evidence. Centralize authentication and authorization events, add owner-aware alerts, and test incident queries. For agents, map every tool to its credential path and approval policy. Run a tabletop exercise in which a repository secret leaks or an agent attempts an unauthorized write. Record how quickly the team can identify the principal, owner, permissions, active sessions, and safe containment action.

Success is measurable. The team should know what percentage of production identities have an owner, how many workloads still use long-lived credentials, how many identities are shared across environments, how quickly a high-risk credential can be revoked, and whether logs can attribute sensitive requests. Avoid vanity totals that reward creating inventory records without fixing authority.

Questions to ask in every review

• Which exact workload uses this identity, and who owns that workload?
• Can the platform issue a temporary credential instead of storing a secret?
• Are issuer, audience, subject, environment, and resource conditions narrow enough?
• Is the identity shared across applications, clusters, pipelines, or environments?
• What resources and actions can it reach today, including indirect tool calls?
• Can responders attribute use, rotate safely, revoke quickly, and retire cleanly?
• For an AI agent, what untrusted inputs can influence tool selection or parameters?
• Which actions require approval, and does the tool enforce the final boundary?

Bottom line

Non-human identity security works when every software principal has a purpose, owner, narrow authority, short credential path, useful telemetry, and an end date. Cloud roles and federation reduce secret exposure, but weak trust policies can still authorize the wrong workload. Rotation limits credential lifetime, but it does not fix shared identities or excessive permissions. Agent guardrails help with model behavior, but tools must still enforce identity and authorization outside the model.

Start with the identities that can deploy code, read sensitive data, change infrastructure, or call consequential tools. Give them distinct boundaries and replace permanent credentials where the platform supports a safer exchange. Then test the questions an incident will force you to answer: what acted, why it was allowed, what it touched, who owns it, and how fast access can be stopped.

FAQ

What is a non-human identity?

It is a digital principal used by software, a service, workload, device, automation process, or AI agent. The identity is distinct from the password, key, certificate, or token used to authenticate it and from the permissions granted after authentication.

Are API keys always unsafe for workloads?

No, but static API keys carry more operational risk than short-lived, audience-bound credentials when a supported federation or managed identity option exists. If a key is necessary, store it in an approved secrets system, restrict its permissions, attribute its use, rotate it through a tested process, and retire it with the workload.

How should an AI agent authenticate to tools?

Use a narrowly scoped connector or task credential, keep sensitive writes behind appropriate approvals, and validate the final action in the tool or gateway. Do not treat model output as proof that the request is authorized.

What should a non-human identity inventory contain?

At minimum, record the principal, owner, workload, environment, authentication method, credential location, permissions, trust conditions, last use, review date, and retirement trigger. Add delegation and tool context for agent workflows so logs preserve both the software actor and the initiating task.