RSA 2025 showed identity becoming the control plane for AI and NHIs

At a glance

What this is: RSA 2025 surfaced a converging identity problem: AI, third-party risk, and NHI sprawl are becoming one control-plane issue.

Why it matters: IAM teams have to govern service accounts, AI-assisted workflows, and supplier access as connected risk domains because the blast radius now crosses all three.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Oasis Security's RSA 2025 takeaways on AI, third-party risk, and identity

Context

RSA 2025 was not just another product-heavy security conference. The central identity security signal was that AI assistance is moving into production while third-party relationships and non-human identities are expanding the number of access paths that security teams have to govern.

For IAM leaders, that creates a single operating problem rather than three separate ones: who or what can act, which systems they can reach, and how much trust is extended through suppliers, service accounts, and AI-enabled workflows. The source article’s takeaway is that the control plane is shifting toward identity, but the operational burden now sits with governance teams.

That starting point is typical of the current market, not an edge case. Most enterprises are already dealing with a mix of human access, workload identities, and AI-adjacent tooling, but still run them through different oversight models.

Key questions

Q: How should security teams govern AI-assisted workflows that can take action on their own?

A: Security teams should govern AI-assisted workflows as identities with assigned owners, bounded permissions, and explicit approval paths. The key is to separate conversational capability from operational authority. If a workflow can read data, trigger actions, or call tools, it needs the same entitlement discipline and offboarding logic as any other non-human identity.

Q: Why do third-party integrations increase identity risk so quickly?

A: Third-party integrations increase identity risk because they extend trust through credentials, tokens, and delegated access rather than through direct human oversight. Once the supplier has standing access, your programme inherits the supplier’s governance quality. That is why inventory, expiry, and revocation discipline matter as much as vendor due diligence.

Q: What breaks when non-human identities are managed separately from AI security?

A: What breaks is the ability to see the full trust chain. AI tools often rely on service accounts, API keys, and delegated permissions to operate, so separating AI security from NHI governance leaves gaps in ownership, entitlement review, and incident containment. The result is duplicated controls that still miss the real access path.

Q: How can IAM teams reduce risk from supplier access and machine identities together?

A: IAM teams should use one lifecycle model for supplier access and machine identities, with discovery, ownership, review, and revocation linked together. That makes it easier to spot stale access, duplicate privileges, and forgotten integrations before they create a wider attack surface.

Technical breakdown

Why identity becomes the control plane in AI-heavy environments

When AI tools, SOC copilots, and third-party services all need access to data and actions, identity becomes the coordination layer that decides what is allowed to act. In practice, that means authentication, authorisation, entitlement scope, and ownership all matter more than the interface or model name. The article reflects a broader shift already visible in security programmes: teams are no longer securing only users, they are securing software actors and delegated access paths. That creates a governance problem, not just a tooling problem, because every new actor type increases review, logging, and offboarding complexity.

Practical implication: Map every AI or third-party workflow to an explicit identity owner before it is allowed into production.

Third-party risk now includes delegated machine access

Third-party risk used to focus on contractual exposure and supplier trust. In identity terms, it now includes whatever access the supplier can reach through API keys, service accounts, embedded tokens, and connected workflows. That matters because supplier compromise is often operationalised through legitimate credentials rather than classic intrusion paths. Once a vendor or integration has standing access, its access patterns become part of your own attack surface. This is why third-party risk management and NHI governance are converging: the same credential controls that protect internal workloads also determine how much trust is inherited from partners.

Practical implication: Inventory supplier-issued secrets and bound them to named business owners, expiry dates, and revocation triggers.

NHI sprawl is accelerating faster than governance cadence

Service accounts, API keys, and other non-human identities grow quickly because they are easy to create and hard to retire. The article’s point about NHIs multiplying with cloud and gen-AI use is consistent with a larger governance failure: lifecycle controls are usually slower than the rate at which new machine identities appear. That creates entitlement drift, unclear ownership, and stale credentials long before security teams notice. The technical issue is not just discovery, but whether entitlement data remains accurate long enough to support policy, review, and incident response.

Practical implication: Shift from periodic clean-up to continuous discovery and entitlement validation for all non-human identities.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

AI security and NHI governance are now converging on the same control plane. The article is right that AI for security is moving into production, but the deeper implication is that the identities behind those workflows matter more than the model itself. Once copilots, responders, and supplier integrations can take action, identity scope becomes the real boundary of trust. Practitioners should treat AI adoption as an identity architecture decision, not a feature rollout.

Third-party risk has become delegated access risk. Supplier exposure is no longer only about data sharing or contractual compliance. It is about whether external actors are operating through standing credentials, embedded tokens, or inherited permissions that were never designed for continuous oversight. That pushes third-party governance into the same discipline as NHI lifecycle management, because the failure mode is access persistence beyond accountability.

Identity blast radius is the right named concept for this RSA pattern. AI assistance, cloud services, and third-party chains all expand the number of identities that can act on behalf of the enterprise, which makes the reachable impact of any one credential larger. The article captures the market intuition, but the governance conclusion is sharper: if identity is the control plane, then uncontrolled identity growth is what defines the blast radius. Practitioners should measure control by reachable scope, not by how many tools they have deployed.

The market is moving from point controls to lifecycle governance. Discovery, context, anomaly detection, and entitlement right-sizing were all themes in the article because static access models are not keeping pace with dynamic environments. That shift validates lifecycle-first governance across NHI, supplier, and AI-assisted access. Security teams should expect evaluation criteria to move from feature checklists to whether a programme can continuously assign, verify, and revoke identity authority.

AI for security does not remove governance pressure, it multiplies it. Automated detection and triage can reduce analyst workload, but they also create new privileged actors that need oversight. The result is that identity programmes will increasingly be judged on whether they can govern machine speed without losing accountability. Practitioners should assume that any AI-enabled security workflow will eventually need the same scrutiny as a service account with broad reach.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
• For deeper lifecycle context, see Ultimate Guide to NHIs for visibility, rotation, and offboarding discipline.

What this signals

The practical signal for IAM and security architecture teams is that AI rollouts should now be reviewed alongside service-account governance, not after the fact. The boundary between assistive automation and delegated authority is already blurred in real environments, which means entitlement review, ownership, and revocation need to cover machine actors as a standard design assumption.

Identity blast radius: the useful lens here is not how many AI tools or supplier connections exist, but how far any one identity can reach when permissions accumulate across workflows. That shifts prioritisation toward entitlement mapping, access path reduction, and tighter lifecycle control for external and internal non-human identities alike.

With only 5.7% of organisations reporting full visibility into their service accounts, the governance gap is already structural, according to Ultimate Guide to NHIs. Teams should expect the next wave of AI-enabled security tooling to increase rather than reduce the need for disciplined identity inventory and review.

For practitioners

• Treat AI copilots as governed identities Assign every AI-assisted workflow an owner, a permission boundary, and an approval model before it is allowed to act on security data or response paths.
• Collapse third-party access into your NHI inventory Track supplier-issued API keys, service accounts, and embedded tokens in the same register as internal non-human identities so revocation and review follow one process.
• Measure identity blast radius, not just asset count Review which systems each credential can reach, which actions it can trigger, and whether those permissions are still justified by the current business relationship.
• Add lifecycle triggers to supplier access reviews Tie access review and offboarding to contract change, service retirement, and integration replacement instead of relying on calendar-based recertification alone.

Key takeaways

• AI adoption, third-party risk, and NHI sprawl now behave like one identity governance problem rather than separate programme tracks.
• Service accounts and supplier access remain poorly visible in most enterprises, which makes delegated machine access a durable source of exposure.
• The strongest response is lifecycle-based control over every identity that can act, not a narrow focus on tools or model features.

Key terms

• Non-Human Identity: A non-human identity is any credentialed software or workload actor that can authenticate and act inside an environment. That includes service accounts, API keys, tokens, certificates, bots, and AI agents when they are granted operational access. Governance must cover creation, ownership, review, rotation, and retirement.
• Identity Blast Radius: Identity blast radius is the amount of reachable access an identity can exert if it is misused or compromised. It is determined by the systems, data, and actions linked to the identity, not by the size of the environment. The smaller the blast radius, the easier containment becomes.
• Third-Party Access Governance: Third-party access governance is the control set that tracks, approves, reviews, and revokes access granted to external vendors and partners. It becomes an identity problem when suppliers operate through shared credentials, delegated workflows, or persistent machine access that outlives the business need.
• Lifecycle Governance: Lifecycle governance is the discipline of assigning, certifying, changing, and removing access across the full identity lifespan. For non-human identities, it must handle faster creation cycles, weaker human visibility, and more frequent offboarding triggers than human identity programmes usually expect.

Deepen your knowledge

AI-assisted workflows, third-party delegation, and NHI lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is working through the same control-plane shift, it is worth exploring.

This post draws on content published by Oasis Security: RSA 2025: 5 Takeaways on AI, Third-Party Risk & the Future of Identity. Read the original.