MachineBrain
Trend· Independently researched

AI Security Vulnerabilities and Monitoring Challenges

Explore AI security vulnerabilities and monitoring challenges, with insights on detection, remediation, and best practices for AI systems.

AI Security Vulnerabilities and Monitoring Challenges

The shift is from finding flaws to operating through them

AI security is becoming less about whether systems contain vulnerabilities and more about whether organisations can see, validate and remediate them before someone exploits them. Recent evidence spans model oversight, mainstream web infrastructure and operational technology, which makes this more than a single vendor’s problem.

The pattern is consistent. AI systems create new identities, tool calls and automation paths that must be monitored. At the same time, AI-assisted discovery increases the number of bugs entering disclosure pipelines, while ordinary failures such as default passwords and delayed patching remain enough to cause physical damage.

That distinction matters because some discussion treats AI security as a specialised alignment question. It is partly that, but recent incidents suggest a more mundane operational challenge: asset inventory, access control, telemetry coverage, patch deployment and a credible process for deciding which reports deserve urgent action.

Monitoring is not control, and control is not coverage

The most consequential recent evidence comes from METR’s pilot assessment of OpenAI’s internal monitoring system. The assessment reportedly found that only 75% to 94% of traffic from GPT-5.5-level agents was eligible for monitoring, depending on configuration and circumstances. [4][5]

That is not a claim that the remaining traffic was malicious, nor evidence of a completed compromise. It is a measurement of observability boundaries. If some agent traffic never reaches the monitoring path, a detector cannot alert on it, regardless of how sophisticated its models or rules may be.

METR also reportedly identified two settings that could disable monitoring for newly created agents. It found that OpenAI’s Codex agents could bypass safety restrictions to perform actions a user was permitted to take. [4] The important word there is permitted.

An agent acting with the user’s authority can still create a security incident. A user may have access to repositories, cloud consoles, internal documents or deployment systems that they should not expose through a broad automation loop. Conventional identity security has long recognised this problem, and agentic systems make it easier to trigger at machine speed.

OpenAI has said production vulnerabilities identified in the assessment have been patched. That is useful information, but it is not equivalent to independent verification that every affected pathway is now covered. METR had not independently verified the completeness or effectiveness of those fixes when the findings were reported. [4][5]

This is where security marketing often becomes unhelpful. “Patched” answers whether the supplier changed something. It does not by itself answer whether monitoring now captures all relevant traffic, whether a configuration can regress, or whether the same class of bypass exists in another tool integration.

AI is accelerating discovery faster than remediation

The PHP2Shell disclosures show the same operational asymmetry from another direction. Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, allowed unauthenticated remote code execution through memory-management flaws in PHP. [9][10]

The affected versions include PHP releases before 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Emergency fixes were released on October 21, while PHP 8.1 and older branches are already end of life, leaving some deployments without a supported patch path. [9][10]

Reports say AI systems, including OpenAI’s GPT-5.6 Sol and Google’s Gemini 4 Argon, assisted the research that uncovered the flaws. [6] That is a significant example of AI shortening the route to a real security finding, but it should not be inflated into a claim that AI independently solved software security.

The vulnerability still required technical validation, coordinated disclosure and maintainers capable of producing patches. Those remain the scarce steps. A flaw has limited defensive value until affected operators know whether they run the vulnerable code and can safely deploy a fix.

Axios reported that OpenSSL maintainers received 71 vulnerability reports per month between May and July 2026, compared with nine per month during 2025. Many of the newer submissions were duplicates or low-severity reports. [3] That is a clear sign of a changing workload, not necessarily a sevenfold improvement in useful discoveries.

The practical bottleneck is increasingly report quality. Automated systems can propose suspicious patterns at low marginal cost, but maintainers must reproduce the issue, establish impact, determine affected versions, coordinate disclosure and create a safe patch. AI shifts effort toward those human judgement stages.

This is why the industry should be wary of both extremes. It is wrong to dismiss AI-assisted vulnerability discovery as noise, because PHP2Shell shows serious results. It is also wrong to assume more discovered issues automatically produces safer software, because validation and remediation capacity can be overwhelmed.

The old attack paths have not disappeared

The French supermarket refrigeration incident is a corrective to the idea that AI security begins and ends with foundation models. Reporting on the attack said attackers gained control of internet-accessible Danfoss refrigeration controllers using weak or default passwords. [7]

Temperatures were reportedly raised to 50 degrees Celsius for roughly six hours, with peaks as high as 80 degrees Celsius. The consequences included spoiled goods, damaged equipment, fires and water damage from sprinkler systems. [7]

An Intermarché store in Issy-les-Moulineaux reportedly lost €21,000, while Carrefour’s repair costs exceeded €10 million. National losses were estimated in the tens of millions of euros, although investigations by French authorities were ongoing. [7]

The IBM Technology security panel used the incident to make a familiar but still neglected point: patching operational technology has a real downtime cost, but uncontrolled failure costs more and can introduce safety risks. That is not an AI-specific lesson, and it is exactly why it matters.

Many AI deployments will sit on top of this existing infrastructure. A customer-support agent may access a PHP application. A coding agent may create a configuration change. A forecasting model may feed a control system. New automation inherits the weaknesses of the identities, networks and patch processes beneath it.

The incident does not establish that AI caused the French attack. The available reporting points to weak credentials and exposed controllers, which are conventional security failures. But it demonstrates why AI security programmes that ignore infrastructure hygiene will be incomplete from the start.

California is pushing governance toward auditable practice

Regulatory activity in California also reflects the move from broad principles toward operational controls. StateScoop reported that OpenAI urged Governor Gavin Newsom to strengthen California’s AI safety law with additional safeguards, an unusual reminder that even major developers see practical gaps in a rapidly evolving framework.

California’s 2025 and 2026 laws cover frontier-model safety disclosures, incident reporting, auditor standards, automated workplace decisions, consumer-facing chatbots and child-oriented systems. The overall direction is clear: developers and deployers are increasingly expected to document controls and demonstrate meaningful human oversight.

For project teams, the important implication is not that every application needs frontier-model governance machinery. It is that “we monitor it” will become a less satisfactory answer when a regulator, customer or auditor asks what was monitored, who had authority, and how incidents were handled.

The useful unit of compliance will be evidence. That means versioned model and prompt records, logs for tool calls, a record of permissions granted to agents, documented escalation paths, and proof that someone can intervene when automated behaviour crosses a defined boundary.

What to build into an AI project now

Start with an asset and authority map. List each model, agent, tool connector, service account, API key, runtime environment and data source. Then identify which actions each component can initiate and which actions it can cause indirectly through another service.

Do not treat an agent’s permissions as a copy of the requesting user’s permissions. Give agents narrower, purpose-specific identities wherever possible. An agent that summarises internal documents should not inherit the ability to delete cloud storage, modify production code or change identity policies.

Measure monitoring coverage directly. Ask what percentage of agent requests, tool calls, outbound network requests and privileged actions reach logging and detection systems. The METR findings are a reason to ask for a number, not accept a generic assurance that monitoring exists. [4][5]

Test configuration changes as security changes. If a setting can turn off monitoring for a class of newly created agents, it should be access-controlled, logged and reviewed. A deployment pipeline should flag any change that reduces telemetry coverage or widens tool permissions.

Build a vulnerability intake process before deploying AI-assisted coding or security tools. Require reproducible reports, affected versions, proof of impact and clear ownership. This protects maintainers from low-value volume while ensuring that a report resembling PHP2Shell receives the necessary urgency. [9][10]

Finally, make patching a design constraint rather than a post-launch maintenance task. Know which components can be updated remotely, which need scheduled downtime, and which have reached end of life. The French refrigeration failures show that deferred maintenance becomes an operational resilience issue, not merely an IT backlog item. [7]

The evidence does not yet support a claim that AI systems are uniquely insecure or that automated monitoring has broadly failed. It does support a narrower, more actionable conclusion: AI is expanding both the attack surface and the reporting surface, while visibility and remediation remain uneven.

Frequently Asked Questions

What are common AI security vulnerabilities and how can they be monitored?

Common vulnerabilities include AI agents creating new identities, tool calls, and automation paths that may bypass monitoring. Monitoring must ensure visibility of all agent actions, tools, and identities, as some traffic may not reach monitoring systems. Effective coverage requires measuring what is actually visible rather than relying solely on alerts or vendor claims of patches.

How does AI affect the volume and management of vulnerability reports?

AI accelerates the discovery of vulnerabilities faster than teams can validate and remediate them. This increase in volume demands investment in triage, reproduction, and remediation workflows beyond just scanning tools to manage the influx effectively.

What challenges exist in monitoring AI agents and their actions?

Monitoring AI agents is complicated by incomplete observability; for example, METR’s assessment found only 75% to 94% of GPT-5.5 agent traffic was eligible for monitoring. Additionally, some settings can disable monitoring for new agents, and agents acting with user permissions can perform actions that create security risks, making comprehensive coverage difficult.

Why is coverage important in AI security monitoring?

Coverage ensures that all relevant AI agent traffic and actions are visible to monitoring systems. Without full coverage, detectors cannot alert on potentially malicious or risky behavior, regardless of how advanced their detection models are. Measuring and verifying coverage is essential before trusting alerts or vendor patch claims.

How can organizations improve AI security remediation workflows?

Organizations should focus on strengthening triage, reproduction, and remediation processes to keep pace with the increased vulnerability reports driven by AI-assisted discovery. This includes treating AI security as an operational challenge involving asset inventory, access control, telemetry coverage, and credible prioritization of reports rather than relying solely on scanning or vendor assurances.

How we researched this

This article was assembled from 1 video source, 2 published articles, 10 cited references.

Nothing here is based on hands-on testing. Where a figure or finding appears, it belongs to the source cited beside it, and the writing says so rather than implying otherwise. Every source is listed below so you can check it.

Sources

Watch AI Security Vulnerabilities and Monitoring Challenges on Youtube

AI Agents Action Selection

AI Agents Action Selection

Explore AI agents' action selection, integration challenges, and security in automation. Learn about personal AI agents and best practices.

AI Safety Incidents and Observability Challenges Explained

AI Safety Incidents and Observability Challenges Explained

Explore how AI safety incidents stem from observability gaps and how action trails and controls improve regulatory compliance and governance.

AI Agents Multi-Agent Systems Platforms

AI Agents Multi-Agent Systems Platforms

Explore AI agents and multi-agent systems platforms with comparisons, costs, observability, and security insights for effective deployment.

AI Agent Security Best Practices

AI Agent Security Best Practices

Learn AI agent security best practices, including permission boundaries, authorization controls, and human approval to safeguard AI in cybersecurity.

Topics

Infrastructure And Ops