HiddenLayer’s $100M Series B signals tighter AI runtime security

At a glance

What this is: HiddenLayer's funding announcement argues that AI security must move from build-time assurances to runtime protection as enterprises deploy agentic and generative systems.

Why it matters: For IAM, PAM, NHI, and AI governance teams, the implication is that approval, tool use, and action boundaries for AI systems need continuous verification, not one-time policy definition.

Context

AI runtime security is the control problem that emerges when models do more than generate text and start taking actions through tools, code, and connected systems. In that environment, static policy design does not tell you whether an AI system is behaving within its intended scope.

This matters because agentic systems blur the line between application logic and privileged execution. For identity and access teams, the governance question is no longer only who can access the AI platform, but what the AI can do once it is allowed to act, and how those actions are observed, bounded, and revoked.

HiddenLayer's announcement sits in a part of the market where runtime oversight is becoming a baseline expectation rather than an optional control tier.

Key questions

Q: What fails when AI agents are only governed at design time?

A: Design-time controls can define intended behaviour, but they do not prove what an agent will do once tools, prompts, and external data interact in production. The failure is that unsafe tool use, over-broad delegation, and unexpected actions only emerge at runtime, when the system is already acting. Security teams need live enforcement and observability, not policy documents alone.

Q: Why do AI agents increase privilege risk even when logs exist?

A: Logs record what happened, but they do not stop a privileged agent from taking an irreversible action before review. If the agent can chain requests quickly, the governance problem is not visibility alone. The risk comes from granting access too early and leaving it available for whatever the agent decides to do next.

Q: How do teams know whether AI runtime enforcement is actually working?

A: Look for low-latency enforcement, consistent decisions across languages and encodings, complete telemetry, and repeatable blocking of risky content under load. A strong signal is that the control behaves the same in production-like conditions as it does in a lab, without creating user-visible pauses or blind spots.

Q: Should organisations treat AI-driven exposure as a data governance issue or an identity issue?

A: They should treat it as both, but data visibility should come first because identity controls need a known asset to protect. The better model is to connect DSPM, DAG, IAM, and PAM so exposure, entitlement, and privilege are evaluated together.

Technical breakdown

Why runtime controls matter for agentic AI identity

Agentic AI systems can decide when to invoke tools, pass context, and trigger actions without a human approving every step. That makes them unlike ordinary applications, because the security boundary is not just authentication at login but authorization at execution time. In practice, the important control question is whether an agent is still operating inside the identity, permissions, and task scope it was granted. Runtime security watches the live behaviour, not just the configured policy. That is especially relevant where AI agents can create tickets, modify code, query data, or call downstream services on behalf of users or processes.

Practical implication: monitor AI agent actions continuously and treat each tool invocation as a governance event.

How AI coding agents expand the privilege problem

AI coding agents are security-relevant because they sit directly in development and delivery workflows, where small permission gaps can become production risk. If an agent can write code, review changes, or ship artifacts, then the question is not only whether it is authenticated, but whether its delegated authority is limited to the exact task, environment, and repository it needs. Runtime misuse can include over-broad tool access, unauthorized code changes, or indirect execution through chained prompts and integrations. That is an identity and privilege problem as much as it is an AI problem.

Practical implication: scope coding-agent access to task-specific permissions and separate it from human admin pathways.

Why design-time AI governance is not enough

Design-time controls matter, but they cannot fully anticipate how a system will behave once models, tools, and orchestration layers interact under live conditions. AI systems can be manipulated through inputs, context, or tool selection in ways that only become visible during execution. That is why runtime observability is increasingly central to AI governance: it exposes whether the system is using the right tools, crossing intended boundaries, or taking actions that policy never explicitly approved. In governance terms, runtime is where intent is tested against behaviour.

Practical implication: pair policy review with runtime detection, alerting, and intervention for unsafe AI actions.

Threat narrative

Attacker objective: The objective is to turn the AI system's delegated authority into uncontrolled execution that affects code, data, or connected services.

1. Entry occurs when an AI system is connected to tools, code repositories, or enterprise services that expand what it can touch.
2. Credential or authority abuse follows if the agent inherits more access than the task requires, allowing tool misuse or unauthorized actions.
3. Impact lands when the agent makes unsafe changes, manipulates downstream systems, or executes actions that should have been blocked at runtime.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime governance is now the decisive control plane for agentic AI. Once AI systems can select tools and act inside enterprise workflows, design-time safeguards stop being sufficient. Security teams must govern what the system does while it is live, not just what it was intended to do at build time. That shifts the centre of gravity from model policy to operational enforcement, which is where identity, privilege, and auditability converge for practitioners.

AI coding agents create a new privilege boundary that traditional application security does not model well. A coding agent that can write, review, and ship code is not just a developer aid, it is a delegated actor with access that can alter production outcomes. That makes the agent's identity and scope a governance issue, especially where human reviewers assume they are the only meaningful approval layer. Practitioners should treat agent authority as separately bounded from human access.

Agentic AI security is becoming a named category because the failure mode is no longer hypothetical. HiddenLayer's funding round reflects market recognition that runtime behaviour, tool use, and action approval are the real control surface. This is a named concept worth tracking as runtime AI trust gap: the difference between a model that appears safe in design and a system that remains safe when it acts. Security programmes should measure that gap directly.

Identity governance for AI must extend beyond authentication to delegated action control. The central question is not whether the agent signed in, but what authority it exercised after sign-in and whether that authority stayed task-scoped. That is where agentic AI intersects with IAM and NHI governance in practice: ephemeral permissions, tool grants, and execution oversight become the real risk boundary. Practitioners should align AI controls with delegated authority, not just access admission.

Investor capital is following a real governance gap, not a marketing cycle. The size of the round signals that the market is converging on runtime protection as the next battleground in AI security. For practitioners, that means procurement, architecture, and risk discussions should assume that agent oversight will need to sit alongside identity controls, not underneath them. The programme implication is simple: if the system can act, it needs continuous supervision.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime AI trust gap: enterprises are now confronting the difference between an AI system that looks safe in policy and one that remains safe while acting. That gap is where agentic risk concentrates, because tool use, context inheritance, and delegated authority can change faster than review cycles can keep up. Security programmes should move control points closer to execution and away from static approval alone.

The 13% preparedness figure should be read as a governance warning, not a maturity score. If organisations cannot say whether AI-related breaches have occurred, then auditability, escalation paths, and incident handling for AI actions are still incomplete. Practitioners should assume the AI control plane will need the same operational discipline as identity and privilege management.

For teams already building AI oversight, the next step is to connect runtime enforcement to existing identity controls rather than creating a separate AI-only process. That means aligning agent permissions, observability, and revocation with IAM and PAM workflows where they already exist, and then extending them to the new AI execution layer.

For practitioners

• Define runtime approval boundaries for AI agents Specify which tool calls, code actions, and data operations require live enforcement rather than pre-approved policy alone.
• Separate coding-agent authority from human developer access Create distinct access scopes for autonomous coding agents so they cannot inherit broad repository, deployment, or admin permissions from human roles.
• Instrument agent behaviour for audit and intervention Log tool use, output-to-action transitions, and blocked requests so security teams can detect misuse while the agent is operating.
• Map AI governance to delegated privilege decisions Document where AI systems are allowed to act on behalf of people or services, then review those delegations as part of access governance.

Key takeaways

• AI security is moving from static assurances to runtime enforcement as organisations deploy systems that can act through tools and code.
• HiddenLayer cites a market signal in which nearly a third of organisations cannot say whether they have had an AI-related breach, underscoring how weak visibility still is.
• The practical response is to govern delegated AI action the same way identity teams govern privilege, with live enforcement, auditability, and revocation.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and identity practitioners translate delegated access into operational controls across modern environments.