Meerah Rajavel Warns Open AI Models Could Outpace Cybersecurity Guardrails

Meerah Rajavel has issued a stark warning: inexpensive open AI models, not today’s controlled frontier systems, represent the greatest emerging cybersecurity threat. The Palo Alto Networks chief information officer made that argument in an August 30 interview discovered through Google News.

Her concern centers on a narrowing capability gap. Rajavel says advanced capabilities can reach openly available models within four to six months of appearing in frontier systems. Attackers then need only computing resources and technical skills, rather than continued access to a monitored commercial service.

That distinction changes the security debate. Closed providers such as Google, OpenAI, and Anthropic can monitor activity, block users, revise safeguards, and withdraw access. Once downloadable model weights spread across private systems, those controls largely disappear.

The warning is not proof that open models already cause more cyberattacks than closed ones. It is a forecast about access, economics, and control. The central conflict pits the benefits of open development against the security value of enforceable guardrails.

The Google News Report Centers on a Four-to-Six-Month Window

Rajavel’s central claim is that dangerous AI capabilities become harder to control when their cost falls and their distribution expands.

In the original Rajavel interview, she distinguishes frontier models from cheaper systems that attackers can operate themselves. Frontier services require payment and usually place restrictions around high-risk behavior.

That economic barrier does not stop well-funded criminals or state-backed groups. However, it can limit experimentation by less capable actors. Hosted services also give providers opportunities to identify suspicious prompts, terminate accounts, and preserve evidence.

Rajavel argues that the balance changes when comparable capabilities reach downloadable models. An attacker can run a model privately, modify its behavior, automate repeated attempts, and avoid a provider’s abuse-monitoring system.

Her four-to-six-month estimate is the interview’s most consequential claim. It describes a possible lag between a frontier capability appearing and a cheaper alternative becoming widely accessible.

The estimate should not be treated as a universal technical law. Different models vary in training quality, tool access, hardware needs, and cyber performance. Some open systems will remain far behind the strongest hosted models.

Yet attackers do not always need the best available intelligence. A model only needs to improve the economics of reconnaissance, phishing, code modification, vulnerability research, or credential theft.

Cyber operations also consist of many smaller tasks. A model that cannot autonomously compromise a hardened network might still draft messages, inspect code, translate lures, or adapt scripts.

This creates a volume problem. Modest capability improvements become consequential when attackers can run thousands of private sessions without per-request oversight.

The terminology deserves care. Many systems described as open-source AI are more accurately called open-weight models. Their trained parameters are downloadable, but their training data, development process, or full source materials may remain unavailable.

That distinction matters for licensing and transparency. It matters less for Rajavel’s immediate security argument, which concerns the ability to copy, modify, and privately operate a capable system.

Her comments arrive as AI agents gain greater independence. An agentic system is software that lets a model plan tasks, use tools, and take actions across several steps.

Earlier chatbots mainly generated text for a person to review. Agents can now browse files, write code, call external services, and interact with enterprise systems.

Those permissions create more opportunities for both legitimate automation and abuse. They also make conventional prompt filtering only one part of the security problem.

Rajavel says companies must examine where an AI system can escape its intended boundaries. That includes the model, its tools, connected data, user permissions, runtime environment, and software dependencies.

The Google News headline captures the provocative conclusion, but the underlying argument is broader. Cheap offensive capability is one threat, while insecure enterprise adoption creates another.

A downloaded model can help an attacker. An ungoverned model inside a company can also leak information, execute unsafe instructions, or inherit excessive access.

Rajavel’s warning therefore connects two fronts. Organizations must prepare for more capable adversaries while securing their own accelerating use of AI.

Cheap AI Changes the Economics of Cyberattacks

The most important shift is not that AI invents entirely new crimes, but that it reduces the labor required to scale familiar attacks.

Cybercrime has always depended on economics. Attackers compare the expected return from a campaign with the cost of tools, infrastructure, access, and skilled labor.

AI can reduce several of those costs. It can help less experienced operators understand unfamiliar code, summarize technical documentation, and customize social-engineering messages.

A private model also supports repeated experimentation. Attackers can remove behavioral restrictions, fine-tune the system, and integrate it into automated workflows.

Rajavel says Palo Alto Networks serves more than 70,000 customers and stops about 30 billion attacks moving through its network. Those figures describe the company’s visibility, not the total global threat landscape.

She also said the company encountered almost 250 million previously unseen attacks during the preceding calendar year. According to her interview, that was four times the prior year’s level.

A previously unseen event is not automatically an AI-generated attack. Novel detections can rise because of changing attacker behavior, improved sensors, expanded customer coverage, or revised classification methods.

Rajavel’s figures therefore illustrate defensive scale rather than proving causation. They show why even a small improvement in attacker productivity can burden security teams.

The threat becomes more serious when AI moves beyond text generation. Models with tool access can inspect systems, test hypotheses, revise commands, and pursue multi-step objectives.

Anthropic’s 2025 cyber evaluations found clear progress in vulnerability identification and complex attack chains. The evaluated models still struggled with long plans and unexpected obstacles.

That combination matters. Current limitations prevent simple claims that autonomous AI has replaced expert attackers. At the same time, improving performance can make experts faster and weaker actors more capable.

Commercial providers can respond to observed misuse. They can update classifiers, restrict tools, reduce access, or investigate accounts associated with suspicious activity.

Open weights change that relationship. A provider can publish improved safety guidance, but it cannot remotely update every downloaded copy.

The same permanence supports legitimate users. Researchers can reproduce results, companies can keep sensitive information on local infrastructure, and developers can adapt models for specialized tasks.

That is why the conflict is not simply responsible companies against irresponsible open developers. Openness creates real economic, scientific, and security benefits.

Defenders use accessible models to inspect malware, search logs, classify alerts, and study attacks. Smaller organizations can build protective tools without depending on one vendor.

The economic asymmetry differs across tasks. Defenders must protect many systems continuously, while an attacker may need only one successful path.

AI can help defenders process huge volumes of signals. It can also help attackers search for the single mistake that survives those defenses.

Rajavel’s own enterprise figures show the defensive side. She said Palo Alto Networks increased automation of information technology operations from 12 percent several years ago to 83 percent.

She also reported that IT operating costs declined by almost 72 percent over two years. Travel and expense processes reached 90 percent automation through AI and process redesign.

Those are company-reported results, not independently audited causal findings. Still, they demonstrate the productivity gains that encourage enterprises to deploy AI quickly.

The tension follows directly. The same economics that make defensive automation attractive also lower costs for offensive automation.

A private open model does not need to surpass the strongest commercial model on every benchmark. It needs to be sufficiently capable, affordable, and adaptable for a specific attack workflow.

Security teams should therefore avoid using model rankings as their only threat signal. Deployment freedom, tool integration, and operating cost can matter as much as raw benchmark performance.

Open Models Trade Central Control for Adaptability

Open-weight AI distributes innovation and defensive access, but it also removes the central enforcement points that hosted services retain.

A closed model provider controls an application programming interface, which is the managed connection through which customers submit requests. That control supports authentication, rate limits, logging, and abuse detection.

The provider can also change the service after release. It can patch a weakness, strengthen a classifier, restrict a feature, or remove a model.

Those measures are imperfect. Attackers can create accounts, conceal intent, distribute work, jailbreak safeguards, or steal access credentials.

Closed systems also concentrate risk. A provider’s security failure can affect many customers, while opaque training and moderation practices limit outside scrutiny.

Open-weight systems reverse several properties. Users gain access and customization, while the original developer loses continuing control over downstream copies.

Anthropic’s 2026 open-weights position captures this tradeoff. The company supports open models without dangerous capabilities and opposes blanket bans.

Its stated concern begins when a model reaches dangerous cyber or biological capability. Once those weights are released, copies can operate privately and safeguards can be removed.

That position supports part of Rajavel’s argument, but it does not establish that open models are categorically the greatest threat. Anthropic has commercial interests in controlled model access.

Open-model developers and advocates raise a different case. External researchers can inspect behavior, reproduce tests, develop mitigations, and adapt systems for defensive use.

Local deployment also supports data control. A hospital, law firm, or security team may prefer processing sensitive material within infrastructure it manages.

Open systems reduce dependency on provider policy and availability. They can expand access for academics, startups, public agencies, and regions underserved by commercial services.

The security value of that accessibility is genuine. Defensive expertise and tooling are unevenly distributed, just like offensive capability.

A downloadable model can help a small security team analyze suspicious scripts without sending proprietary data to an external provider. It can also support repeatable research.

The problem is that benefits and harms share the same distribution channel. A public release cannot reliably distinguish a defender from an attacker.

This is the core tradeoff behind the Google News story. Central control enables intervention, while distributed access enables adaptation.

No single label resolves it. “Open” does not mean safe, and “closed” does not mean secure.

The more useful question is whether a specific capability becomes substantially more dangerous when it can run without monitoring. Cybersecurity offers several plausible cases.

One is scalable vulnerability discovery. A model that inspects large codebases can help defenders find defects, but attackers can direct the same capability toward exposed software.

Another is exploit development. Models can explain crashes, generate variations, and assist with debugging, even when they cannot complete a sophisticated exploit independently.

A third is campaign automation. AI can coordinate reconnaissance, content generation, code changes, and operational decisions across many targets.

Safety measures inside model behavior can reduce casual misuse. Downloadable weights let determined operators modify or bypass those measures.

That does not make every open release equally risky. Model capability, hardware requirements, fine-tuning difficulty, and tool integration all change the practical threat.

A small model that improves document classification presents a different risk from a system that reliably finds and exploits unknown vulnerabilities.

Policy based only on openness would ignore those differences. Capability-based evaluations offer a more targeted approach.

The National Institute of Standards and Technology defines a dual-use model partly through its potential to enable powerful offensive cyber operations. The definition applies regardless of attempted safeguards.

That framing shifts attention from a model’s license toward what it can actually do. It also recognizes that closed safeguards may fail or be circumvented.

NIST’s approach does not erase the distribution question. Two equally capable models can present different operational risks when one remains monitored and the other spreads through private copies.

The strongest policy analysis must consider both dimensions. Capability determines potential harm, while distribution determines how easily providers or authorities can intervene.

The Risk Also Lives Inside the AI Supply Chain

Focusing only on attackers using open models misses the immediate danger of enterprises importing unverified models, libraries, and agents into trusted environments.

Rajavel has repeatedly argued that AI security cannot be added after deployment. Companies must secure the model, data, application, infrastructure, and runtime together.

Runtime security means observing and controlling what an AI system does while it operates. This includes its prompts, outputs, tool calls, files, identities, and network connections.

The need grows with agentic AI. An agent that only drafts text has limited reach. One that can execute code or query customer records carries much greater operational risk.

Enterprises often combine several models rather than using one large system. A general model may plan a task, while smaller models parse documents, classify images, or extract structured information.

This modular design improves speed and cost. It also creates dependencies that conventional software inventories may not capture.

A model downloaded from a public hub is not merely content. Its format, metadata, loading code, tokenizer, runtime, and supporting libraries can all introduce vulnerabilities.

Palo Alto Networks researchers disclosed library vulnerabilities involving open AI and machine-learning projects associated with NVIDIA, Salesforce, and Apple researchers. Vulnerable versions could execute malicious code through crafted model metadata.

The affected projects were NeMo, Uni2TS, and FlexTok. The researchers said vulnerable loaders could execute arbitrary commands when processing modified model files.

Those findings do not show that open models are inherently malicious. They show that AI artifacts participate in a software supply chain with familiar dependency and code-execution risks.

OWASP’s supply-chain guidance identifies model hubs, packages, data platforms, and machine-learning operations software as possible attack surfaces.

The guidance recommends verifying package authenticity, monitoring versions, and maintaining dependencies. Those practices sound routine, but AI development can weaken their application.

Teams may download models during experiments and promote them into production without a full review. Notebook-driven work can blur the boundary between research and deployed software.

Model names also create false confidence. Popularity, a familiar uploader, or a high download count does not replace provenance and integrity checks.

An organization should know who published a model, which exact version it uses, and whether the artifact changed. It should also track licenses and known vulnerabilities.

Security teams need to scan model files before loading them. They should prefer safer serialization formats and isolate any process that handles untrusted artifacts.

Least privilege remains essential. An agent should receive only the data and tools required for its assigned task, not broad access for convenience.

Network restrictions also matter. A compromised model workflow should not freely contact external systems or move laterally across internal infrastructure.

Companies should record tool calls and sensitive data access. Logs need enough context to reconstruct what the agent attempted and which identity authorized it.

Human approval should remain at high-impact boundaries. Financial transfers, production changes, privilege escalation, and external communications require stronger controls than document summarization.

The skeptical point is important. Palo Alto Networks sells security products, so its executives have a commercial reason to emphasize expanding attack surfaces.

That incentive does not invalidate Rajavel’s technical argument. It means readers should separate verified vulnerabilities and measured behavior from broader forecasts about the “greatest” threat.

Her company’s detection volumes cannot establish that open models caused a particular share of attacks. Nor does the interview provide a comparative incident rate for open and closed systems.

The four-to-six-month capability lag also needs repeated testing. Public benchmarks may not represent real intrusion work, where persistence, stealth, and environmental adaptation matter.

Closed providers face their own serious risks. Account controls can fail, insiders can abuse access, and capable models can assist harmful users before monitoring systems intervene.

Frontier model weights can also be stolen. A closed system’s distribution advantage disappears if attackers obtain and privately operate its parameters.

The prudent conclusion is narrower than the headline. Open distribution can amplify cyber risk when capable models become cheap, modifiable, and difficult to monitor.

That mechanism is credible. Its current magnitude remains uncertain and should be measured rather than assumed.

Three Signals Will Test Rajavel’s Warning

The next phase of this debate will depend on capability evidence, real-world incidents, and enforceable security practices rather than model labels.

The first signal is independent cyber evaluation of newly released open-weight models. Researchers need tests that measure multi-step work, not only isolated questions or coding puzzles.

Useful evaluations should examine vulnerability discovery, exploit development, privilege escalation, persistence, and adaptation after failure. They should compare systems under similar tools and computing budgets.

A widening gap between open and frontier models would weaken the four-to-six-month thesis. A repeatedly narrow gap would strengthen it.

Evaluation design will remain contentious. Publishing detailed offensive tests can itself spread techniques, while private testing makes results harder to audit.

The best programs will provide enough methodology for credibility without releasing operational instructions that simplify abuse. Independent evaluators can reduce reliance on vendor claims.

The second signal is evidence from actual attacks. Security vendors, model providers, governments, and incident-response firms should document how AI changes attacker behavior.

The crucial question is not whether an attacker used a model at some point. It is whether AI enabled greater scale, speed, access, or technical capability.

Investigators should distinguish hosted services from privately operated models when evidence allows. Without that separation, broad claims about open-source AI remain difficult to verify.

They should also distinguish capability from causation. A machine may generate phishing text without determining campaign targeting, infrastructure, or monetization.

Real-world telemetry can reveal which tasks attackers automate first. It can also show where model limitations still require human expertise.

The highest-risk change would be reliable autonomous exploitation across unfamiliar environments. That requires planning, tool use, feedback interpretation, and recovery from errors.

A more immediate change may involve orchestration. Human operators can delegate many bounded tasks to models while retaining control of strategic decisions.

The third signal is whether governments and developers converge on capability-based release standards. These standards would evaluate dangerous functions before distribution.

NIST has already promoted lifecycle management for dual-use foundation models. Its guidance includes model evaluation, cyber misuse, and supply-chain risk.

A workable framework would apply to both open and closed developers at capability thresholds. It would not assume that one distribution model is universally safe.

Open releases may require additional mitigation once a system crosses a meaningful threshold. Options include staged access, independent testing, delayed release, or withholding specific high-risk components.

Each option carries costs. Restrictions can concentrate market power, slow defensive research, and reduce access for smaller organizations.

Blanket prohibitions would also struggle in practice. Weights can cross borders, copies can persist indefinitely, and smaller models continue improving.

Commercial providers should not receive an automatic exemption. Their systems require strong monitoring, transparent reporting, and rapid responses to verified abuse.

Enterprise buyers face a more immediate decision. They should treat every model and agent as a software dependency with its own identity, permissions, provenance, and runtime behavior.

That means maintaining a complete AI inventory. Teams need to know which models employees use, which data reaches them, and which actions they can take.

Security review should follow risk, not novelty. A locally hosted summarizer and an autonomous production agent should not face identical approval processes.

Organizations should also evaluate what happens after compromise. Containment often matters more than confidence that prevention will always work.

A well-designed agent can fail without exposing an entire network. A poorly designed agent can turn one malicious prompt into an enterprise incident.

Knowledge workers also have a role. They should avoid placing sensitive material into unapproved services and verify consequential AI-generated instructions.

Teams handling local technical documents can build a searchable knowledge base with controlled sources and explicit access boundaries. The same discipline applies to any AI workspace.

Readers arriving from Google News should therefore treat Rajavel’s claim as a testable security thesis, not a settled ranking of every AI threat.

The thesis becomes stronger if open models repeatedly approach frontier cyber performance within months and appear in documented attacks. It weakens if practical capability gaps remain large.

It also weakens if monitoring fails to meaningfully constrain misuse on hosted models. Central control only improves safety when providers use it effectively.

Rajavel’s warning ultimately concerns the loss of intervention. Once capable weights spread, no developer can recall every copy, restore every safeguard, or inspect every use.

That permanence deserves serious attention. So do the defensive benefits, transparency, and competition that open development can support.

The right response is neither complacency nor a reflexive ban. It is better evidence, capability-sensitive release decisions, secured supply chains, and tightly bounded enterprise agents.

Watch the next major open-weight release, then ask three concrete questions. What cyber tasks can it complete, what controls disappear after download, and what incidents show those capabilities being misused?

Those answers will determine whether the warning highlighted through Google News becomes the defining AI security problem, or one risk among several competing threats.