Your AI Agents Have Credentials Too: The NHI Governance Gap Nobody Is Talking About

The identity problem nobody notices until it’s too late

Every organisation with a mature security program governs its human identities. There are processes for provisioning access, reviews for what people can do, offboarding workflows for when they leave. MFA is enforced, privileged access is controlled, access reviews happen on some cadence. The human identity estate is imperfect in most organisations, but it’s governed.

The machine identities are a different story.

Service accounts accumulate across years of infrastructure evolution. API keys get created for a project, the developer who created them leaves, and the keys keep working indefinitely because nobody knows what depends on them. OAuth grants pile up as teams connect tools to each other. IAM roles get cloned from permissive templates because the secure version requires extra effort nobody has time for. Certificates expire. Or they don’t, because they’ve been set to ten-year validity to avoid the rotation problem.

This has always been true. Security teams have known about it and, in most organisations, done relatively little about it. The problem felt manageable: service accounts were used by applications, not adversaries. The risk was real but diffuse.

Then agentic AI arrived.

What changed

Every organisation deploying AI tools is creating new machine identities at a pace that has no historical precedent. Not slowly, through deliberate infrastructure work, but through individual product decisions made by developers, data scientists, and product teams, often without involving security at all.

Consider what a typical AI deployment looks like in a mid-size organisation in 2026:

A data science team deploys a RAG pipeline that reads from the internal knowledge base, queries a vector database, and calls an external LLM API. That pipeline has credentials: an IAM role to read from S3, a database user for the vector store, and an API key for the LLM provider. Those credentials were provisioned in an afternoon and have had no governance applied since.

A developer team integrates GitHub Copilot Workspace, which is granted repository access across the organisation’s GitHub organisation. The token that grants that access is an OAuth grant tied to an admin user’s account. When that developer leaves, nobody removes the grant.

The platform team deploys an internal MCP server that gives Claude access to internal APIs: the ticketing system, the deployment pipeline, the incident management tool. The server authenticates via a service account with broad permissions because scoping it down would have taken another week of work. The service account has never been reviewed.

A customer success team uses an AI agent to draft and send follow-up emails. The agent has OAuth access to the organisation’s Google Workspace, including the ability to read and send email on behalf of anyone in the CS team.

None of these scenarios are unusual. All of them involve machine identities with real, consequential permissions. None of them are being governed.

The taxonomy of non-human identities

Before you can govern NHIs, you need to understand what falls into the category. Most organisations discover the scope is significantly larger than they expected.

Service accounts are dedicated user accounts created for applications rather than humans. They appear in Active Directory, cloud IAM, and application databases. They often have long-lived credentials, broad permissions, and no clear owner. In cloud environments, managed identities and workload identity federation are replacing the worst of these patterns, but the legacy estate persists.

API keys and long-lived tokens are credentials generated for programmatic access to services. They appear in GitHub secrets, environment variables, configuration files, secrets managers, and sometimes, unfortunately, in code repositories and Slack messages. Their defining characteristic is that they’re static (they don’t expire unless someone explicitly rotates or revokes them) and they’re often created by a person but outlive that person’s tenure.

OAuth grants are authorisations that allow one application to act on behalf of a user or organisation. They’re created through the “Connect” or “Authorise” flows that have become ubiquitous in SaaS integrations. Most organisations have hundreds of these across their SaaS estate. They’re invisible in most identity systems, rarely reviewed, and persist indefinitely unless explicitly revoked.

IAM roles and machine identities in cloud environments are the cloud-native equivalent of service accounts: identities assumed by compute resources, serverless functions, containers, and other workloads. They’re generally better governed than traditional service accounts (cloud providers have made progress here with managed identities, instance profiles, and workload identity), but the permissions attached to them often grow unchecked over time.

Machine certificates provide authentication for systems, services, and devices. Certificate lifecycle management is a well-understood problem that most organisations solve incompletely. Certificates expire in production, renewal processes are manual and error-prone, and the certificate inventory is rarely comprehensive.

AI agent credentials are the newest and fastest-growing category. These are the identities used by LLM-based systems to take actions: the IAM role assumed by a RAG pipeline, the OAuth grant given to an AI assistant, the API key used by an agentic workflow to call external services, the service account used by an MCP server to access internal APIs. This category didn’t exist at meaningful scale three years ago. It’s now expanding faster than any other part of most organisations’ identity estates.

Why AI agent credentials are a different problem

Every category of NHI has governance challenges. AI agent credentials have a specific set of properties that make them more dangerous than traditional machine identities.

They have delegated authority over humans. A traditional service account reads a database or writes to a queue. An AI agent emails customers, updates tickets, commits code, modifies configuration, and takes actions in production systems, actions that humans are accountable for. The permissions required for these actions are broad by nature. You can’t build an effective AI assistant for a customer success team without giving it access to customer data, communication tools, and case management systems.

They’re created outside normal identity workflows. Human identities go through provisioning processes. New employees get accounts created by IT. Service accounts are (ideally) reviewed and approved. AI agent credentials are typically created by whoever is deploying the AI tool: a developer configuring a new integration, a product manager setting up a third-party tool, an operations team automating a workflow. There’s no process checkpoint, no security review, no record.

They’re hard to scope. Traditional least-privilege guidance says: give the identity only the permissions it needs. For a service account that reads one S3 bucket, this is straightforward. For an AI agent that might need to query any internal knowledge source, access any customer record, send communication to any contact, and use any tool available in the workflow, scoping is genuinely difficult. The result is that AI agent credentials tend to be broadly permissioned because narrow permissions make the agent useless.

Their behaviour is inherently variable. A traditional service account does a predictable thing: it runs a batch job, it processes a queue, it writes to a log. You can define what it should do and alert on deviations. An AI agent’s behaviour is determined by what users ask it to do, which is inherently unpredictable. This makes behavioural monitoring of AI agent credentials significantly harder.

They bridge perimeters. AI agents routinely operate across boundaries that security architectures treat as hard divides. An internal AI assistant might query an internal knowledge base, call an external LLM API, send data to a third-party vector database, and post results to an internal Slack channel, all in a single workflow. Each of these actions crosses a boundary. The credential used for each crossing is often insufficiently secured.

What attackers do with compromised NHIs

The attacks that exploit poorly governed NHIs follow predictable patterns. These aren’t hypothetical. They’re documented in breach reports and incident post-mortems across the last several years.

Credential discovery via exposed secrets. Automated scanners continuously crawl public code repositories, S3 buckets with misconfigured access policies, and paste sites looking for exposed API keys, database credentials, and OAuth tokens. An API key committed to a public repository is typically found within minutes. If it hasn’t been rotated, the attacker has persistent access to whatever that key is authorised to do, potentially indefinitely, since many organisations have no alert for key usage from unexpected sources.

Service account abuse for persistence. Once an attacker gains initial access to an environment, service accounts provide an ideal persistence mechanism. They have broad permissions, their usage isn’t monitored with the same scrutiny as human account usage, and their activities blend into normal application traffic. An attacker who compromises a deployment pipeline service account has credentials that allow them to insert code into production systems, read all the secrets the pipeline accesses, and maintain access even if the initial compromise vector is remediated.

OAuth token hijacking. OAuth grants that are broadly permissioned and tied to administrative accounts represent a significant attack surface. An attacker who can steal or abuse an OAuth token gains the access of whoever authorised the grant, without needing that person’s password or MFA. In environments where OAuth grants are not regularly reviewed, this access can persist for years after the original authorisation.

AI agent credential abuse. This is the newest attack pattern, and it’s not yet well understood by most defenders. An attacker who compromises an AI agent’s credentials (by extracting them from environment variables, discovering them in a misconfigured secrets manager, or exploiting a prompt injection vulnerability in the agent itself) gains an identity that has:

Legitimate, pre-authorised access to internal systems
Broad permissions that were designed to enable flexible agent behaviour
Usage that blends into normal agent traffic, making anomaly detection difficult
No human who actively monitors whether the credentials are being used appropriately

A compromised AI agent credential doesn’t look like a compromised account. It looks like the agent doing its job. The exfiltration happens through the same API calls the agent makes legitimately.

Why existing identity programs don’t cover this

If you have a PAM solution and an IGA program, you might assume NHI governance is largely handled. It isn’t.

Privileged access management tools are designed for human privileged access: the jump servers, credential vaults, and session recording that govern what administrators can do. Most PAM deployments have limited coverage of service accounts and almost no coverage of API keys, OAuth grants, or AI agent credentials.

Identity governance and administration programs are built around the joiners/movers/leavers process. They handle user provisioning, role assignments, and access recertification. For humans. NHIs don’t have a lifecycle that maps to employment. They’re created for a project, not a person, and they have no natural offboarding event.

CSPM tools will flag broadly permissive IAM roles and unrotated access keys. They’re useful for identifying the most egregious misconfigurations. But they don’t give you a comprehensive picture of what your NHIs are, what they’re doing, who owns them, or whether they’re still needed.

The gap isn’t a tool gap. Most organisations already have tools that touch parts of the NHI problem. It’s a scope and process gap. Nobody owns NHI governance end to end, so it falls between the teams that own the partial tools.

What NHI governance actually involves

A functioning NHI governance program has four components: discovery, risk assessment, lifecycle management, and monitoring.

Discovery means building a comprehensive inventory of every non-human identity in your environment. This requires looking across multiple systems: cloud IAM consoles, identity providers, SaaS platform audit logs, secrets managers, certificate stores, and code repositories. For AI agent credentials specifically, it means asking every team that has deployed AI tooling what credentials those tools use and documenting the answers.

The discovery phase consistently surfaces surprises. Most organisations find two to three times more NHIs than they expected, including credentials that are actively in use by systems that nobody is consciously maintaining.

Risk assessment means evaluating each NHI against a set of risk factors: privilege level (what can this identity do?), usage pattern (is it still active?), credential age (when were these credentials last rotated?), ownership (is there a team that actively manages this?), and exposure (are these credentials accessible to more people or systems than they should be?). AI agent credentials get additional scrutiny given the factors discussed above: delegated authority, broad permissions, and perimeter-crossing behaviour.

Lifecycle management means treating NHIs with the same rigour as human identities across their lifecycle: provisioning with appropriate permissions, regular reviews of whether access is still needed and appropriately scoped, rotation of credentials on a defined cadence, and decommissioning when the NHI is no longer required.

For AI agent credentials specifically, lifecycle management needs to account for the rapid evolution of AI tooling. An agent that was deployed for a proof of concept six months ago and quietly forgotten is a common finding. The credentials don’t disappear when the agent does.

Monitoring means understanding what your NHIs are doing and alerting when they deviate from expected behaviour. This is harder for AI agents than for traditional service accounts, for the reasons discussed above. The approach is to monitor at the aggregate level (total API calls, data volumes, external connections) rather than trying to specify exactly what the agent should do on each request.

Where to start

Most organisations that begin an NHI governance program are overwhelmed by the scope of what they discover. The right approach is to prioritise by risk rather than trying to address everything at once.

Start with the highest-privilege NHIs: the ones with broad permissions in production environments, access to sensitive data, or the ability to take consequential actions. For most organisations, this means production-environment IAM roles with admin or write access, service accounts with access to customer data, and AI agent credentials with broad SaaS permissions.

For each high-privilege NHI, answer four questions: Does it still need to exist? Is the level of access still necessary and proportionate? Do we know who owns it? When were the credentials last rotated?

The answers to these questions will identify the highest-priority remediation actions. An active service account with admin permissions and a credential that hasn’t been rotated in three years, with no identified owner, is a straightforward high priority. An AI agent OAuth grant with access to all company email, created during a product trial that was abandoned, is another.

Work down from there. The goal in the first engagement is a reliable inventory of what exists and a prioritised remediation list, not perfect governance across every NHI. Perfect is the enemy of starting.

The regulatory direction of travel

NHI governance isn’t just a security best practice. The regulatory and standards landscape is moving to make it an explicit requirement.

ISO 27001:2022 expanded Annex A to include specific controls for non-human identities, recognising that the 2013 version’s focus on user accounts was no longer sufficient. NIST SP 800-207 (Zero Trust Architecture) addresses workload identity as a core component of zero trust implementation. CISA has published guidance on machine identity management as part of its identity security work.

Australian organisations operating under APRA CPS 234 are already expected to manage information security risks related to all access to information assets, which includes NHIs. The ISM addresses service account governance under its access control controls. IRAP assessors are increasingly asking about NHI management as part of ISM assessments.

The direction is clear. Organisations that build NHI governance capabilities now are ahead of the compliance curve. Those that wait are building a debt that will be more expensive to address under regulatory pressure.

The window before this becomes critical

AI adoption is accelerating. The organisations deploying the most ambitious agentic AI programs are also the ones creating the most ungovernanced NHIs, the most broadly-permissioned agent credentials, and the most complex cross-perimeter integrations, all without the governance infrastructure to understand what they’ve built.

The adversary community is watching this. Attacks targeting AI agent credentials are not yet common. They will become common when the credential estate is large enough to be a profitable target and the attack tooling has matured. That window is measured in months, not years.

The good news is that NHI governance is tractable. It doesn’t require a multi-year transformation program. An organisation that commits to understanding what NHIs it has, prioritising the highest-risk ones, and building lifecycle management processes can make meaningful progress in a matter of weeks. The foundational work (discovery and risk assessment) is where most organisations need to start, and it’s achievable.

The time to build that foundation is now, while the credential estate is still comprehensible and before the regulatory and adversarial pressure arrives together.