Cyera’s $600 million round signals trust-layer demand for AI governance

At a glance

What this is: Cyera’s funding round is framed around a trust layer for enterprise AI, with the key finding that most organisations still cannot distinguish human from AI agent activity inside their own systems.

Why it matters: IAM, data security, and agent governance teams need to treat AI visibility as a control-plane issue because programmes cannot govern what they cannot separate, scope, or audit.

By the numbers:

• 68% of organisations cannot distinguish human from AI agent activity inside their own systems.
• Cyera raised $600 million at a $12 billion valuation.
• Cyera shipped more than 100 new product capabilities across DSPM, privacy, identity, DLP, and agentic security.
• Cyera has grown to more than 1,500 employees across 18 countries.

Context

AI governance fails when organisations cannot reliably tell whether activity comes from a person or an agent. In that state, access policies, audit trails, and data controls lose precision because the actor behind the action is ambiguous before the control decision is even made.

Cyera’s funding round is positioned around that gap: a trust layer for what AI can see and do. The practical issue for identity teams is not model intelligence, but whether governance can separate human intent from machine execution, then bind the right controls to each.

The company’s article ties that problem to enterprise-scale AI adoption rather than to a single product feature. That makes the story relevant to NHI, agentic AI, and data governance programmes that are trying to operate across the same control boundary.

Key questions

Q: How should organisations govern AI agents alongside human identity and device access?

A: Organisations should treat AI agents as a separate identity class with their own entitlement boundaries, logging expectations, and approval model. Human IAM controls often assume interactive sign-in and review cycles, which do not fit autonomous or programmatic access. The safer approach is to define actor-specific policy and verify which access paths can be delegated without expanding trust unnecessarily.

Q: Why do AI security programs need both data controls and identity controls?

A: Because data controls show where sensitive information lives, while identity controls determine who or what can reach it. In AI environments, a workflow may expose data simply by having a valid service account or API token. If those entitlements are broad or poorly owned, data posture tools will identify risk without constraining it.

Q: What are the signs that AI access controls are too weak for sensitive enterprise data?

A: Weak controls usually show up when teams cannot easily see where AI is being used, what data it can reach, and who can invoke it. Other warning signs are unregulated training inputs, uncontrolled output generation, and external users or plugins retaining access beyond their intended scope. Those gaps make accidental disclosure and misuse much more likely.

Q: What happens when AI systems are granted static permissions for dynamic work?

A: Static permissions can over-grant because they assume the actor’s needs are stable, but AI tasks often change scope mid-session. The result is permission drift, poor explainability, and weak accountability when the system crosses from analysis into action. Organisations should treat that as a governance failure, not a tuning issue.

How it works in practice

Why human-versus-agent visibility changes the control model

When organisations cannot distinguish human activity from AI agent activity, the control question shifts from simple authentication to actor attribution. Identity systems can authenticate a session, but governance still needs to know whether the session is being driven by a person, a delegated workflow, or an autonomous runtime. That distinction affects policy enforcement, logging, and review. Without it, approval, access, and data handling controls become ambiguous at the exact point they need to be precise. For enterprise AI, attribution is not a reporting feature, it is the basis for control selection.

Practical implication: classify activity by actor type before you bind permissions, logging, and escalation rules.

How a trust layer combines DSPM, identity, and behaviour

A trust layer for AI governance is not just data discovery. In Cyera’s framing, it sits across DSPM, identity, DLP, and agentic security so the organisation can determine what the AI can reach, what it can infer, and what it can do. That matters because data exposure is often a function of identity scope plus behavioural context, not only file location. If those signals stay separate, teams get partial control and false confidence. Convergence is the real design requirement here.

Practical implication: align data classification, identity scope, and behavioural monitoring in one operating model.

Why agentic security changes the boundary of least privilege

Agentic systems do not only consume data, they may choose actions within runtime constraints. That means least privilege has to account for dynamic behaviour, not just pre-assigned access. A static role model can describe what an agent should not do, but it may not capture what the agent is able to infer, chain, or request in-session. Once action scope is runtime-dependent, governance needs controls that evaluate context as well as entitlement. This is where traditional access policy starts to underfit the problem.

Practical implication: review whether your privilege model can express runtime constraints, not only static entitlements.

NHI Mgmt Group analysis

AI governance is now an actor-classification problem, not only a data problem. Cyera’s own numbers point to a basic failure of attribution: many organisations cannot separate human action from AI agent action inside their environments. That means the first governance question is who or what is acting, before any policy, access, or data decision can be trusted. The implication is that identity programmes must treat actor typing as a control prerequisite, not an afterthought.

The trust layer is the new control plane for enterprise AI. Cyera’s framing shows that data visibility alone is insufficient unless it is joined to identity scope and behavioural context. DSPM can tell you where sensitive data sits, but AI governance also needs to know which identities can reach it and what those identities can do with it. Practitioners should therefore evaluate whether their current stack can enforce decisions at the intersection of data, identity, and action.

Ephemeral AI behaviour creates trust debt where static IAM assumptions once worked. Least privilege was designed for identities whose scope is stable enough to provision, review, and recertify. That assumption weakens when the actor is an AI system whose tool use, data reach, and execution path can shift inside a task. The implication is not just more controls, but a different governance premise for runtime access.

Named concept: trust-layer governance. This article sharpens the idea that AI governance now needs a layer that governs what the system can see, infer, and do across identity and data boundaries. That concept matters because it reframes AI security as infrastructure, not policy decoration. Teams that still separate data governance from identity governance will miss the control boundary where AI risk actually accumulates.

Market consolidation is following the governance gap. The funding, acquisitions, and capability expansion described here signal that buyers are looking for convergence across DSPM, identity, DLP, and agentic security. That is a strong indicator that fragmented point controls no longer match enterprise AI risk. Practitioners should expect platform buying criteria to shift toward cross-domain governance coverage rather than single-control depth.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Agentic AI Identity Guide

What this signals

Trust-layer governance: AI programmes now need a control plane that joins identity, data, and behaviour instead of treating them as separate monitoring problems. If human and agent activity still collapse into the same telemetry, the organisation cannot enforce differentiated policy or prove accountability at runtime.

The immediate programme implication is that actor typing must move upstream of access decisions. Once teams can classify whether a workflow is human, non-human, or autonomous, they can stop building policies around assumptions that no longer hold and start governing what the system can see and do.

For practitioners

• Classify actor type before policy design Map each AI-facing workflow to human, NHI, or autonomous behaviour so access, logging, and review rules are applied to the right actor class.
• Unify identity and data scopes Tie sensitive-data classification to the identities and agents that can reach it, then verify that the resulting policy can be enforced at runtime.
• Test runtime privilege boundaries Check whether your current entitlements can describe what an AI system may infer, request, or execute during a live task, not just at provisioning time.
• Audit AI observability gaps Identify where logs, lineage, and access telemetry still collapse human and agent activity into the same record and fix those blind spots first.

Key takeaways

• The core problem is not AI capability alone, but the inability to distinguish human from agent activity well enough to govern it.
• That visibility gap breaks the link between data controls, identity controls, and accountability, which is why AI adoption stalls in practice.
• Enterprises need a trust layer that classifies actors, binds data access to runtime context, and makes access decisions observable.

Key terms

• Trust layer: A governance layer that sits between AI capability and enterprise data or actions. It combines identity, data classification, access control, and behavioural policy so organisations can decide what an AI system may see, infer, or do at runtime.
• Actor Typing: Actor typing is the practice of classifying activity by the identity class behind it, such as human, non-human, or autonomous. This matters because the right security control depends on whether a person, a workload, or an AI system is initiating the action.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.