AI agent security is shifting the risk from code to identity

At a glance

What this is: This is an analysis of how AI-driven application security pushes risk from code quality into non-human identity governance, especially runtime credentials and agent access.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern dynamic machine and agent identities, not just human users and static secrets.

👉 Read Hush Security's analysis of how AI security is shifting risk into identity

Context

AI agent identity risk is increasingly a workload identity problem, not just an application security problem. As AI tools catch more code flaws earlier, the remaining exposure concentrates in the credentials, tokens, and service accounts that let systems authenticate to data, APIs, and downstream services.

That shift breaks older governance models that were built around periodic review of stable access. For identity teams, the hard question is no longer whether code is secure enough, but whether runtime access is governed tightly enough to contain AI agents, microservices, and other non-human identities.

The broader issue is that non-human identity sprawl is now part of the core control surface for modern IAM programmes. Discovery, vaulting, rotation, and least privilege each help, but none of them are sufficient on their own when credentials outlive the workload that uses them.

Key questions

Q: How should security teams govern AI agents that rely on shared runtime credentials?

A: Security teams should treat every AI agent as a workload identity with a defined task boundary, then issue only the minimum access required for that task. Shared credentials should be retired where possible because they obscure accountability, widen blast radius, and make revocation harder after the task completes.

Q: Why do static secrets create more risk in AI-driven environments?

A: Static secrets create more risk because AI-driven systems are dynamic, short-lived, and highly interconnected. A credential that stays valid for months can be reused across many services long after the original task ends, which turns a small exposure into a broad trust failure.

Q: What do teams get wrong about secrets discovery?

A: Teams often assume that finding a secret is the same as fixing the exposure. In reality, discovery only reveals where the credential exists and where it might be used. The control value comes from revocation, rotation, and access scoping, not from the inventory itself.

Q: Who should own machine identity governance in a modern IAM programme?

A: Machine identity governance should be shared across IAM, PAM, security engineering, and platform teams because the risk sits in runtime access, not just in a vault. Ownership needs to cover issuance, scope, monitoring, and offboarding across every non-human identity type.

Technical breakdown

Why static secrets fail in ephemeral AI workflows

Static secrets were designed for environments where workloads persisted long enough for periodic rotation to matter. In AI-native systems, tasks can spin up, call several services, and terminate quickly, which makes long-lived credentials a mismatch for the operating model. A stored API key or service token can remain valid long after the job that used it is gone. That creates exposure that is hard to observe and harder to revoke at the right moment. The technical issue is not just storage, but lifecycle misalignment between credential lifetime and workload lifetime.

Practical implication: move from credential persistence to task-scoped issuance wherever the workload pattern is ephemeral.

How over-privileged service accounts expand blast radius

A service account is simply a machine identity that lets software authenticate to other systems. The risk rises when the account carries broad permissions across databases, queues, APIs, and orchestration layers. In AI-driven environments, that matters because one agent or pipeline may chain multiple actions in a single execution path. If the credential is compromised, the attacker does not need to break each target separately. They can reuse the existing trust path. The architecture problem is not new privilege, but accumulated privilege across integrated systems that were never reviewed as one access boundary.

Practical implication: map each machine identity to its real downstream reach before it is allowed into production workflows.

Why discovery tools expose, but do not govern, identity risk

Discovery tools are useful because they surface hidden secrets, unmanaged credentials, and broad blast radius across cloud and code repositories. But discovery is diagnostic. It tells you where exposure exists, not whether the access model is safe to keep. That distinction matters in AI-heavy environments where the number of identities is growing faster than manual governance can keep pace. Visibility without revocation, scoping, or runtime enforcement leaves teams with a cleaner inventory and the same underlying access problem. Technical maturity therefore depends on turning discovery into action, not treating it as the control itself.

Practical implication: pair discovery with enforcement so exposed credentials can be scoped, rotated, or retired automatically.

Threat narrative

Attacker objective: The attacker wants durable runtime access through machine identity so one credential can unlock multiple systems and workflows.

1. Entry occurs when attackers target exposed credentials, hardcoded secrets, or over-shared tokens tied to automated pipelines and AI workloads.
2. Escalation follows when those credentials grant broader access than the current task requires, allowing reuse across APIs, databases, and internal systems.
3. Impact is achieved through lateral movement across connected services, with the compromised identity becoming the bridge into multiple operational environments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access review processes assume privilege persists long enough to be reviewed. That assumption was designed for stable human and machine access windows, not for AI agents that can acquire and release access within a single task execution. Once identity becomes runtime-driven, the review cycle can miss the entire event. The implication is that governance must rethink what counts as reviewable access state.

Identity blast radius is becoming the deciding control variable. When AI agents, microservices, and automated pipelines share the same downstream systems, one over-privileged credential can multiply impact across several services. The problem is not only whether a secret exists, but how far it can move once used. Practitioners should treat access scope as an incident limiter, not a provisioning detail.

Runtime governance is now the gap between visibility and control. Discovery reveals secrets and over-permissioned accounts, but the article shows why that is only the first half of the problem. In agentic environments, a credential can be valid, useful, and still unsafe because it outlives the task. The field needs governance that is built around execution, not inventory.

Just-in-time access is becoming the structural alternative to standing privilege. The article’s core logic is that static credentials do not fit dynamic workloads. That is not a tooling complaint, it is an operating model problem. Practitioners should read this as a shift away from durable access as the default and toward access that is issued only when the task requires it.

Non-human identity governance is converging with agentic AI governance. The same control failures now affect service accounts, automation pipelines, and AI agents because all of them depend on runtime credentials. That convergence means IAM, PAM, and NHI teams can no longer treat machine identity as a sidecar to human access management. The programme implication is a shared control model across all non-human actors.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Another finding from the same research shows that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
• For a broader governance lens, see Ultimate Guide to NHIs , Key Challenges and Risks for visibility gaps, over-privilege, and unmanaged credentials.

What this signals

Credential visibility is becoming a governance boundary, not just an operational convenience. When teams cannot see which vendors and workloads hold OAuth-linked access, they also cannot prove that access is still appropriate. The 85% visibility gap reported in The State of Non-Human Identity Security shows why identity programmes need continuous control over machine access, not periodic clean-up.

Ephemeral access needs a different control logic. If a workload can come and go in minutes, access governance must happen at runtime rather than by batch review. That is where NHI programmes should align with NIST Cybersecurity Framework 2.0 functions for identify, protect, and detect, because the identity state is changing faster than traditional certification cycles can follow.

The next maturity jump is not a better inventory. It is the ability to connect identity discovery, access scope, and automated revocation into one operating model so machine identities stop becoming hidden long-tail risk.

For practitioners

• Map machine identities to real downstream reach Inventory service accounts, API keys, and tokens by the systems they can actually reach, then identify where one credential crosses multiple trust zones. This exposes hidden blast radius before it becomes an incident.
• Replace standing access with task-scoped issuance Issue credentials for the shortest feasible execution window, aligned to the task rather than the platform. Revoke them automatically when the job completes so the access state does not outlive the workload.
• Tie discovery to automated enforcement Use discovery outputs to trigger rotation, scope reduction, or retirement workflows instead of treating them as reporting artifacts. If a secret is found but not acted on, the control failed.
• Review AI agent permissions as runtime boundaries Assess each agent as a workload identity with explicit action reach, then verify which APIs, queues, and data stores are truly required for the task. Remove inherited access that is not essential to execution.

Key takeaways

• AI-assisted code security reduces one class of risk, but the identity layer now holds the harder exposure problem.
• Long-lived secrets and over-privileged service accounts turn AI workflows into broad trust chains that are difficult to contain.
• IAM and NHI teams need runtime governance, task-scoped access, and enforcement tied to discovery if they want to reduce blast radius.

Key terms

• Non-Human Identity: A non-human identity is any credentialed digital identity used by software, services, or automation rather than a person. That includes API keys, service accounts, tokens, certificates, and AI agents when they authenticate to other systems.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being issued only when needed. In machine environments, it becomes risky when the credential outlives the workload, because dormant access is still usable by an attacker or misbehaving automation.
• Identity Blast Radius: Identity blast radius is the amount of downstream access a compromised credential can unlock. It measures how far one secret can travel across systems, which is why scope, reuse, and inheritance matter as much as the credential itself.
• Just-in-Time Access: Just-in-time access is a provisioning pattern where credentials are issued for a specific task and revoked when the task ends. For non-human identities, it reduces the window in which a token can be stolen, reused, or forgotten in an active state.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Hush Security: LLMjacking and the shift from code security to identity risk. Read the original.