OX Security CNAPP Platform Brings Cloud Posture and AI Agent Runtime Defense Together

OX Security launched a CNAPP platform on September 16 that pairs established cloud controls with real-time monitoring for AI agents. The OX Security CNAPP platform, called OX Cloud, targets a security gap created when autonomous software gains identities, permissions, and access to enterprise tools.

The launch is not simply another expansion of a cloud-security feature list. OX is arguing that security teams need one graph connecting code, cloud configuration, identities, data, prompts, and live agent actions. That claim challenges both conventional CNAPP products and separate AI-security tools.

Palo Alto Networks and other large security vendors already offer runtime protection, AI posture management, and agent controls. OX must therefore prove that its prompt-to-runtime context creates better decisions, not merely a broader dashboard.

The central question is whether combining these signals helps defenders isolate reachable risks and unsafe agent behavior. If it does, OX Cloud could reduce the gap between discovering a cloud weakness and understanding how an autonomous system might exploit it.

The OX Security CNAPP Platform Extends Visibility Into Live Agent Activity

OX Cloud adds agent behavior to the infrastructure, identity, vulnerability, and data signals that cloud-security platforms already collect.

A cloud-native application protection platform, or CNAPP, combines several cloud-security functions within one system. These functions commonly include configuration monitoring, workload protection, entitlement analysis, vulnerability management, and attack-path mapping.

OX Cloud includes cloud security posture management, Kubernetes posture management, data security posture management, runtime vulnerability detection, cloud inventory, and graph-based attack-path analysis. The company is also adding AI Detection and Response, which it abbreviates as AIDR.

The difference sits in what OX wants the platform to observe. Conventional posture tools examine resources such as storage buckets, containers, identities, network paths, and access policies. OX Cloud also seeks to identify agents, models, prompts, and Model Context Protocol servers operating inside that environment.

MCP is a standard interface that lets AI systems connect with external tools and data. An MCP server might expose a database, file system, ticketing service, code repository, or internal API to an agent.

That connection gives an agent more utility, but it also turns model output into actions. A manipulated agent might retrieve restricted records, invoke an unapproved tool, or use a valid credential outside its intended workflow.

OX says its platform connects these actions with the surrounding cloud context. According to the company’s OX Cloud announcement, the product can inventory workloads, identities, data stores, Kubernetes clusters, and active AI agents.

The platform then uses reachability analysis to prioritize findings. Reachability determines whether an exposed component, vulnerable package, or excessive permission can actually connect to a valuable resource or execution path.

This approach matters because cloud scanners can produce long lists of technically valid findings. A vulnerable package inside an isolated workload does not present the same immediate risk as that package inside an internet-facing service with access to customer records.

OX applies that logic to agents. A questionable prompt or unusual tool call becomes more important when the responsible agent can reach production data, administrative APIs, or deployment systems.

The company also says OX Cloud can associate runtime activity with the prompt or code that initiated it. That connection could help investigators reconstruct why an agent took an action rather than merely recording that the action occurred.

These remain vendor claims. OX has described capabilities and product architecture, but it has not published comparative detection rates, false-positive measurements, deployment overhead, or independent evaluations for this launch.

That evidence gap does not make the product irrelevant. It defines what enterprise buyers must validate before treating the new platform as a consolidated control plane.

Why AI Agents Put Traditional Cloud Security Under Pressure

Agents compress several familiar security problems into one fast-moving identity that can reason, choose tools, and initiate changes.

A traditional workload usually follows code that engineers can review before deployment. Its permissions may still be excessive, and its dependencies may still contain vulnerabilities. However, the expected execution path is relatively stable.

An agent behaves differently. It interprets instructions, retrieves context, selects tools, and constructs a sequence of actions at runtime. Small changes in prompts, retrieved documents, model versions, or tool descriptions can alter that sequence.

This variability does not mean agent behavior is unknowable. It means defenders need telemetry around both the decision path and the resulting system calls.

Identity is a core part of that problem. An agent that acts through a shared service account can make logs difficult to interpret. Investigators may see a database query or file change without knowing which agent initiated it, why it acted, or who authorized the workflow.

Microsoft’s least-privilege guidance recommends treating every agent as a distinct principal. Each agent should have a managed identity, an explicit owner, narrowly scoped roles, and an approved tool manifest.

That model creates a measurable boundary. Teams can determine which tools an agent should call, which resources it can access, and whether its runtime activity remains within its assigned purpose.

The problem becomes more serious when MCP servers inherit broad credentials. MCP supports authorization mechanisms, including OAuth, but the protocol does not automatically enforce a safe policy for every deployment.

Microsoft reported that 15 percent of remote MCP servers observed through Defender for Cloud signals allowed unauthenticated access to sensitive data or operational capabilities. Its MCP exposure findings included connections to ticketing systems, private repositories, and human-resources tools.

That figure does not describe all MCP deployments. It does demonstrate that agent connectivity can expose real enterprise systems when authentication and execution boundaries are misconfigured.

A posture scan might identify the exposed server. An identity product might find its credential. A runtime tool might record a suspicious call. OX is betting that a shared graph can connect all three before an analyst manually assembles the chain.

This is the strongest argument for combining CNAPP data with AI agent runtime defense. The threat is neither entirely an application problem nor entirely a cloud problem.

Consider an agent tasked with resolving support requests. It can read tickets, search internal documentation, and update customer records. An indirect prompt hidden inside a ticket could instruct the agent to retrieve unrelated records or send data to an external endpoint.

A prompt filter might flag the instruction. However, the severity depends on which identity the agent uses, which tools it can invoke, and which records those tools can access.

Conversely, an unusual API call does not always indicate an attack. The agent might be completing a legitimate task after encountering an uncommon request. Defenders need enough context to distinguish unexpected behavior from unauthorized behavior.

OX Cloud is designed around that distinction. Its promise is not simply to detect strange prompts. It is to connect live behavior with reachable assets, effective permissions, and the originating software path.

OX Cloud Turns Reachability Into Its Main Differentiator

The platform’s central mechanism is evidence-linked prioritization, where runtime behavior and attack paths determine which findings deserve attention.

Cloud-security teams already struggle with alert volume. Posture scanners detect misconfigurations, vulnerability tools enumerate packages, identity systems identify excessive permissions, and data tools classify sensitive stores.

Adding agents can create another inventory without resolving that fragmentation. A security team might learn that an agent exists, uses a particular model, and connects to several tools. Those facts still do not show whether its behavior creates an exploitable path.

OX describes a four-stage workflow: identify, prioritize, investigate, and govern. The stages use the same contextual data rather than operating as disconnected product modules.

Identification covers workloads, identities, agents, data stores, and cloud assets. OX says this includes resources discovered from observed activity, not only resources declared in configuration files.

Prioritization applies reachability to vulnerabilities, permissions, misconfigurations, and supply-chain exposure. Findings that cannot connect to an active workload or valuable asset receive less urgency.

Investigation uses a cloud graph to reconstruct the relationships surrounding an event. An analyst should be able to see which identity acted, which resource it touched, and what additional systems were reachable.

Governance applies restrictions to agent activity and AI usage. This is where OX’s AIDR and agentic attack-surface functions become more than discovery features.

The mechanism sounds coherent, but its quality depends on data fidelity. OX must reliably discover assets, interpret permissions, trace agent calls, and preserve enough context for investigation.

Coverage gaps can create false confidence. An unobserved tool call, unmanaged credential, encrypted traffic path, or unsupported agent framework could break the chain connecting prompt and outcome.

Data correlation can also produce ambiguous conclusions. A prompt appearing shortly before an API call does not automatically prove that it caused the call. Long-running workflows, parallel agents, retries, and delegated subtasks complicate attribution.

OX must therefore distinguish correlation from causation inside its interface. Analysts need timestamps, invocation chains, identity records, policy decisions, and application traces that support the proposed relationship.

Deployment architecture matters too. Runtime inspection can occur through network interception, workload sensors, application libraries, API gateways, cloud logs, or integrations with agent frameworks.

Each method offers different visibility. Network controls may observe destinations and payloads but miss internal reasoning. Framework instrumentation may capture tool selection but provide incomplete coverage across custom applications.

OX says the broader AINAPP platform connects the prompt, code, build, deployment, and runtime stages. AINAPP is the company’s term for an AI-native application protection platform.

The concept gives OX a potentially useful position. Its application-security products already examine source code and software supply chains. OX Cloud extends that story into deployed infrastructure and live agent activity.

However, buyers should ask how the connection works for code and agents not already managed through OX products. A unified platform offers limited value if the richest context only appears within a tightly controlled toolchain.

The practical test is a real incident. A security team should inject a suspicious tool description, trigger an unauthorized access attempt, and inspect whether OX reconstructs the full path.

That exercise should show the initiating content, agent identity, selected tool, parameters, destination, effective permission, affected data, and enforcement result. Anything less leaves analysts stitching together evidence across systems.

OX Security Faces Established CNAPP and AI-Security Platforms

OX is competing against platform consolidation led by larger vendors, not against static cloud scanners that ignored AI entirely.

The market has already moved toward lifecycle coverage. Major vendors now combine AI discovery, posture analysis, red teaming, runtime inspection, identity controls, and policy enforcement.

Palo Alto Networks presents Prisma AIRS as a platform covering AI applications, models, data, and agents. Its Prisma AIRS documentation describes runtime firewalls, APIs, red teaming, model security, posture management, and agent protection.

Palo Alto also integrates AI discovery with Cortex Cloud. That connection can identify models, endpoints, datasets, agents, and dependency relationships across Amazon Web Services, Microsoft Azure, and Google Cloud.

This makes the primary contest broader than OX versus a conventional CNAPP. It is OX’s context-first integration against incumbent security platforms assembling similar controls across existing product portfolios.

The incumbents bring installed bases, cloud telemetry, threat intelligence, identity integrations, and established procurement relationships. Buyers may prefer extending an existing contract instead of introducing another security platform.

OX can counter with focus. A smaller vendor can design around agent workflows without preserving every architectural assumption inside an older product suite.

Its code-to-runtime narrative may also appeal to application-security teams. Those teams want to know whether a finding introduced during development remains reachable after deployment, and whether an agent can activate the vulnerable path.

That connection could reduce disputes between developers and security analysts. Developers often receive scanner findings without evidence that the affected code is exposed. Runtime context can establish which issues have immediate operational relevance.

Yet larger vendors are making the same consolidation argument. Palo Alto reported approximately $120 million in annual recurring revenue for Prisma AIRS after one year of general availability.

The company also reported more than 800 Prisma AIRS customers in its fiscal 2026 fourth-quarter presentation. Those figures use Palo Alto’s own revenue-allocation and booked-quote definitions, but they indicate meaningful commercial demand.

This competitive pressure forces OX to demonstrate specific advantages. A longer feature list will not be enough because cloud platforms already cover many of the same categories.

OX can differentiate through faster investigation, cleaner prioritization, broader framework support, or clearer prompt-to-runtime attribution. It could also compete through deployment flexibility and lower operational complexity.

Customers should compare workflows rather than category labels. Both products may claim agent discovery, runtime defense, and posture management while collecting different telemetry or enforcing policy at different points.

One platform might block malicious prompts before model processing. Another might intercept tool calls, restrict identity permissions, or isolate the workload after detecting suspicious activity.

Those controls are complementary, but their placement affects latency, coverage, and failure modes. A product positioned outside the execution path may observe more safely while lacking immediate blocking authority.

An inline control can stop an action, yet it also becomes part of the application’s availability path. Buyers must understand what happens when the security service becomes slow, loses connectivity, or cannot classify a request.

OX has not publicly provided enough launch-specific evidence to settle those comparisons. Its immediate challenge is converting a credible architecture into repeatable customer outcomes.

Runtime Defense Cannot Replace Agent Design and Access Control

No CNAPP can compensate for agents that share identities, receive excessive permissions, or execute high-impact actions without independent authorization.

Runtime monitoring often receives attention because it can detect behavior that static reviews miss. That strength can also encourage teams to treat observation as a substitute for safer architecture.

An agent should not gain broad access merely because a monitoring product records its actions. Logging an unauthorized data transfer does not undo the transfer.

The agentic risk taxonomy from OWASP includes tool misuse, identity and privilege abuse, memory poisoning, cascading failures, and rogue-agent behavior. These risks cross model, application, identity, and infrastructure boundaries.

Defenders should start with distinct agent identities. Shared credentials obscure ownership and make revocation difficult. Each production agent needs a named owner, documented purpose, and limited set of allowed resources.

Tool access should also be explicit. An agent designed to summarize support tickets should not inherit administrative access to the ticketing platform. It should receive only the read operations necessary for that task.

Write access deserves a separate decision. If the workflow expands to modify records, the team should create new permissions and approval rules instead of broadening an existing role without review.

High-impact actions need deterministic enforcement. Deleting data, changing production infrastructure, issuing payments, or publishing external content should not rely only on a model’s interpretation of natural-language instructions.

Human approval remains appropriate for actions with large financial, operational, or legal consequences. Automated approval can work for lower-impact tasks when policy conditions are narrow and independently enforced.

Memory introduces another risk. An agent may store conversation history, preferences, retrieved facts, or intermediate plans across sessions. Malicious content can persist inside that memory and influence later decisions.

A runtime product should expose memory reads and writes where possible. It should also show whether an agent used retrieved content when selecting a tool or constructing parameters.

However, memory access may occur inside a framework or model service that provides limited telemetry. Buyers should test whether OX Cloud captures these interactions across their actual deployment stack.

False positives present a separate challenge. Agent workflows naturally produce unusual action sequences because they adapt to user requests. Simple anomaly detection can flag legitimate variation and overwhelm analysts.

OX says reachability helps reduce that noise. The claim is plausible, but reachability does not prove malicious intent. A reachable path can support a legitimate workflow, while an unreachable software flaw can become relevant after a configuration change.

Enterprises should measure precision during a controlled deployment. Useful metrics include confirmed incidents, false positives, investigation time, blocked legitimate tasks, unsupported workflows, and telemetry gaps.

They should also measure performance impact. Runtime inspection can add latency when it evaluates prompts, tool calls, data flows, or identity policies synchronously.

OX has not published general latency or overhead figures for OX Cloud. Results will likely depend on deployment method, traffic volume, policy complexity, and the amount of context collected.

Another uncertainty is enforcement consistency. An organization may operate agents built with several frameworks across multiple clouds and SaaS platforms. A policy must survive those architectural differences.

A dashboard that discovers every agent but governs only a subset creates uneven protection. Security teams need a clear compatibility matrix and evidence that unsupported paths remain visible.

The appropriate conclusion is not that runtime defense lacks value. It is that runtime monitoring works best as one layer within a larger control system.

Secure agent design begins with limited authority. Runtime defense then verifies whether behavior remains within those limits and helps investigators understand deviations.

Three Signals Will Show Whether OX Cloud Delivers

The next test is operational evidence, including customer validation, measurable noise reduction, and broad enforcement across real agent stacks.

The first signal is independent customer evidence. OX should show how the platform performs inside production environments containing multiple clouds, agent frameworks, identity providers, and MCP servers.

Useful case studies would quantify how many agents and non-human identities were discovered. They should also report which risky paths were confirmed, how many alerts were suppressed, and how investigation time changed.

The second signal is comparative performance. Buyers need detection and enforcement tests covering prompt injection, poisoned tool descriptions, excessive permissions, unusual API sequences, and attempted data exfiltration.

These tests should include benign variations to measure false positives. A system that blocks every uncommon action provides little value for adaptive workflows.

OX should also disclose where enforcement occurs. Customers need to know whether controls operate inside workloads, through network inspection, within agent frameworks, or through cloud APIs.

The third signal is competitive response. Palo Alto Networks, Microsoft, and other security vendors are integrating agent identity, posture, runtime inspection, and governance into larger platforms.

If those vendors connect code, prompts, identities, cloud resources, and tool calls with similar precision, OX’s architectural distinction will narrow. OX will then compete on deployment quality, investigation speed, coverage, and customer service.

If incumbents keep those controls fragmented, OX can argue that one contextual graph produces faster and more defensible decisions. Customer evaluations will determine which outcome reflects production reality.

Security leaders evaluating the OX Security CNAPP platform should begin with one constrained agent workflow. They can map its identity, approved tools, reachable data, expected actions, and escalation rules before enabling broader coverage.

The evaluation should then introduce controlled failures. Test an exposed MCP server, an overprivileged identity, a poisoned document, an unauthorized tool call, and a vulnerable reachable workload.

The platform should show not only that something unusual happened, but why it mattered. It should connect the originating instruction with the acting identity, selected tool, reachable asset, policy decision, and final outcome.

That standard applies beyond OX. Agent security products must turn complicated telemetry into reliable enforcement and explainable investigations.

The launch reflects a real shift in cloud security. Agents are becoming active cloud participants rather than another asset class to inventory.

OX Cloud responds by placing runtime behavior inside the same graph as code, workloads, identities, and data. The design is credible, but the strongest claims still require independent validation.

Teams considering OX Cloud should ask for a production-shaped trial, not a polished feature demonstration. Can the platform identify every agent, separate legitimate variation from misuse, and reconstruct a complete action chain? Can it enforce limits without delaying normal work or creating another alert queue? Those results will determine whether the OX Security CNAPP platform becomes a meaningful control plane or another layer that security teams must reconcile.