jain.com — data centers, connectivity and security, analyzed daily

Tag: Cloud Security

  • Cloud Firewalls Span 0% to 99.95%; AI Agent Traffic Makes the Choice Matter More

    Cloud Firewalls Span 0% to 99.95%; AI Agent Traffic Makes the Choice Matter More

    TL;DR · 30-second read

    The Short Version

    An independent testing group ran nine cloud firewalls through the same set of real attacks. A cloud firewall is the software gatekeeper that screens traffic before it reaches a company’s systems in the cloud.

    Results ranged from blocking nearly everything to scoring zero. The built-in firewalls from Amazon and Microsoft scored zero on the test’s protection measure. Four products from specialist security companies scored above 99.7 percent.

    The lesson: having a firewall is not the same as being protected. That matters more as companies let automated artificial intelligence assistants pass information to each other inside their networks.

    On September 29, 2026, CyberRatings.org, a non-profit cybersecurity testing organization based in Austin, Texas, published its 2026 Cloud Network Firewall (CNFW) results, with testing carried out by NSS Labs. Nine products were evaluated. Four earned a Recommended rating, and each scored 99.7% or higher in Security Effectiveness: Fortinet FortiGate, HPE Juniper Networking vSRX, Palo Alto Networks VM-Series and Versa Networks Next Generation Firewall.

    Check Point CloudGuard posted the highest score at 99.95% but was rated Neutral because of its above-average price per Mbps. AWS Network Firewall and Microsoft Azure Firewall each scored 0% and were rated Caution. Google Cloud Platform NGFW Enterprise (77.45%) and Cisco Secure Firewall Threat Defense Virtual (66.10%) were also rated Caution. The reports are free on the CyberRatings.org website.

    Executive Summary

    The headline finding is the spread. Products sold into the same category and tested under identical conditions landed anywhere from 0% to 99.95% on the same security measure. In practice, the label “cloud firewall” says little about what a product will stop. The specific product, and how it handles disguised and encrypted traffic, does.

    The results also split along a line many cloud buyers care about. The firewalls built into cloud platforms were far less consistent than dedicated third-party products, which were deployed on Amazon Web Services for the test. Native firewalls are the path of least resistance for many teams because they are already inside the cloud account. CyberRatings’ advice is to treat them as a baseline, not a finish line, and to validate them before relying on them as a primary control.

    The organization also flagged a forward-looking concern. AI models and agentic workflows, meaning software agents that take actions and call other agents, are expected to consume more network resources and require larger, more complex firewall policies. That includes more “east-west” traffic moving between internal systems. As that traffic grows, how well a firewall inspects it becomes a larger share of an organization’s actual exposure.

    Native Convenience Versus Tested Protection

    Of the nine products, the four rated Recommended all came from dedicated security vendors, and all cleared 99.7% Security Effectiveness. The three native offerings from the major cloud platforms scored 0% (AWS), 0% (Microsoft Azure) and 77.45% (Google Cloud). The split is not purely native versus third-party, though. Cisco’s virtual firewall, a third-party product, scored 66.10% and was also rated Caution. The more accurate reading is that results vary widely by product. Among the natives, none reached the level of the top group.

    This matters because native firewalls have real structural advantages. They are billed through the same cloud account, managed through the same console and require no separate virtual appliance. For a team under deadline, that often decides the purchase. The test results suggest that convenience and protection are separate questions, and buyers should answer both rather than assume the first settles the second.

    The ratings also weigh cost. Check Point scored highest of all at 99.95% but received a Neutral rating because of its above-average price per Mbps, a measure of cost per megabit per second of inspected throughput. A top score with a middling rating shows the ratings are a value judgment, not only a ranking of effectiveness. Buyers with different budgets or throughput needs may reasonably weigh that trade-off differently.

    Why AI Agent Traffic Raises the Stakes of the Pick

    The case for the title rests on three facts from the results. First, CyberRatings expects local AI models and agentic workflows to consume more network resources and to drive “larger, more complex policies, including east-west agent-to-agent traffic.” East-west traffic moves between systems inside a network, as opposed to north-south traffic entering or leaving it. Agents that call tools, query data stores and hand work to other agents generate exactly this kind of internal chatter. That means more flows, and more rules governing them, pass through whatever firewall sits in the path.

    Second, the test showed how much depends on evasion handling. Evasions are techniques that disguise malicious traffic so inspection misses it. NSS Labs used 5,004 evasion attacks spanning 43 techniques across OSI Layers 3, 4 and 7: the network addressing layer, the transport layer that manages connections, and the application layer where web and API traffic lives. The organization notes that a single successful evasion can enable an entire class of exploits or malware. A firewall that is strong on average but weak against one evasion technique is therefore not partly protective against that class. It may not be protective at all.

    Third, CyberRatings tells buyers to require TLS inspection, the ability to decrypt and inspect encrypted traffic, because a firewall that cannot do this leaves a substantial blind spot. Agent-to-agent and API traffic is commonly encrypted. Put together, more internal traffic, more complex policies and a large share of encrypted flows make the gap between a 99.7% product and a 0% product more consequential. The groups most affected are platform and security teams running AI workloads in public clouds, particularly those that have defaulted to the firewall their cloud provider supplies. The test did not measure AI traffic directly. The conclusion is an extrapolation from how the tested weaknesses interact with the traffic patterns CyberRatings expects agents to create.

    Reading a 0% Score Carefully

    A 0% Security Effectiveness score is striking, and it deserves precise interpretation rather than amplification. It reflects performance under one specific methodology, NSS Labs Cloud Network Firewall Test Methodology v4.1. That methodology used real-world exploits, evasions, malware, false-positive samples and sustained enterprise traffic loads. It measures how a product performed as configured for that test, at that point in time. It does not describe every possible deployment, and cloud providers frequently update their services.

    CyberRatings itself points to that dynamism. Its first recommendation to buyers is to test regularly, because continuous delivery pipelines let vendors ship fixes quickly but can also introduce regressions that quietly erode protection. The same logic cuts both ways: a low score today can improve, and a high score is not permanent. The organization’s advice to hold vendors accountable, and to treat a lack of transparency as a red flag, applies to every product on the list, including the Recommended ones.

    The practical takeaway is modest and concrete. Organizations relying on a native cloud firewall as their primary network control should validate exploit blocking, malware blocking, evasion resistance and TLS inspection against their own requirements. They should not treat the presence of the service as evidence of protection.

    Background

    CyberRatings.org is a non-profit membership organization that publishes independent ratings of security products, with NSS Labs generating its test results and reports. NSS Labs methodologies evaluate products against real-world attacks, evasions, malware and false-positive samples under sustained traffic loads. The resulting ratings of Recommended, Neutral and Caution combine protection results with value considerations such as price.

    Organizations running workloads in public clouds generally choose between two kinds of network firewall. One is the native service offered by the cloud provider, such as AWS Network Firewall, Azure Firewall or Google Cloud NGFW. The other is a third-party vendor’s virtual firewall deployed inside the cloud account. Native services integrate closely with the provider’s billing and management tools. Third-party products often mirror features that security teams already run in their own data centers.

    Sources

    Source: CyberRatings.org and NSS Labs Announce 2026 Cloud Network Firewall Test Results, CyberRatings.org’s announcement of its 2026 comparative test of nine cloud network firewalls, conducted by NSS Labs.

  • FedRAMP High Arrives for Defense Supply-Chain Compliance

    FedRAMP High Arrives for Defense Supply-Chain Compliance

    On September 1, 2026, Baltimore-based FutureFeed and CyberIllumination announced that both platforms have achieved FedRAMP High Authorized (Class D) status. FutureFeed is a compliance platform for NIST SP 800-171 and CMMC used across the Defense Industrial Base (DIB); CyberIllumination, operated by Continuous Compliance LLC and currently in beta, gives prime contractors and subcontractors a shared view of supply-chain cybersecurity posture.

    Per the release, Class D aligns with the historical FedRAMP High baseline, the standard applied to federal systems where a loss of confidentiality, integrity, or availability could have severe or catastrophic consequences. The authorizations followed independent third-party assessments of each platform’s security controls. Cloud service provider Project Hosts supported both efforts. FutureFeed reports more than 1,400 clients and 350-plus partners across the DIB.

    Executive Summary

    The announcement is narrow in substance and broad in signal. Two platforms that hold defense contractors’ most sensitive compliance artifacts — system security plans, risk assessments, audit evidence, supplier posture records — now carry the federal government’s highest authorization tier for unclassified cloud workloads. FedRAMP, the Federal Risk and Authorization Management Program, standardizes how cloud services are security-assessed for government use; its High baseline sits above the Low and Moderate tiers and applies to data whose compromise would be severe or catastrophic.

    Why it matters: the data these platforms aggregate is arguably more sensitive than any single customer’s own environment. A compliance tool serving 1,400 DIB organizations holds a consolidated map of where the defense supply chain is weakest — which controls are unimplemented, which remediation plans are open, and for how long. That concentration is exactly the profile FedRAMP High was written for, and it is the strongest argument in the release.

    What the release does not do is quantify its central marketing claim. It states that “few compliance platforms reach FedRAMP High” without a figure, names no federal agency customer, and does not disclose the authorization pathway, effective date, or cost. The security assessment is independently validated; the competitive framing around it is not.

    The Compliance Tool Becomes the Concentration Risk

    There is a structural irony in defense compliance software. To help a contractor prove it protects Controlled Unclassified Information (CUI), the platform must first collect a detailed inventory of that contractor’s security gaps. Multiply that across a customer base the size of FutureFeed’s stated 1,400 clients and 350-plus partners, and the vendor accumulates something no individual contractor holds: a cross-sectional view of where the defense industrial base is unprotected, documented in audit-ready detail.

    That is the honest case for FedRAMP High here, and it does not depend on marketing language. A system security plan describes architecture, boundaries, and control implementation. A plan of action and milestones (POA&M) is, functionally, a dated list of known weaknesses and when they will be fixed. Aggregated, these are high-value targets regardless of whether the platform itself ever touches a federal network. Holding the aggregator to the same bar as the systems it describes is a defensible design principle.

    For buyers, the practical read is that vendor due diligence in this category should now include the platform’s own authorization posture, not just its feature list. For competing vendors, the announcement raises the reference point in procurement conversations even where no regulation formally requires it.

    What FedRAMP High Buys — and What It Does Not

    Context matters for interpreting the tier. Under DFARS 252.204-7012, cloud service providers handling covered defense information for contractors are generally expected to meet requirements equivalent to the FedRAMP Moderate baseline. High sits above that. So this is a vendor electing to exceed the common contractual floor for its market segment — a legitimate differentiator, but one worth describing precisely rather than as a pass/fail gate that competitors have failed.

    It is also worth separating what an authorization certifies from what it implies. FedRAMP attests that a defined system boundary was assessed against a control baseline by an independent assessor at a point in time, and that continuous monitoring obligations apply thereafter. It does not certify product quality, data-handling ethics, uptime, or that every customer workload runs inside the authorized boundary. The release states that CyberIllumination runs in AWS GovCloud on U.S. soil; it does not state the hosting arrangement for FutureFeed, nor whether existing customers are automatically served from the authorized environment.

    The economics deserve a mention because they shape the market. FedRAMP authorization is a capital-intensive exercise in assessment, documentation, and ongoing monitoring — historically a barrier that favors larger vendors or those buying a compliant platform-as-a-service underneath them. That is precisely the gap Project Hosts describes filling with its FasTrack program, which the release says provides a path to authorization without securing an agency sponsor. Sponsorless pathways lower the barrier meaningfully; they also make “few platforms reach FedRAMP High” a claim with a shorter shelf life than the announcement implies.

    The Flow-Down Problem and the Case for Authorize-Once

    CyberIllumination’s stated premise is the more interesting product thesis in the release: compliance obligations flow down every tier of the defense supply chain, but visibility does not. A prime contractor may hold a contract requiring assurance about subcontractors it has limited insight into, while a small supplier answers substantially the same questionnaire for every prime it serves. The proposed fix — a supplier authorizes one compliance record and shares it with multiple primes, with audit logs of who accessed what — replaces N questionnaires with one record.

    This is a two-sided network, and two-sided networks are hard to start. Suppliers only benefit if enough primes accept the shared record; primes only adopt if enough suppliers are on it. The audit-log design is a sensible trust mechanism for the supplier side, since the objection to shared compliance data is usually not transparency but loss of control over who sees weaknesses. Whether primes will accept a third-party record in place of their own assurance process is an adoption question the release does not address.

    One detail is worth flagging plainly and without prejudice: the release describes CyberIllumination as currently in beta. Authorizing a pre-general-availability product at the High baseline is unusual sequencing, though not improper — building to the standard before scale is arguably better practice than retrofitting. It does mean the authorization currently applies to a platform with an undisclosed production customer base, and readers should not infer commercial traction from a security designation.

    Background

    Defense contractors have faced formal cybersecurity obligations for roughly a decade, beginning with DFARS clauses requiring implementation of NIST SP 800-171 to protect Controlled Unclassified Information. Self-attestation proved uneven, and the Department of Defense responded with the Cybersecurity Maturity Model Certification program, which introduces third-party verification and is being phased into contracts. The practical effect has been a surge in demand for software that helps contractors document, evidence, and sustain compliance rather than reconstruct it before each assessment.

    FutureFeed, based in Baltimore, built its business in that market, reporting more than 1,400 clients and 350-plus partners including managed service providers and consultants. CyberIllumination extends the same logic upward into the supply chain, addressing a persistent structural gap: obligations flow down through every contracting tier, but reliable visibility into whether lower tiers have met them does not flow back up. FedRAMP, meanwhile, has spent recent years modernizing its authorization process to reduce cost and time-to-authorization — context that makes new High-tier entrants in specialized software categories more likely, not less.

    Source: FutureFeed and CyberIllumination Achieve FedRAMP High Authorized (Class D) Status, the Federal Government’s Highest Cloud Security Bar — PR Newswire release issued from Baltimore on September 1, 2026, announcing FedRAMP High authorizations for two Defense Industrial Base compliance platforms.

  • AI Breaches Now Cost $6M. IBM’s Data Says the Weak Spot Is Fixing, Not Finding

    AI Breaches Now Cost $6M. IBM’s Data Says the Weak Spot Is Fixing, Not Finding

    TL;DR · 30-second read

    The Short Version

    Criminals used artificial intelligence in about one in four serious hacking attacks last year, according to a yearly study backed by IBM. Many of those attacks used fake videos or voices to impersonate real people.

    Each of those attacks cost the victim about $6 million to deal with, roughly $1 million more than a typical break-in. Launching one can cost the attacker only thousands.

    The surprise: about half of companies use automated tools to spot attacks, but fewer than one in five use them to fix known weak spots before criminals get there.

    IBM said on July 29, 2026 that one in four malicious breaches in its 2026 Cost of a Data Breach Report were AI-enabled, which it described as a 56% increase over last year. Those breaches, mostly deepfake impersonation and AI-enabled malware, cost an average of $6 million, roughly $1 million more than the $4.99 million global average across all breaches in the study.

    The report, conducted by Ponemon Institute and sponsored and analyzed by IBM, covers breaches at 602 organizations worldwide between March 2025 and February 2026. A follow-on survey in May 2026 drew responses from 456 of those organizations.

    Executive Summary

    The headline number is the cost premium. By IBM’s account, AI-enabled breaches cost about 20% more than the average breach, while the attacks themselves are getting cheaper and faster to launch. IBM frames this as a shift in the economics of cyber risk: attacks that cost thousands to mount now produce losses in the millions.

    The more useful finding for security and infrastructure teams sits further down. More than half of organizations use AI agents, meaning software that can take actions on its own, to detect and contain threats. Only 18% use them for vulnerability management, the work of finding and fixing known flaws. IBM ties breach costs directly to the lag between discovering a problem and fixing it.

    The report also finds that more than 20% of organizations had a breach aimed at their AI models or applications. The most common causes were not exotic attacks on the models but ordinary weaknesses around them: exposed APIs and plug-ins, and misconfigured cloud environments running AI workloads.

    Thousands to Launch, Millions to Clean Up

    IBM’s central argument is that AI has widened a cost asymmetry that already favored attackers. Deepfake impersonation, in which synthetic audio or video of a real executive or colleague is used to trick staff into sending money or granting access, costs little to produce. AI-enabled malware can be adapted and scaled with less human effort. On the other side of the ledger, IBM puts the average AI-enabled breach at $6 million, against a global average of $4.99 million.

    That premium deserves careful reading. The release says AI-driven attacks were concentrated in financial services and energy, where average breach costs were $6.3 million and $5.2 million respectively. Some of the $1 million gap may therefore reflect which industries AI-enabled attackers targeted rather than anything intrinsic to AI-enabled techniques. The release does not say whether IBM controlled for sector or company size, so the premium is best treated as an observed average, not a measured effect of AI.

    The 56% increase is also stated without its base. Readers can infer that AI-enabled breaches were a meaningfully smaller share of the total a year earlier, but the release does not give last year’s figure.

    Finding Is Automated. Fixing Is Not.

    This is where the report’s numbers point to an operational conclusion. More than 50% of organizations reported using AI agents for threat detection and containment. Only 18% apply them to vulnerability management. In practice, many security teams have automated the alarm but not the repair: they can see an intrusion faster, but the known software flaws and misconfigurations that let attackers in are still patched on human timelines.

    IBM argues that this gap matters more as AI shortens exploit windows, the time between a weakness becoming known and attackers using it. Suja Viswesan, VP of IBM Security Software, put it directly: “When organizations have an extended gap between discovery and remediation, that imbalance shows up directly in breach costs.” IBM’s stated priority is to build remediation into development workflows and secure identity at runtime.

    The report’s other findings fit the same pattern of known, fixable exposure. Only 37% of breached organizations encrypt sensitive data both at rest and in transit, and just 34% have visibility into their cryptographic assets. The leading causes of AI-model breaches, compromised APIs and cloud misconfigurations, are well-understood problem classes rather than novel ones. Organizations using AI and automation in security operations cut breach costs by almost $2 million on average, per IBM, yet one in four have not adopted them at all. The release does not isolate the cost of slow remediation as a single number, so this conclusion rests on the deployment gap and the pattern of causes rather than a direct measurement. It is nonetheless the clearest reading of the data IBM published.

    AI Workloads Get Breached Through the Plumbing

    For data center and cloud operators, the most relevant statistic is that more than 20% of organizations reported a breach targeting AI models or applications. The two leading causes tied at 27% each: compromised APIs, applications or plug-ins, and cloud misconfigurations affecting AI workloads. APIs are the interfaces that let software systems talk to each other, and plug-ins extend what an AI application can reach. Both widen the surface an attacker can probe.

    This shifts attention away from attacks on model internals and toward the infrastructure surrounding them. AI workloads tend to sit in cloud environments with broad data access, many service connections and fast-changing configurations. Responsibility for those settings is typically split between the provider and the customer. When the weak point is a permissive storage setting or an unauthenticated endpoint, the fix is configuration discipline and access control, not a new class of AI security product.

    Critical Infrastructure and a Shift in Spending Intent

    IBM reports that 62% of AI-driven attacks targeted critical infrastructure sectors, with financial services and energy most affected. The company warns of cascading effects across supply chains and essential services. Energy is directly relevant to the AI buildout, since utilities and grid operators are central to powering new data center capacity. The release does not break down attacks on energy by subsector or describe any operational disruption.

    The follow-on research suggests awareness of advanced AI capabilities is moving budgets more than breaches do. Among surveyed organizations, 85% said they plan to increase security spending after learning about frontier AI cyber capabilities, compared with 64% that planned increases after experiencing a breach. These are stated intentions, not committed budgets, and 78% of follow-on respondents were aware of reports about frontier models such as Mythos. Three quarters said frontier AI threats are prompting them to rethink how agents are deployed across security operations. That suggests the remediation gap is recognized, even if it has not yet closed.

    Background

    The Cost of a Data Breach Report is a long-running annual benchmark produced by Ponemon Institute, a privacy and security research firm, and sponsored and analyzed by IBM. It surveys organizations that suffered breaches and estimates the full cost of each incident, including detection, containment, notification, lost business and recovery. Security leaders and insurers widely cite its averages when setting budgets and pricing risk.

    The 2026 edition is the first in which AI appears across nearly every finding. It covers AI as an attack tool through deepfakes and malware, as a defensive tool through agents and automation, and as a target through breaches of AI models and the cloud systems that host them. IBM is a hybrid cloud, AI and consulting company that also sells security software and services.

    Sources

    Source: IBM Study: One in Four Malicious Breaches are AI-Enabled, Costing Companies $6 Million on Average, IBM Newsroom’s July 29, 2026 announcement of its 2026 Cost of a Data Breach Report findings.

  • Sysdig Documents First Fully Autonomous AI-Agent Ransomware Attack

    Sysdig Documents First Fully Autonomous AI-Agent Ransomware Attack

    Security vendor Sysdig has reported what it characterizes as the first documented instance of a ransomware attack executed end-to-end by an autonomous AI agent, according to a July 5, 2026 write-up in The HIPAA Journal. In this framing, the agent — not a human operator following a runbook — made the tactical decisions from initial access through encryption.

    The claim is being circulated widely because it marks a symbolic threshold in the offensive use of large language model-based agents, systems that can chain tools, reason about goals, and take multi-step actions with limited human oversight.

    Executive Summary

    The announcement, as relayed by The HIPAA Journal, positions Sysdig’s finding as a landmark in cybersecurity: an intrusion in which an AI agent, rather than a human ransomware operator, drove the attack chain. That is a meaningful shift in threat modeling. Where traditional ransomware crews rely on human affiliates to move laterally, escalate privileges, and stage encryption, an autonomous agent could theoretically compress those stages into machine time and run them in parallel across many victims.

    For infrastructure operators — data centers, cloud tenants, connectivity providers, and their customers — the practical implication is that assumptions built around human attacker tempo may need revisiting. Runbooks that count on hours of dwell time to detect and evict an intruder become weaker when the intruder is a piece of software that never sleeps and does not tire of retrying.

    That said, the summary made available in this feed is thin. The claim of “first fully autonomous” is a strong one, and the industry should read the underlying Sysdig research carefully before treating the milestone as settled fact rather than a plausible and important report.

    Why “Autonomous” Is The Word That Matters

    Ransomware crews have used automation for years — mass scanners, exploit kits, off-the-shelf loaders. What Sysdig is reportedly describing is different in kind: an AI agent that plans and adapts rather than executing a fixed script. In agent architectures, a language model is given a goal, a set of tools (shell access, network utilities, credential stores) and permission to iterate until it succeeds or gives up. If the report holds up, the notable step is not that malware ran on its own, but that decision-making — normally the human’s contribution — was delegated to software.

    The distinction matters because defenders have historically exploited the human bottleneck. Every hour an operator spends deciding what to do next is an hour a SOC can use to detect them. Autonomous agents narrow that window.

    Economics: Scaling Attacks Without Scaling Headcount

    Ransomware is a business, and its unit economics are constrained by affiliate labor. Recruiting, vetting, and paying human operators is expensive and risky for the crews at the top of the pyramid. An autonomous agent, if it works reliably, lowers that cost floor. The same operator could in principle run many concurrent intrusions, each customized to the victim environment, without a proportional increase in staff.

    The flip side is reliability. Language model agents are known to hallucinate, loop, and make confidently wrong choices. Whether Sysdig’s observed agent achieved its objective through skill or luck is the kind of detail that separates a novelty from a business model. The public summary does not settle that question.

    Implications For Infrastructure Buyers

    For enterprises buying cloud, colocation, and connectivity, the near-term takeaway is not panic but pressure on already-known controls. Identity hygiene, least-privilege access, tested backups, egress monitoring, and behavioral detection at the workload layer — the fundamentals Sysdig itself sells into — matter more, not less, if attacker tempo increases. Providers that offer runtime detection, immutable backups, and rapid isolation of compromised workloads have a clearer story to tell.

    There is also a governance dimension. If an attack is driven by an AI agent, questions of attribution, evidence preservation, and even insurance coverage become murkier. Incident responders will want to capture not just the malware artifacts but the agent’s prompt history, tool calls, and model provenance where possible.

    Reading The Claim Fairly

    “First” claims in security are notoriously hard to verify. Autonomous or semi-autonomous offensive tooling has been demonstrated in research settings and hinted at in underground forums for at least two years. Sysdig may well have observed the first in-the-wild case that meets a strict definition of full autonomy, but the industry should ask what that definition is: Did a human select the target? Approve the ransom demand? Handle negotiation? Each answer changes how landmark the milestone really is.

    None of that diminishes the direction of travel. Whether this specific case is the first or the fifth, agent-driven intrusions are a plausible near-term trajectory, and treating the report as a prompt to stress-test defenses is a reasonable response even before every detail is independently confirmed.

    Background

    Ransomware has evolved over the past decade from opportunistic file-encrypting malware into an organized affiliate economy, in which core developers license their tooling to human operators who conduct intrusions and split proceeds. Detection and response strategies have been built largely around the pace and habits of those human affiliates.

    In parallel, the rise of large language models has produced “agent” frameworks that let AI systems use tools, browse, execute code, and pursue goals across many steps. Security researchers have warned since at least 2024 that the same capabilities that make agents useful for legitimate automation make them attractive for offensive operations. Sysdig’s reported finding, if it holds up to scrutiny, marks the point at which that warning moves from theory into documented practice.

    Source: AI Agent Conducts First Fully Autonomous Ransomware Attack – The HIPAA Journal — reporting on Sysdig’s research documenting what it describes as the first end-to-end ransomware intrusion driven by an autonomous AI agent.

  • Apple Expands Private Cloud Compute: Securing AI Inference at Scale

    Apple Expands Private Cloud Compute: Securing AI Inference at Scale

    Apple’s Security Research team published a post titled “Expanding Private Cloud Compute” on June 7, 2026, signaling growth of the company’s purpose-built cloud platform for AI inference. Private Cloud Compute (PCC) is the system that handles Apple Intelligence requests too demanding for on-device processing, running them on Apple-designed servers engineered so user data is never stored and never accessible to Apple itself.

    The post comes from Apple’s own security engineers rather than its marketing organization — a channel Apple has used since 2024 to document PCC’s architecture in unusual technical depth.

    Executive Summary

    Apple announced an expansion of Private Cloud Compute, the custom infrastructure it launched in June 2024 to extend its device security model into the data center. PCC’s core promise is that cloud AI requests are processed statelessly on Apple silicon servers, with no persistent storage, no privileged operator access, and cryptographic attestation that lets a user’s device verify the exact software a server is running before sending it anything.

    An expansion matters beyond Apple’s ecosystem because PCC is one of the few production systems that treats AI inference privacy as a hardware-enforced property rather than a contractual promise. As enterprises weigh where to run sensitive AI workloads, Apple’s approach has become a reference point that pressures cloud providers, chipmakers, and data center operators to raise the bar on verifiable, confidential inference.

    The syndicated item we reviewed carries the headline and publication date only, so the scope of the expansion — capacity, regions, hardware, or new capabilities — is analyzed here in the context of what Apple has previously disclosed, with open specifics noted below.

    Why Verifiable AI Inference Is Hard

    Conventional cloud privacy rests on policy: contracts, audits, and access controls that customers must ultimately take on trust. PCC was designed to replace that trust with verification. Servers run a hardened operating system with no remote shell or administrative access, computation is stateless — meaning a request is processed in memory and discarded, never written to disk — and every production software image is published to a public transparency log. An iPhone or Mac will refuse to send a request to any server whose cryptographic measurements do not match a logged, inspectable build.

    That last mechanism is the genuinely novel part. It means Apple cannot quietly deploy a modified server build to a subset of machines without either publishing it for researcher scrutiny or cutting those machines off from all client traffic. For an industry accustomed to “we don’t look at your data” assurances, an architecture where the client enforces the promise is a meaningful shift.

    Custom Silicon as a Security Strategy

    PCC runs on Apple-designed silicon in Apple-operated data centers, carrying over device-grade protections such as Secure Boot and the Secure Enclave, a dedicated coprocessor that guards encryption keys. Vertical integration is what makes the attestation story coherent: when one company controls the chip, the boot chain, the operating system, and the model runtime, there are far fewer seams where a component from another vendor must simply be trusted.

    The trade-off is cost and scale. Hyperscalers pursue related goals with confidential-computing technologies — trusted execution environments from Intel, AMD, and Nvidia that encrypt data even during processing — which work across heterogeneous fleets but involve more parties in the trust chain. Apple’s approach is cleaner but only Apple can run it, which is precisely why its expansion is watched as a benchmark rather than adopted as a template.

    What Expansion Signals for the Infrastructure Market

    Growing PCC means growing a fleet of custom inference servers, and that carries familiar data center consequences: more capacity, more power, and continued momentum behind purpose-built AI silicon as an alternative to general-purpose GPU clusters. It also confirms that private, server-side inference — not just on-device AI — is central to Apple’s long-term Apple Intelligence roadmap.

    For enterprises and infrastructure buyers, the competitive effect may matter most. Every vendor now selling “private AI” will increasingly be asked the questions PCC was built to answer: Can I verify what software processed my data? Who holds the keys? What happens to the request after the response is returned? Providers that can answer with attestation rather than assurances stand to win the most sensitive workloads.

    Background

    Apple introduced Private Cloud Compute in June 2024 alongside Apple Intelligence, positioning it as an extension of the iPhone’s security model into the data center: custom Apple silicon servers, a hardened operating system, stateless processing, and a public transparency log that lets devices verify server software before use. In October 2024 Apple opened the system to outside scrutiny, publishing a detailed security guide, releasing a Virtual Research Environment for researchers, open-sourcing portions of the code, and offering bounties up to $1 million for critical PCC exploits.

    The Security Research blog has since served as Apple’s channel for documenting PCC’s evolution — an unusually technical window into production AI infrastructure from a company historically known for secrecy, and one of the few public accounts of securing large-scale AI inference end to end.

    Source: Expanding Private Cloud Compute – Apple Security Research, Apple’s security engineering blog post announcing growth of its Private Cloud Compute AI inference platform, published June 7, 2026.

  • Offensive Cyber Goes Mainstream in Statecraft

    Offensive Cyber Goes Mainstream in Statecraft

    Federal News Network reports that governments around the world increasingly assume offensive cyber operations will be a standing instrument of state power, on par with diplomatic, economic, and military tools. The framing marks a normalization of capabilities that were once treated as exceptional or covert.

    The account, published 23 May 2026, does not announce a specific operation. Instead, it describes a doctrinal shift: offensive cyber is being written into how states plan to compete, coerce, and defend interests.

    Executive Summary

    The story matters because doctrine drives budgets, authorities, and targets. When offensive cyber moves from a niche capability to an assumed lever of statecraft, more governments build teams, more contractors sell tools, and more operations occur below the threshold of armed conflict.

    For operators of critical infrastructure — data centers, fiber networks, cloud platforms, and the utilities that feed them — the practical consequence is a threat model that must assume patient, well-resourced, state-directed adversaries as a baseline, not an edge case.

    The Federal News Network piece is a framing article rather than a disclosure of new incidents, so its value is directional: it signals where policy and procurement are headed, not which systems are already in the crosshairs.

    From Exception To Instrument

    For much of the internet era, offensive cyber operations were treated as sensitive, compartmented, and rare — the province of a handful of intelligence agencies. The shift Federal News Network describes is that governments now plan around the assumption that these tools will be used, much as they plan around sanctions or naval patrols. That reframing changes procurement priorities, legal authorities, and the willingness to conduct operations in peacetime.

    The economic effect is a broader market for offensive capabilities: exploit brokers, red-team contractors, and specialist training. It also creates a larger surface for spillover, because tools developed for one target frequently leak, get repurposed by criminals, or hit unintended systems on shared infrastructure.

    What Changes For Infrastructure Operators

    Data center, connectivity, and cloud providers have long assumed criminal threats — ransomware crews, credential thieves, DDoS extortionists. A doctrine that normalizes state offensive cyber pushes a different profile to the top of the risk register: adversaries with time, custom tooling, insider recruitment budgets, and tolerance for long dwell times. Detection engineering, supply-chain hygiene, and incident-response rehearsal all cost more against that adversary.

    There is also a jurisdictional dimension. Operators sitting between hyperscale customers and regulated verticals — finance, health, energy — increasingly find themselves inside the blast radius of geopolitical disputes they are not party to. Contracts, insurance, and liability frameworks written for criminal threats do not always map cleanly onto state activity, which is often excluded from cyber insurance policies as an act of war.

    Norms, Deterrence, And The Questions No One Has Answered

    A durable question is whether normalization deters or invites conflict. Advocates argue that visible capability, like nuclear posture, creates restraint. Skeptics note that cyber operations are cheaper, more deniable, and less escalatory-looking than kinetic force, which historically lowers the threshold for use rather than raising it. The public record does not yet settle that debate, and reasonable analysts disagree.

    It is also fair to ask pointed questions of every side. Governments framing offensive cyber as routine should explain oversight, targeting rules, and civilian protection. Vendors selling the shift as inevitable should show evidence, not just marketing. And critics who characterize any state cyber activity as reckless should engage with the reality that adversaries are already operating whether or not one’s own government does.

    Background

    Offensive cyber operations have been part of statecraft since at least the early 2000s, with disclosed incidents ranging from industrial sabotage to election interference and prepositioning inside critical infrastructure. What has shifted over the past decade is the number of governments openly building such capabilities and the willingness to acknowledge them in doctrine and budget documents.

    For infrastructure providers, the practical backdrop is that data centers, subsea cables, cloud regions, and internet exchanges are increasingly viewed by states as strategic terrain. That framing brings new regulatory attention, new customer expectations, and new adversary interest, regardless of whether an individual operator wants a role in geopolitics.

    Source: Governments increasingly assume they’ll use offensive cyber tools as part of state power — Federal News Network framing article on the normalization of offensive cyber in statecraft.