RSAC 2026: AI Agents & Non-Human Identity Risk

A service account does not get tired, take vacation, or appear in an org chart. More importantly, it does not explain itself when it starts reading a table it was never supposed to touch.

This is exactly why non-human identity became a major security theme at RSA Conference 2026. According to CSO Online’s RSA 2026 recap, identity management stood out as AI agents, automation frameworks, and machine-scale access patterns pushed risk far beyond the traditional employee-admin model.

The challenge is not just the growing number of identities. Instead, these identities actively retrieve data, call APIs, trigger workflows, and chain actions at a speed no human review process can match. As a result, identity governance shifts from simple access management into a real-time data security problem.

The Problem Was Already Bigger Than the Org Chart

AI did not create non-human identity sprawl — it inherited and accelerated it.

Back in April 2025, CyberArk reported that machine identities outnumber human identities by more than 80 to 1. These include service accounts, API keys, certificates, workload identities, tokens, secrets, bots, and automation credentials — all quietly holding modern infrastructure together.

Most of these identities exist for practical reasons. For example, deployment pipelines need database access, reporting services require read permissions, and batch processes move data across systems. Meanwhile, proof-of-concept projects often receive broad access just to “make it work,” with cleanup postponed indefinitely — and then forgotten.

Even before AI, this created risk. Now, however, AI agents amplify it by introducing autonomous behavior on top of already overprivileged credentials.

Machine Identities and AI Agent Identities Are Not the Same Thing

Security teams need to stop flattening every non-human identity into a single category. Sure, it makes dashboards look cleaner. However, that is usually the first sign that reality has been mugged in an alley.

Machine identities include service accounts, workload identities, API keys, certificates, and automation credentials. In most cases, they execute predefined tasks. Their risk comes from scale, over-permissioning, weak ownership, stale credentials, and poor lifecycle management.

By contrast, AI agent identities introduce a different class of risk. They interpret requests, retrieve context, select tools, call services, and trigger workflows with varying levels of autonomy. In a SailPoint and AWS announcement, SailPoint CEO Mark McClain described this growth as the emergence of a new category of non-human identities, each expanding the attack surface.

This distinction matters. A traditional service account may be overprivileged, but its behavior usually stays narrow. In contrast, an AI agent can use that same account within a broader workflow that shifts based on prompts, retrieved data, available tools, and downstream responses. At that point, the identity no longer just authenticates a script — it enables a decision loop.

Identity Risk Becomes Data Risk Immediately

On paper, non-human identity looks like an IAM problem. In practice, it turns into a data security problem almost immediately.

AI agents do not stay confined to identity platforms. Instead, they connect to databases, data warehouses, SaaS applications, internal APIs, document repositories, vector databases, and knowledge systems. Once connected, the key question shifts: not whether the identity exists, but what it can access.

For example, a document summarizer may need internal policies but not regulated customer records. Similarly, a support assistant may require historical tickets but not raw payment data. In the same way, a data-analysis agent may only need aggregated metrics, not live production tables with personal identifiers.

Problems begin when these boundaries blur. During testing, teams often grant broad read access to avoid friction. The agent works, momentum builds, and the project expands. However, permissions rarely get tightened. As new datasets connect, a tool built for convenience quietly turns into an access path to sensitive data.

There is no dramatic breach moment. No flashing red screens or cinematic hacker nonsense. Instead, a valid identity runs valid queries against data it should never have been able to reach.

Authentication Only Proves the Door Opened

Most organizations can prove that a non-human identity authenticated successfully. That is useful, but it is not control.

Authentication shows the key worked. However, it does not prove the room should have been entered. Nor does it explain why a service account accessed a sensitive column, why an agent-driven workflow queried production data outside normal hours, or why a credential created for one system suddenly appears in another.

This is where identity governance begins to break down. IAM systems handle assigned permissions well. In contrast, they struggle to explain whether real behavior still matches the original business purpose. That gap becomes dangerous as AI agents operate continuously, retrieve context dynamically, and trigger chained actions across systems.

For human users, a manager might spot when an entitlement no longer makes sense. With non-human identities, ownership is often vague. The creator may have left, the team may have changed, and the application may have been renamed or retired. Meanwhile, the credential — because credentials are immortal little nightmares unless someone kills them — may still be active.

The Lifecycle Problem Is Where the Rot Starts

The hardest part of non-human identity governance is not creation. Creation is easy — usually too easy. Instead, the real challenge lies in ownership, review, expiration, and retirement.

Every non-human identity that can access sensitive systems should have a clear owner, defined purpose, approved scope, expected behavior, and a review schedule. This sounds obvious until someone asks who owns the service account created during a proof of concept six quarters ago.

AI agents make lifecycle governance harder because their purpose drifts. A workflow that starts as a narrow assistant can evolve into a general automation layer. A retrieval agent may connect to more repositories, while a tool-calling agent gains access to additional APIs. At the same time, service accounts often retain permissions long after the workflow changes.

This drift creates the real risk. Not every dangerous identity starts dangerous. Instead, many become dangerous because no one revalidates what they can access as the environment evolves.

What This Looks Like in Practice

Consider a common scenario. A company deploys an AI assistant to help employees summarize internal documents. The project team creates a service account so the assistant can retrieve content from a knowledge base. During testing, the account receives broad read permissions to reduce friction and speed up iteration.

Initially, everything works. Users like the assistant, and more repositories get connected. Later, a customer-data store is added for a separate analytics project. However, because permissions were never narrowed, the assistant can now retrieve records that were never part of the original use case.

No exploit is required. An attacker does not need to break into the database. Instead, the agent only needs an overprivileged identity and a workflow that asks the wrong question.

From the identity platform, the access appears legitimate. From the application layer, the workflow looks successful. From a data-security perspective, however, the organization has created an unmanaged path to sensitive information.

Runtime Behavior Matters More Than Configuration Intent

Configuration shows what an identity should do. Runtime monitoring reveals what it actually does — and that is where the real problems surface.

For AI-era non-human identity governance, teams must observe data access in context. For example, which service accounts query sensitive fields? Which agent workflows touch production databases? Which identities suddenly increase query volume? Which credentials access data outside expected patterns? Which machine accounts remain active without a clear workflow?

These are not abstract governance concerns. Instead, they determine whether an organization can detect misuse before it turns into data exposure, compliance failure, or a very expensive incident report dressed up for the board.

What Security Teams Should Do Now

The practical response is not to panic-ban AI agents. That is how organizations create shadow AI and then act surprised when employees route around them. The better response is to govern non-human identities as live access paths to data.

• Build an inventory of service accounts, workload identities, API keys, automation credentials, and AI agent identities that can access sensitive systems.
• Assign ownership for every non-human identity with meaningful data access.
• Define the intended purpose and expected behavior for each identity, not just its technical permission set.
• Review access regularly, especially after AI workflows expand or new datasets are connected.
• Monitor actual database activity so overprivileged or drifting identities become visible.
• Mask sensitive data where AI workflows do not need raw values to complete the task.
• Retire stale credentials before they become somebody else’s foothold.

This is not glamorous work. It is worse: necessary. And in security, necessary work usually loses budget arguments until the first incident proves it should have been funded six months ago.

The RSAC 2026 Takeaway

RSA Conference 2026 did not introduce non-human identity as a new concept. What it did was make the consequences harder to ignore.

AI agents are turning machine identities into active participants in business workflows. Active participants need boundaries, ownership, monitoring, and evidence. It is no longer enough to know that a credential exists or that authentication succeeded. Security teams need to know what that identity can access, what it actually accessed, whether the behavior matches its purpose, and how quickly they can respond when it does not.

That is where the data layer becomes critical. Identity governance can define access. Data-layer monitoring can validate behavior. Discovery can show which systems contain sensitive information. Masking can reduce unnecessary exposure. Audit trails can prove what happened after the fact.

DataSunrise is relevant because it sits at that control point. With activity monitoring, sensitive data discovery, data audit, dynamic data masking, and compliance-focused controls across databases, cloud data stores, and distributed environments, DataSunrise helps organizations see and limit what non-human identities are doing where the risk becomes real: around the data itself.