Are AI agents already operating inside our enterprise, even if we didn’t deploy an ‘agent platform’? → Yes; agents show up across browsers, endpoints, SaaS, and cloud where teams already run AI programs.
What is the dominant signal this week that changes engineering priorities? → Onyx Security raised $113 million to build a Secure AI Control Plane focused on discovering agents and inspecting actions before they happen.
What is the primary search question we should be answering as CTOs and security leads? → How do we discover and control AI agents across enterprise environments without slowing adoption?
What actually breaks in production: the model, or the system around it? → In practice it’s the action boundary: the moment an agent touches a browser, an endpoint, a SaaS workflow, or cloud resources.
What’s the practical move this quarter? → Treat agent governance as a control-plane architecture decision, not a prompt-engineering project.
Quick Answer: how do we control AI agents across enterprise environments?
If agents are acting across browsers, endpoints, SaaS, and cloud, the only scalable way to govern them is an enterprise control plane that can discover agents and inspect each action before it executes, then block, correct, or route the action to a human approval path when risk is high. The central engineering shift is that governance must sit at the action layer, not in the model layer, because production failures propagate through workflows and permissions faster than any prompt guardrail.
Onyx’s $113M raise is a category bet: ‘agent control plane’ becomes mandatory infrastructure
Onyx Security raising $113 million for a Secure AI Control Plane is a strong signal that enterprises are no longer debating whether agents belong in the business; they’re debating whether they can keep control as agents take on more tasks. We think a reasonable engineer could disagree on timing, but not on the direction: once agents operate across browsers, endpoints, SaaS, and cloud, governance stops being a feature inside an app and becomes shared infrastructure.
| Market signal from this week | What it implies for engineering leaders | The decision it forces this quarter |
|---|---|---|
| Onyx Security raised $113M Series B (total funding $153M) | Investors expect agent governance to be a platform, not an add-on | Decide whether to build governance plumbing or buy a control plane |
| Secure AI Control Plane positioned around discovering agents | You can’t govern what you can’t enumerate | Establish an ‘agent inventory’ across browser/endpoint/SaaS/cloud |
| Inspecting every action before it occurs | Runtime mediation is becoming the enforcement point | Design systems for block, correct, or human approval at action-time |
| Focus on critical infrastructure sectors (energy, financial services, healthcare) | Risk tolerance is driving adoption patterns | Prioritize highest-blast-radius workflows first |
The central claim: agent failures happen at orchestration boundaries, so you need action mediation
Our central claim is simple and arguable: as enterprises become agent operators, the most dangerous failures will not come from a model ‘saying the wrong thing,’ but from an agent performing the wrong action across real systems at production speed, which breaks traditional app-by-app security and requires a control plane that inspects and mediates actions before they execute. The right response isn’t to endlessly swap models; it’s to architect governance around discovery plus pre-execution inspection.
- Model guardrails don’t see real permissions. A model can be aligned while the agent still has OAuth tokens, endpoint access, or cloud roles that make a bad action possible.
- Agent sprawl is normal, not exceptional. When agents operate across browsers, endpoints, SaaS, and cloud, ‘unknown agents’ are an expected operational state.
- Production speed is the risk multiplier. In energy, financial services, and healthcare, the blast radius of a single wrong action is outsized because execution is fast and downstream systems are real.
- Governance must be centralized to scale. If every product team invents its own approval and blocking logic, your enterprise becomes an inconsistent policy surface.
- Discovery is the first control. A control plane that can discover agents and then inspect their actions is the architectural prerequisite for enforcement.
Why ‘discovering AI agents’ is not an inventory problem, it’s a runtime reality
Onyx frames the environment accurately: agents already run across browsers, endpoints, SaaS, and the cloud, which means ‘what counts as an agent’ is not limited to one vendor’s platform. In practice, discovery is not a one-time CMDB exercise; it’s ongoing detection of where autonomous or semi-autonomous workflows exist, which identities they use, and what actions they attempt. If you can’t continuously map that surface, enforcement becomes guesswork.
| Environment where agents operate (per Onyx) | What ‘discovery’ usually has to answer in that environment | The trade-off you’ll face |
|---|---|---|
| Browsers | Which workflows are being executed through web sessions and what actions are being attempted | Visibility can be broad, but interpretation of intent is hard |
| Endpoints | Which local actions are being triggered and under what user or service context | Control is strong, but risk of disrupting legitimate workflows is real |
| SaaS | Which business processes are being automated and which accounts they run under | Coverage is valuable, but integrations can fragment across apps |
| Cloud | Which sessions are attempting operational actions and with what privileges | Central policy is possible, but policy design must reflect real operations |
Pre-execution inspection changes the contract between agent apps and enterprise security
The most important technical detail in the signal is that Onyx’s platform inspects every action before it occurs and can block, correct, or forward actions to a human for approval. That is a different enforcement model than post-hoc logging or after-the-fact review, and it changes how we design agentic systems: we must assume that every meaningful action can be intercepted, evaluated, and either allowed, modified, or escalated. The trade-off is latency and user experience versus control, but the alternative is invisible automation.
- Block is a production control, not a policy statement. Blocking has to be consistent under load, or teams will bypass it when the system is busy.
- Correct implies deterministic transformation. If an action can be ‘corrected,’ your enterprise must define what correction means in operational terms, not in vague ethics language.
- Human approval is a workflow, not a button. Forwarding actions to humans requires identity, routing, and an audit trail that can stand up in regulated reviews.
- Real-time inspection shifts failure modes. When enforcement happens before execution, outages can look like ‘agent can’t do its job,’ not ‘system is compromised,’ and that changes incident response.
- Adoption pressure will fight governance. Any enforcement that feels like friction will get worked around unless it’s designed into the runtime path.
The numbers that matter: 1.1M agents and 66M sessions signal operational scale
Onyx says it secures more than 1.1 million agents for customers and inspects more than 66 million AI sessions in real time. We don’t treat vendor numbers as universal proof, but we do treat them as a design constraint: if your governance approach cannot handle ‘many agents, many sessions,’ then it is a pilot architecture, not a production architecture. A control plane approach is inherently about throughput, policy evaluation efficiency, and clean failure behavior.
| What Onyx reports doing | What that forces you to plan for internally | The engineering trade-off |
|---|---|---|
| Securing more than 1.1 million agents | Governance must be multi-tenant across teams and business units | Central policy vs local autonomy |
| Inspecting more than 66 million AI sessions in real time | Enforcement must be operable at high event rates | Rich evaluation vs predictable latency |
| Inspect every action before it occurs | You need clear allow/deny/escalate semantics | Control vs user experience |
| Build proprietary models to monitor intent and reasoning | You must decide how much to rely on ‘intent inference’ | Interpretability vs coverage |
If you’re choosing models instead of governance, you’re optimizing the wrong layer
Many teams respond to agent risk by focusing on model choice, model alignment, or prompt constraints. That work matters, but it is not where the highest-severity enterprise failures originate once agents can touch browsers, endpoints, SaaS, and cloud. The engineering truth is uncomfortable: even a well-behaved model can produce an operationally dangerous outcome if the orchestrator routes it into privileged actions without inspection and escalation paths. That’s why control planes are emerging.
- Prompts don’t encode your real org chart. Your approval policies reflect business authority, not linguistic constraints, and those need runtime enforcement.
- LLM ‘reasoning’ isn’t an audit trail. Enterprises need evidence of what action was attempted, under what identity, and what policy allowed it.
- Agent speed outpaces manual review by default. If governance is bolted on after the workflow, it becomes a backlog of logs, not control.
- The hardest bugs are cross-system. The moment an agent spans SaaS plus cloud plus endpoint activity, the failure is compositional, not local.
What a Secure AI Control Plane changes in your stack this quarter
The practical implication is that agent governance becomes a shared platform capability, similar to identity or network policy, rather than a per-application effort. If Onyx’s framing is right that every enterprise is becoming an agent operator, then platform teams must decide where enforcement lives: in the app, in the runtime, or in a centralized control plane that can see actions across browsers, endpoints, SaaS, and cloud. For most enterprises, the scalable move is centralization, even if it means reworking how agent teams ship.
In critical infrastructure sectors like energy, financial services, and healthcare, the urgency is not theoretical. When a single wrong decision by an agent at production speed can cause an outage, market disruption, or put a life at risk, the architecture must assume high-stakes actions are attempted continuously. That pushes governance from ‘compliance documentation’ into ‘runtime system design.’
- Central policy becomes an engineering artifact. Policies have to be versioned, testable in staging-like environments, and deployable without breaking operations.
- Identity and session context become first-class inputs. If inspection is real time, you need reliable mappings between sessions and enterprise identities.
- Approval paths must be operationally staffed. If you forward actions to humans, someone must be on-call for business-critical workflows.
- Agent teams inherit platform constraints. Governance is not optional per team; it becomes a baseline contract for production access.
‘Block, correct, or human-approve’ is a product requirement, not a security checkbox
Onyx’s triad of responses—block, correct, or forward to a human—maps directly to how real enterprises operate under pressure. Blocking is necessary for clear violations, correction is useful when you can safely constrain an action into a permitted form, and human approval is essential when the enterprise needs accountability. The architectural challenge is that these paths must feel natural inside workflows, or adoption slows and teams route around the control plane.
At Plavno, when we design AI automation around high-risk operations, we treat the approval path as part of the user experience and the blocking path as part of reliability engineering. The best governance system is the one engineers and operators trust: predictable, explainable, and consistent under load, even when the model behaves unexpectedly.
A control plane that inspects actions before they occur must fail safe by design; if your enforcement layer fails open under stress, it becomes a compliance prop, and if it fails closed without graceful degradation, it becomes an outage generator.
Where agent control planes actually sit: browsers, endpoints, SaaS, and cloud are four different seams
Onyx explicitly names the surfaces where agents run: browsers, endpoints, SaaS, and cloud. That matters because each surface has different identities, different telemetry, and different failure modes. A control plane that pretends all actions are the same will either over-block and create operational friction or under-block and create unacceptable risk. The right mental model is ‘policy plus context,’ where context includes where the action happens and what systems it touches.
Enterprises also need to accept that agents don’t respect org boundaries. A single workflow can start in a browser, pivot through SaaS, and end in a cloud operation, which means enforcement cannot be purely local. The trade-off is complexity: you’re building cross-domain governance, but you’re also reducing the most dangerous class of failures—those that only appear when systems compose.
If you can’t correlate an agent action across browser, endpoint, SaaS, and cloud contexts into one auditable chain, you will miss the failures that actually matter.
Browsers are becoming an agent runtime, not just a UI layer
When agents operate ‘across browsers,’ that usually means they can act through web sessions where human context and machine automation blur. The governance risk is that a browser session can trigger business actions that are hard to distinguish from normal work, especially when the same SaaS tools are used by humans and agents. Pre-execution inspection helps only if you can reliably attach identity and intent to the session so that policy is enforced consistently.
Discovery without attribution is noise: you need to know which agent, under which identity, attempted which action, or your control plane becomes a dashboard instead of a governor.
Cloud session inspection forces you to define ‘intent’ as an operational concept
Onyx plans to build proprietary AI models designed to monitor agents’ intent and reasoning, and that highlights a real engineering tension: intent is not a philosophical concept in production, it’s something you must translate into enforceable categories. In cloud environments, actions are often powerful and generic, so the same operation can be legitimate in one context and catastrophic in another. If your organization can’t define intent in a way that maps to allow, block, correct, or escalate, you will either create brittle controls or none at all.
| Real enterprise scenario | What ‘inspect before action’ needs to decide | What can go wrong if you get it wrong |
|---|---|---|
| Agent operates through a browser session into a SaaS workflow | Is this action allowed under this identity and context, or should it be escalated? | Over-blocking causes workarounds; under-blocking causes unauthorized business operations |
| Agent triggers endpoint activity as part of an automated task | Should the action be blocked, corrected, or approved by a human? | Endpoint disruptions or invisible automation that bypasses human intent |
| Agent spans SaaS and cloud operations in one flow | Can we treat the chain as one governed session? | Loss of end-to-end auditability and fragmented policy decisions |
| High-stakes sector workflow (energy, financial services, healthcare) | Does this require human approval because the blast radius is severe? | Outage, market disruption, or human harm from an unchecked action |
Plavno’s position: governance is product engineering plus security, not ‘security theater’
The Onyx narrative—that the round is about control as agents take on more tasks—matches what we see in enterprise delivery: once agentic workflows exist, the organization must decide whether governance is a platform product or a set of guidelines. Our position is that guidelines don’t survive quarterly delivery pressure; only enforced architecture does. That’s why we frame agent governance as a product engineering problem with security constraints, not as an after-the-fact security review.
This is where AI consulting becomes practical rather than abstract. You need cross-functional design that includes platform engineering, security, and the teams shipping agentic experiences, because the enforcement layer changes user experience, incident response, and release management all at once.
Define what counts as an agent in your org, using the reality that agents can operate across browsers, endpoints, SaaS, and cloud.
Decide which actions are ‘never automatic,’ which can be corrected, and which can be blocked outright, based on the actual workflows that touch critical systems.
Establish an approval workflow that has real routing, identity verification, and operational coverage, so escalations don’t become a dead letter queue.
Choose where you want enforcement to live: app-by-app logic, shared libraries, or a centralized control plane that can mediate actions in real time.
Commit to continuous discovery, because the set of agents and sessions will change faster than policy documents.
If your governance design can’t answer ‘who approved this action, and what exactly was approved’ in one sentence, you don’t have governance—you have hope and logs.
How we evaluate control-plane vendors in regulated sectors without getting trapped by demos
Onyx focuses on energy, financial services, and healthcare, and that focus is rational: these environments punish false negatives harshly. But vendor selection here isn’t about which dashboard looks best; it’s about whether the control plane can be integrated into enterprise realities without breaking operations. That means asking how the system discovers agents, how it inspects actions before they occur, and how it behaves when the enterprise is under load or partial outage.
At Plavno we pair architecture review with cybersecurity and penetration testing because agent control planes become high-value infrastructure. If an attacker can influence the enforcement layer or its approval workflow, they can often scale impact faster than by attacking a single app.
Validate discovery in your environment by mapping where agents operate today: browsers, endpoints, SaaS, and cloud, then checking whether the control plane can see that surface consistently.
Test pre-execution inspection on real workflows and confirm it can block, correct, or forward actions to humans without collapsing user experience.
Stress the approval path: confirm escalations are attributable, auditable, and operationally supportable when humans are busy.
Audit failure behavior: determine whether the system fails safe in ways that match your sector’s risk posture.
Pressure-test intent monitoring expectations, since vendors may use proprietary models to interpret intent and reasoning, and you need operational definitions, not marketing.
What real deployments look like in Fortune 500 environments—and why sectors matter
Onyx says the Fortune 500 customers it works with are setting the pace for how agent governance is rolled out in practice, and that aligns with what we see: large enterprises tend to start governance where the stakes are highest, then expand outward once the policy and approval mechanics work. The sectors Onyx calls out—energy, financial services, and healthcare—are the ones where a wrong decision at production speed isn’t a minor bug; it’s a systemic event.
In regulated environments, the winning pattern is to start with the smallest set of actions that carry the highest irreversible risk, then expand coverage only after the approval and audit trail are operationally boring.
Closing: the teams that win will audit actions, not prompts, as agents scale
Onyx’s funding and product direction point to the same operational truth: enterprises are becoming agent operators whether they planned to or not, and the control problem is now about runtime actions across browsers, endpoints, SaaS, and cloud. Our view at Plavno is that the ‘right’ governance strategy is the one that can intercept and decide on actions before they happen, because that is where outages, market disruption, and real-world harm are created.
Author: Plavno team. Last updated: July 2026.
Chat GPT 
Perplexity 
Claude 
Gemini 
