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

At a glance

What this is: Cyera’s funding round is being framed as evidence that enterprises need a trust layer to govern what AI can see, learn from, and act on.

Why it matters: For IAM and security teams, the issue is no longer only access control, but whether current governance can distinguish human, machine, and agent activity well enough to enforce policy.

By the numbers:

• In 2026, 68% of organizations cannot tell the difference between human activity and AI agent activity inside their own systems.
• Cyera has 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 in the last 18 months.
• Cyera’s latest funding round totals $600 million at a $12 billion valuation.

👉 Read Cyera’s announcement on AI trust-layer funding and enterprise AI governance

Context

AI governance fails quickly when organisations cannot reliably distinguish human activity from AI agent activity. That is an identity problem first and a data-security problem second, because policy enforcement depends on knowing which subject is acting, what it can reach, and which decisions are being made at runtime.

Cyera’s funding announcement uses that gap to argue for a trust layer that spans DSPM, identity, DLP, and agentic security. The practical issue for IAM teams is not the valuation itself, but the growing expectation that access, context, and behaviour will be governed together rather than in separate control planes.

Key questions

Q: How should security teams govern AI systems that can access sensitive data?

A: Treat AI access as a joint identity and data-governance problem. Security teams need actor classification, data classification, and behavioural controls in the same decision flow so they can limit what the system can see, what it can infer, and what it can do with that information. Without that linkage, policy becomes too coarse to enforce in real time.

Q: Why do AI agents complicate existing IAM models?

A: AI agents complicate IAM because many controls assume a stable subject with predictable intent. An agent may act on behalf of a person or system while selecting data and actions dynamically at runtime, so the old access model no longer explains actual behaviour. That makes entitlement review, investigation, and exception management much harder.

Q: What breaks when organisations cannot distinguish human from AI agent activity?

A: Access governance loses precision immediately. If teams cannot tell whether a person or an agent triggered an action, they cannot certify access accurately, investigate incidents cleanly, or enforce policy with confidence. The result is not just weaker monitoring, but a control model that can no longer assign the right rule to the right actor.

Q: Who should own AI governance across identity and data controls?

A: Ownership should sit with the teams that can join identity, data, and security operations, not with a single product owner. AI governance spans IAM, DSPM, DLP, and monitoring, so accountability has to cover policy design, runtime enforcement, and post-incident reconstruction. Otherwise, each team assumes another layer will catch the gap.

How it works in practice

Why AI agent visibility breaks traditional access governance

Traditional access governance assumes the organisation can reliably attribute actions to a stable identity subject. In AI-heavy environments, that breaks down when systems can act on behalf of people, workloads, or agents in ways that look operationally similar. If security teams cannot distinguish human from agent activity, entitlement review, policy exception handling, and investigation workflows all lose precision. This is where identity context and data context start to converge, because access alone no longer explains risk. The control problem is not just who authenticated, but what kind of actor is actually making the decision.

Practical implication: build detection and governance logic that tags actor type before you rely on the resulting access event.

How DSPM, identity, and DLP converge in AI governance

DSPM discovers and classifies sensitive data, identity controls define who or what may reach it, and DLP constrains what leaves the environment. In an AI operating model, those three functions cannot stay siloed if agents can query, summarise, or move information at machine speed. A trust layer only works when policy can follow the data as it is accessed and transformed. That means the security model must join entitlement state, data sensitivity, and behavioural context in one decision path rather than treating them as separate reviews.

Practical implication: map your AI controls to a single governance flow that links classification, access, and exfiltration policy.

Why agentic security changes the identity perimeter

Agentic security extends the perimeter from human login events to software entities that can select actions and invoke tools. When agents are present, the question is no longer only whether authentication succeeded, but whether the runtime actor should be allowed to see, infer, or act on the data in front of it. That changes the enforcement model for least privilege, because runtime behaviour can outgrow the original access assumption. In practice, this pushes security teams toward continuous evaluation of AI behaviour and stronger containment around tool and data exposure.

Practical implication: review where AI systems can take actions beyond their original approval path and tighten those boundaries first.

NHI Mgmt Group analysis

Trust layers are becoming the new control plane for AI governance. The article reflects a broader shift in enterprise security: teams are no longer trying to secure AI as an isolated workload, but as an actor that crosses identity, data, and behaviour boundaries. That is why DSPM, identity, and DLP are being pulled into the same discussion. Practitioners should treat this as a sign that AI governance is consolidating around runtime control, not point tooling.

Visibility into actor type is now a prerequisite for meaningful policy enforcement. If an organisation cannot distinguish human action from AI agent action, then access review, exception handling, and incident triage all inherit that ambiguity. The failure is not simply missing telemetry. It is that the governance model cannot tell which subject class the policy should apply to, so the control decision itself becomes unstable. Practitioners should rework governance flows so actor identity is explicit before access is authorised or analysed.

Identity and data security are converging because AI turns access into an interpretation problem. A human or workload may only need access, but an AI system can extract meaning, combine context, and act on data in ways the original entitlement did not anticipate. That makes the boundary between who can see data and what the system can do with it much thinner. Practitioners should assume the next generation of identity controls will be evaluated on whether they can govern both reach and use.

Runtime governance is the named concept this announcement points toward. The article’s core message is not that enterprises need more security products, but that AI-era control depends on decisions made while the system is running. Static approval models were built for stable identities and predictable access paths. Practitioners should expect governance programmes to shift toward continuous, context-aware enforcement across AI, human, and machine actors.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• The governance answer is not to bolt on a single control, but to align AI access, identity, and data policy around runtime behaviour. See OWASP Agentic AI Top 10 for the agentic-risk model, then pair it with NHI Lifecycle Management Guide for lifecycle and access discipline.

What this signals

Runtime actor classification is becoming a programme requirement, not an architectural nice-to-have. If your controls cannot distinguish human, machine, and agent behaviour at the point of decision, then policy reviews, incident triage, and recertification will keep producing ambiguous outcomes. The practical signal is that IAM, DSPM, and security operations need shared actor metadata, not separate reporting dashboards.

The next maturity test is whether your AI controls can survive mixed-actor environments without losing auditability. A useful benchmark is whether you can reconstruct who or what touched a sensitive record, why it was reachable, and which policy path allowed it. That is the difference between governance theatre and enforceable control.

For practitioners

• Classify actor type before policy enforcement Update governance logic so each access event is tagged as human, machine, or AI agent before downstream decisions, investigations, or certifications run.
• Unify data and identity controls for AI use cases Join DSPM findings with entitlement data and DLP rules so sensitive records, access paths, and exfiltration conditions are evaluated in one workflow.
• Review AI tool reach against actual runtime behaviour Identify where AI systems can query, summarise, forward, or trigger actions beyond the approval path that was originally granted, then tighten those boundaries.
• Strengthen investigation readiness for mixed human and AI activity Make sure audit and response teams can reconstruct which actor initiated the action, what data was seen, and whether a model or human changed the workflow.

Key takeaways

• AI governance is shifting from model management to runtime control over what AI can see and do.
• The scale of the problem is already material, with most technology professionals treating AI agents as a growing and immediate security threat.
• Practitioners should align identity, data, and behavioural policy so actor type is explicit before access is granted or reviewed.

Key terms

• AI agent visibility: The ability to identify, attribute, and monitor what an AI system is doing inside enterprise environments. In practice, this means distinguishing agent activity from human or workload activity so access, audit, and response controls can be applied to the correct subject type.
• 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.
• Runtime governance: The control of access and behaviour while a system is actively operating, rather than only at design or provisioning time. For AI and machine identities, runtime governance is where actor type, data sensitivity, and policy enforcement have to meet in real time.
• Agentic security: The set of controls used to manage software entities that can choose actions, tools, and execution timing in ways that affect enterprise systems. It extends beyond static access control because the risk comes from what the agent can decide to do during execution.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Cyera: Cyera Raises $600 Million at $12 Billion Valuation to Continue Building the Trust Layer for the AI Era. Read the original.