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

At a glance

What this is: HiddenLayer’s $100 million Series B is a funding event built around the claim that agentic and generative AI now need runtime security, not just model-time safeguards.

Why it matters: For IAM, AI security, and governance teams, it highlights the growing need to treat AI systems as controlled runtime entities whose tool access, action scope, and auditability must be governed continuously.

By the numbers:

• HiddenLayer reports that 96% of organisations already consider AI critical to core operations.
• HiddenLayer says its annual recurring revenue grew more than 10x in the past year.

👉 Read HiddenLayer's announcement on its $100 million Series B for AI runtime security

Context

AI runtime security is the control gap that appears when models, agents, and coding assistants can act inside enterprise workflows without the same visibility and authorization discipline used for human users or workloads. In practice, the problem is not only model behaviour but also the tool access, execution timing, and downstream actions that agentic systems can trigger. This matters because AI attack surface now includes AI identities, secrets, and delegated access, not just prompts and outputs.

The funding story matters because it shows where enterprise risk appetite is moving: toward continuous monitoring of AI behaviour rather than relying on design-time assurances. That intersection with identity governance is real. When an AI agent can call tools, access data, or ship code, its privileges, lifecycle, and audit trail become identity problems as much as AI security problems.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do agentic AI systems create more risk when context is incomplete?

A: Because the system still has to decide whether a situation is real, expected, or safe to continue. If the model misclassifies its environment, it may rationalise harmful actions instead of stopping. That is why contextual grounding matters as much as policy enforcement in AI governance.

Q: What are the warning signs that an AI runtime security programme is failing?

A: Look for broad tool access, missing ownership for agents and connectors, weak audit trails, and AI actions that cannot be tied back to a clear task or policy decision. If you cannot answer what the agent accessed, why it accessed it, and who can revoke it, the programme is not controlling runtime risk.

Q: Should organisations use a dedicated AI agent identity model or extend current NHI controls?

A: Extend current NHI controls first, but only if they include ownership, scope, lifecycle, and revocation discipline. The mistake is treating AI agents as just another service account when they may combine permissions dynamically at runtime. A dedicated model is warranted when delegation chains span multiple applications and control ownership is unclear.

Technical breakdown

Why runtime controls matter more than design-time assurances

Design-time safeguards reduce some risk, but they do not constrain what an AI system does once it is live. Agentic systems can change behaviour based on context, retrieved data, and tool outputs, which means the security boundary moves from the model alone to the full execution path. Runtime controls therefore need to watch prompt injection, tool misuse, unauthorized actions, and data exposure in the moment they occur. In identity terms, the agent becomes a governed runtime principal that needs scoped permissions and continuous verification.

Practical implication: security teams should require runtime policy enforcement for any AI system that can access tools, data, or execution environments.

Agentic harness security and AI coding agents

Agentic harnesses are the surrounding systems that let coding agents read repositories, call APIs, execute commands, and produce code changes. That harness is where trust assumptions often break, because the agent may have broader effective access than any single human developer would receive. If approval, testing, and commit paths are weakly separated, an AI agent can become a high-speed path from instruction to code change. The identity issue is delegated access without enough lifecycle control, auditability, or revocation discipline.

Practical implication: teams should inventory every tool, repository, and secret an AI coding agent can reach and narrow that access to the smallest viable scope.

AI attack surface now includes delegated identity and secrets

The article describes a broader AI attack surface spanning discovery, supply chain, and runtime protection. That framing is important because AI security failures often involve exposed credentials, overbroad service access, or third-party integrations rather than model weakness alone. Once an AI agent inherits credentials or connector permissions, compromise can look like ordinary identity abuse even when the initial trigger is AI-specific. This is where NHI governance becomes essential: every agent, connector, token, and workload credential needs ownership, expiry, and revocation logic.

Practical implication: security teams should map AI systems to the same lifecycle controls used for NHIs, including registration, review, rotation, and offboarding.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI runtime into a high-privilege execution path for data exposure, code manipulation, or unauthorized operational change.

1. Entry begins when an attacker manipulates an AI system through hostile inputs, compromised tooling, or exposed agent credentials to influence its runtime behaviour.
2. Escalation occurs when the agent’s delegated access lets it call tools, retrieve data, or execute actions beyond the intent of the original user request.
3. Impact follows when the compromised AI path is used to expose sensitive data, alter code, or trigger unauthorized actions at machine speed.

NHI Mgmt Group analysis

Runtime AI governance is now an identity problem, not only an AI problem. Once an AI system can call tools, access data, or write code, it behaves like a non-human runtime principal with delegated authority. That means lifecycle, entitlement, and audit controls matter as much as model evaluation. Organisations that manage AI security separately from IAM will miss the real control plane.

Agentic harness security is the named failure mode this funding round underscores. The risky object is not just the model, but the harness that turns model output into privileged action. That harness often sits between human approval and machine execution, which creates a trust gap if tool permissions are broad or poorly monitored. Practitioners should treat that gap as a control boundary, not an implementation detail.

AI security will converge with NHI governance faster than many programmes expect. AI agents, connectors, service tokens, and automated workflows are already forming a machine identity estate. The question is not whether these identities exist, but whether they are registered, scoped, revoked, and reviewed with the same discipline applied to human access. That makes OWASP NHI Top 10 and AI governance frameworks complementary rather than separate.

Market demand is shifting from model trust to behavioural proof. Investors are backing platforms that can show what AI systems actually do at runtime, because trust claims without telemetry do not withstand real deployment. For security teams, that means controls must prove action scope, not merely assert policy intent. Continuous verification becomes the organising principle for trustworthy AI adoption.

Security teams should expect AI governance to inherit the same pressures that transformed cloud and workload identity. Once one privileged AI path is exposed, organisations will demand registration, inventory, and revocation for every similar path. The practical conclusion is simple: if an AI system can act on behalf of the business, it needs an identity model that can be governed, not just a model card that can be read.

What this signals

Agentic AI is forcing identity teams to extend governance beyond human users and traditional workloads. Once AI systems can hold credentials, call tools, and persist across sessions, they become part of the identity estate. That means policy owners will need clearer separation between human approval, workload privilege, and agentic execution paths, with lifecycle controls that match the speed of machine action.

AI governance debt will accumulate wherever teams treat runtime behaviour as an implementation detail. The practical problem is not just whether a model is safe in isolation, but whether the surrounding harness can be reviewed, constrained, and revoked. Security programmes that already struggle with secrets sprawl and service-account ownership will recognise the same failure pattern in agentic AI, only faster.

Organisations should expect NHI and AI security programmes to merge around shared controls for access, audit, and revocation. The same discipline used for machine identity inventory and secrets governance will increasingly apply to autonomous AI systems. For practitioners, that means prioritising the control points that prove who or what is acting, not just what the model was designed to do.

For practitioners

• Inventory AI runtime privileges List every tool, API, repository, database, and secret that each AI system can reach, then document whether access is read, write, or execute. This creates the control baseline for policy enforcement and audit.
• Separate approval from execution paths Ensure human review, policy checks, and code or data actions do not share the same implicit trust path. The goal is to prevent an agent from turning a suggestion into an unauthorized change without a distinct control point.
• Apply lifecycle controls to AI identities Register AI agents, connectors, and service accounts as governed identities with an owner, expiry, rotation rules, and revocation process. This closes the gap between deployment and offboarding that attackers often exploit.
• Monitor for anomalous tool use Alert on unusual command sequencing, repeated retries, unexpected data retrieval, or tool calls outside the agent’s normal task pattern. Pair those signals with session context so investigators can distinguish normal automation from abuse.
• Map controls to OWASP NHI and AI governance Use OWASP NHI Top 10 and NIST AI Risk Management Framework guidance to align agent privilege, access review, and runtime monitoring decisions. This helps unify identity and AI governance rather than treating them as separate programmes.

Key takeaways

• Agentic AI security is becoming a runtime governance problem because AI systems can now act, not just predict.
• The market signal is clear, with enterprise demand shifting toward controls that can prove and revoke AI behaviour at execution time.
• Identity teams should govern AI agents, connectors, and secrets as part of one lifecycle model rather than as separate risk domains.

Key terms

• Agentic runtime security: Agentic runtime security is the control layer that observes and constrains an AI agent while it is making decisions and taking actions. It focuses on execution-time behaviour, including tool calls, data access, and action sequencing, rather than only on prompts or static permissions.
• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• AI Identity Scope: The set of resources, tools, and credentials an AI system can access in order to complete a task. Proper scope is narrower than generic user access because autonomous systems can chain actions quickly, making overbroad permissions far more damaging than in human-only workflows.
• Runtime Verification: Runtime verification is the practice of checking what an identity is doing while it is active, rather than relying only on provisioning-time controls. For autonomous agents, it means monitoring prompts, tool use, outputs, and policy violations as actions unfold so harmful behavior can be contained early.

What's in the full analysis

HiddenLayer's full news post covers the operational detail this analysis intentionally leaves for the source:

• The announced funding allocation across Agentic Runtime Security, Agent Harness Security, and broader platform development.
• The customer growth, ARR expansion, and market traction details behind the round.
• The specific product capabilities referenced for securing autonomous coding agents at runtime.
• The company’s own description of where its research and patent portfolio intersects with AI security deployment.

👉 HiddenLayer's full post includes the funding details, product scope, and customer traction behind the round.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect agentic AI access decisions to the identity controls their programmes already need.