Strategic PartnersIssue 117 records
Palo Alto Networks
Palo Alto published three Nov. 10 AI-security announcements, and independent evidence complicates each. Its Cortex AES team said Claude Fable 5.2 scored a 0% attack success rate on the in-house Model Compass benchmark and that scores will feed model allow-lists in Cortex AES; the same day Notebookcheck reported Anthropic's own system-card figures of 4.09% injection success at 15 attempts, and 89.82% under an adaptive attacker without probes, driven largely by fallback to Opus 4.8, while a September preprint shows single headline attack rates often misrank defenses. Palo Alto also made a locally run Data Security MCP Server generally available for agents such as Claude Code, but a preprint scanning 10,655 MCP servers found credential and PII leakage above 10%. Finally, the eBPF-based Cortex Cloud Sensor claims up to 75% fewer resources than Palo Alto's standard sensor; a peer-reviewed study shows eBPF overhead ranges from about 1.5% to nearly 89% by workload and policy. No new U.S. SLED deployment evidence surfaced; relevance to agencies, campuses and research clusters is interpretive.
- Evidence records
- 7
- Cross-source patterns
- 3
- Evidence classes
- 3 vendor claim3 academic research1 independent reporting
- Outcomes
- 3 emerging3 cautionary1 mixed
- Source freshness
- 4 new this fortnight2 older, newly relevant1 recent
- Research completed
- 2026-11-11
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Palo Alto's 0% score for Claude Fable 5.2 meets Anthropic's own non-zero injection figures and evidence that single headline attack rates are often unreliable
On Nov. 10 Palo Alto reported a 0% attack success rate for Claude Fable 5.2 on its unpublished Model Compass benchmark and plans to offer those scores in Cortex AES for model allow-lists. The same day, Notebookcheck reported Anthropic's system-card figures: 4.09% injection success at 15 attempts, and 89.82% under a 200-attempt adaptive attacker without probes, driven largely by fallback to Opus 4.8. A September preprint found most agentic-security papers report no variance and that single runs misrank close defenses about 21% of the time. Interpretation: model scores are useful inputs but depend on attack budget, routing and method, so SLED approvals should require disclosure and local tests.
Operating questionWhat method details (attack budget, repetitions, routing, variance) will the organization require before a model-security score can support an AI model approval?
Supporting evidencePalo Alto Networks (Cortex Agentic Endpoint Security team)Notebookcheck (reporting on Anthropic's Claude Fable 5.2 system card)Chetan Pathade, Prathamesh Pawar, Shubham Patil (arXiv authors)
Palo Alto's locally run DLP MCP server versus research showing local MCP servers commonly leak secrets and PII into model context
Palo Alto's new Data Security MCP Server runs locally and lets agents such as Claude Code triage DLP incidents, with no metrics or permission details published. A preprint scanning 10,655 MCP servers found leakage rates above 10%, with credentials and PII crossing into LLM context through tool returns and logs. Interpretation: for agencies holding CJIS, HIPAA or FERPA data, 'local' describes the connector, not the data path; approval should include a data-flow and leakage review.
Operating questionWhich model provider receives DLP incident content when an agent uses the connector, and is that permitted for the agency's regulated data?
Supporting evidencePalo Alto Networks releases a locally run Data Security MCP Server that lets Claude Code, Cursor and other MCP agents query and act on enterprise DLP dataBiwei Yan, Minghui Xu, Yijun Yang, Boyang Ma, Xuelong Dai, Jingku Li, Yue Zhang (arXiv authors)
Palo Alto claims up to 75% fewer resources for its eBPF Cortex Cloud Sensor, while independent eBPF benchmarks show overhead swings with workload and policy
The Cortex Cloud Sensor launched Nov. 10 uses eBPF and claims up to 75% fewer resources than Palo Alto's standard sensor, without a published test. A peer-reviewed IEEE Access study of four open-source eBPF tools found overhead from about 1.5% to nearly 89% depending on workload and whether policies were enforced, plus log-loss and evasion limits. Interpretation: SLED platform teams should benchmark on their own process- and network-heavy workloads before enabling prevention.
Operating questionWhat CPU, memory and latency budget must a runtime sensor meet on each workload class before prevention mode is approved?
Supporting evidencePalo Alto Networks releases the Cortex Cloud Sensor, an eBPF-based lightweight XDR sensor for Kubernetes, containers and Linux workloads, claiming up to 75% fewer resourcesJin Her, Jongseop Kim, Jinwoo Kim, Seungsoo Lee (Incheon National University; Kwangwoon University)
Evidence ledger
Full record · every source keeps its link and limitations
Palo Alto Networks' Model Compass benchmark gives Claude Fable 5.2 a 0% attack success rate and says scores will feed model allow-lists in Cortex AES
Palo Alto's Cortex AES team says its in-house benchmark, Model Compass (also called Model Security Compass on the page), runs each model inside agent environments (inbox, browser, file store, code project with a shell) and tests hijacking via hidden instructions, rule override, credential leaks and fake-package recommendations. It reports that Claude Fable 5.2, released Nov. 9, had a 0% attack success rate across 'thousands of security tests' and completed 99.5% of paired harmless tasks. It says Claude Sonnet 4.5 scored 7.1% on the same tests and that the best model from every tracked vendor now lets fewer than 4% of attacks through. Palo Alto plans to make Model Compass scores available inside Cortex AES so security teams can decide which models their agents may use. The post itself cautions that a perfect score secures only the model, not the surrounding system.
Why it matters, evidence and limitations
- Why it matters
- State agencies, universities and research groups now choosing which frontier models coding and productivity agents may call will be offered vendor model scores as a control input. Interpretation: a model allow-list is a reasonable policy lever for SLED AI-use rules, but this benchmark is unpublished in method and conflicts with Anthropic's own system-card injection numbers for the same model, so it should not be the sole basis for approval.
- Evidence and measured results
- Opened and read the full post dated Nov 10, 2026. Quantities stated: 0% attack success for Fable 5.2, 99.5% benign-task completion, 7.1% for Sonnet 4.5, under 4% for each vendor's best model. Test count is given only as 'thousands'; no per-category results, attack budget, attempts per scenario, harness details, repeated runs or variance are published. A chart of attack success by model is referenced but its values were not available as text. The post does not say whether Anthropic's automatic fallback to Opus 4.8 was active during testing.
- Limitations and uncertainty
- Vendor-run, unpublished benchmark; no methodology paper, attack budget, repetitions or confidence intervals. Released one day after the model, so results may change as attackers adapt. Anthropic's system card, as reported by Notebookcheck in this edition, shows non-zero injection success for Fable 5.2 under adaptive attack and fallback conditions. Model Compass is not yet available to customers ('Soon').
Notebookcheck: Anthropic's system card shows Claude Fable 5.2 fallbacks to Opus 4.8 raise prompt-injection success for agents, contradicting a single 'perfect' score
Notebookcheck reports figures from Anthropic's Fable 5.2 system card. When safety classifiers flag a request, a less capable model answers (Opus 4.8 for cyber topics), and the checks review everything the model reads, including connector content, web results and files. On Gray Swan's indirect prompt-injection benchmark, attack success after 15 attempts was 4.09% for Fable 5.2 versus 1.02% for Fable 5.1 and 0.96% for Opus 5.5; 53% of attempts against Fable 5.2 were served by Opus 4.8. Attacks succeeded 2.05% of the time when Fable 5.2 answered and 5.17% when Opus 4.8 did. In an adaptive coding test with 200 attempts per scenario, 89.82% succeeded without safeguards (almost all answered by Opus 4.8), falling to 28.16% with Anthropic's product injection probes. Automatic switching is on by default in Anthropic's apps and can be turned off.
Why it matters, evidence and limitations
- Why it matters
- Public-sector staff using Claude in Cowork, Claude Code or the browser to read email, web pages or third-party code are the exposed users. Interpretation: it directly tempers Palo Alto's same-day 0% claim for the same model: model-level scores depend on test conditions, attack budget and routing, and SLED AI policies should address fallback settings explicitly.
- Evidence and measured results
- Opened and read the full article dated 11/10/2026. All numbers are attributed to Anthropic's system card and help page; Notebookcheck did not run its own tests. The system card itself is already archived on the site (Anthropic stream) and was not re-opened in this run; a second independent write-up (Kortress, Nov. 10) reports the same figures and adds that API fallback is off by default.
- Limitations and uncertainty
- Secondary reporting of vendor (Anthropic) measurements; not independent testing. Benchmarks use specific harnesses and attack budgets that differ from Palo Alto's, so the two results are not directly comparable. The article is consumer-oriented and does not address enterprise admin controls beyond the user toggle.
Preprint: 'Attack Success Rate Is Not a Number' finds most agentic-security papers omit variance and that single-run ASR comparisons often misrank defenses
Preprint, not peer reviewed. The authors argue attack success rate (ASR) is a family of metrics shaped by six rarely specified design choices. In a meta-analysis of 259 agentic-security papers posted to arXiv from February 2025 to September 2026, most reported neither variance nor repeated runs for their headline attack metric (58%, 95% CI 44-71, in a hand-coded sample of 50; 65.3% by automated coding of all 259). Only 30.9% disclosed enough about decoding to tell whether evaluation was stochastic, and 29.7% of 64 papers using an LLM judge reported any human agreement check. Analytically, on a 100-instance benchmark the minimum detectable ASR difference at conventional power is 18.2 points, and two defenses whose true ASRs differ by 5 points are misranked by a single run about 21% of the time. They propose a ten-item reporting checklist.
Why it matters, evidence and limitations
- Why it matters
- Why now: Palo Alto's Nov. 10 Model Compass post publishes headline ASRs (0%, 7.1%, under 4%) without attack budget, repetitions or variance, and plans to offer those scores as a control input. This study gives SLED evaluators a neutral checklist for asking what such numbers mean before using them in model approval or procurement.
- Evidence and measured results
- Opened the arXiv abstract page (v1, 21 Sep 2026; 7 pages, 2 tables, 2 figures; DOI pending registration). Figures above are from the abstract. The full PDF and checklist items were not read.
- Limitations and uncertainty
- Preprint, not peer reviewed; three authors; meta-analysis limited to arXiv papers, not vendor benchmarks. Analytical power figures assume a 100-instance benchmark. Full text not reviewed in this run.
Palo Alto Networks releases a locally run Data Security MCP Server that lets Claude Code, Cursor and other MCP agents query and act on enterprise DLP data
Palo Alto announced general availability of a Data Security MCP Server that connects its Data Security (enterprise DLP) product to MCP-compatible agents such as Claude Code and Cursor through existing public APIs. It runs locally in the customer's environment rather than as a vendor-hosted integration, which Palo Alto says keeps control over deployment, credentials and access. Listed uses are risk assessment, drafting and validating DLP policies, incident investigation, false-positive tuning, compliance auditing and reporting. A demo shows an analyst asking an agent to triage 90 days of incidents into clusters and separate real leaks from noise. No accuracy, time-saving or customer results are given.
Why it matters, evidence and limitations
- Why it matters
- State and local DLP teams protecting resident, health (HHS) and student (K-12, higher-ed) records are small and often backlogged on incident triage. Interpretation: natural-language triage could help, but it routes DLP incident details, which by definition involve sensitive data, into whichever AI model the agent host calls, so CJIS, HIPAA and FERPA data-handling rules must be checked before use.
- Evidence and measured results
- Opened and read the full post dated Nov 10, 2026, including use cases and the demo description. Claims of reduced manual work and faster decisions are unquantified. The post does not state what permissions the MCP server's API credentials require, whether write actions (policy changes) are possible, or how agent actions are logged.
- Limitations and uncertainty
- Vendor announcement; no metrics, customers or security architecture details. Applicability depends on the customer already licensing Palo Alto Data Security. The demo is illustrative, not a measured result.
Preprint: static analysis of 10,655 real-world MCP servers finds credential and PII leakage rates above 10%
Preprint, not peer reviewed. The authors argue that leakage in MCP servers is largely protocol-induced: credentials, API keys and personally identifiable information cross the local-to-LLM boundary simply by being returned, logged or raised inside a tool handler, with no explicit outbound request. Their MCPPrivacyDetector uses cross-language static and taint analysis; applied to 10,655 real-world MCP servers it finds leakage rates above 10%, with case studies of leaked bearer tokens, propagated API keys and plaintext authentication credentials.
Why it matters, evidence and limitations
- Why it matters
- Why now: Palo Alto's Nov. 10 Data Security MCP Server is pitched as safer because it runs locally, and SLED security teams are being invited to connect DLP data to agents. This study shows that local MCP servers still pass secrets and PII into model context, so the local framing does not by itself settle data-protection questions for regulated public-sector data.
- Evidence and measured results
- Opened the arXiv abstract page (v1, 19 Jun 2026, cs.CR; arXiv DOI 10.48550/arXiv.2606.21338). Figures are from the abstract; the full paper was not read, so per-category rates, false-positive rates and whether any vendor-published servers were included are unknown.
- Limitations and uncertainty
- Preprint, not peer reviewed. Static analysis of open-source servers; it did not evaluate Palo Alto's Data Security MCP Server. 'Above 10%' is an aggregate; the abstract gives no breakdown.
Palo Alto Networks releases the Cortex Cloud Sensor, an eBPF-based lightweight XDR sensor for Kubernetes, containers and Linux workloads, claiming up to 75% fewer resources
Palo Alto released the Cortex Cloud Sensor, described as a lightweight version of the Cortex XDR sensor for Kubernetes, containers and Linux cloud workloads. It provides anti-malware, exploit protection, process kill and file quarantine, runtime threat detection, process/file/network recording and file integrity monitoring, with alert context linking workloads, clusters, cloud accounts, identities and source code, and Cortex AgentiX agents recommending remediation. It uses eBPF for monitoring, deploys via Helm chart, DaemonSet or Linux installer, leaves vulnerability and configuration scanning to agentless tools, and is claimed to use up to 75% fewer resources than the standard Cortex sensor. The post cites Unit 42 data that attackers can exfiltrate in under 72 minutes.
Why it matters, evidence and limitations
- Why it matters
- State data centers, university research clusters and Kubernetes platforms often remove heavy agents for performance reasons and rely on agentless scanning, which cannot block attacks in progress. Interpretation: a lighter runtime sensor could close that gap, but the resource claim is relative to Palo Alto's own sensor and unmeasured against workloads typical of research computing.
- Evidence and measured results
- Opened and read the full post dated Nov 10, 2026. The 'up to 75% fewer resources' figure has no stated baseline workload, metric (CPU, memory) or test method. No customers, pricing or availability limits are given. The 72-minute figure is attributed to Unit 42's Incident Response Report and not re-verified here.
- Limitations and uncertainty
- Vendor announcement; resource and 'best-in-class' claims unverified. Independent research in this edition shows eBPF tool overhead varies widely by workload and policy, and eBPF monitoring has known evasion and log-loss limits.
IEEE Access study of four eBPF security tools on Kubernetes finds overhead varies sharply by tool and policy, and flags eBPF verifier, log-loss and evasion limits
The peer-reviewed study compares KubeArmor, Falco, Tetragon and Tracee on Kubernetes. In a process benchmark (running /usr/bin/ls 10,000 times, 10 iterations), overhead ranged from about 6.88% (Tetragon, no policy) to 37.59% (Tracee with policy). In a network benchmark of 100,000 UDP packets, overhead ranged from 1.48% (Tracee, no policy) to 88.59% (KubeArmor with policy), and Tetragon rose from 3.14% to 72.92% once a policy was enabled. The authors note trade-offs between enforcement speed and log loss, and list inherent eBPF limits: verifier constraints, weak integration with user-space controls, kernel-to-user bottlenecks that can drop events under load, and evasion via io_uring or avoiding standard syscall paths. AI-driven eBPF security platforms were out of scope.
Why it matters, evidence and limitations
- Why it matters
- Why now: Palo Alto's Nov. 10 Cortex Cloud Sensor relies on eBPF and claims up to 75% fewer resources than its standard sensor. This study gives SLED platform teams (state data centers, research clusters) an independent baseline showing overhead depends on workload type and policy, so they should test before committing. Transferability caveat: Korean university lab study of open-source tools, not U.S. public-sector production systems.
- Evidence and measured results
- Opened the author-hosted PDF and read the benchmark methods, results, insights and limitations sections. ANOVA results are reported with very small p-values. Commercial products, including Palo Alto's, were not tested.
- Limitations and uncertainty
- Tests open-source tools on micro-benchmarks, not the Cortex Cloud Sensor; results may not transfer to commercial sensors or real applications. Korean university research with a government grant; lab environment rather than production. Published 2025; included because it is newly relevant to the Nov. 10 sensor launch.
How to read this edition
Source findings, measured results and limitations come from the cited publications. Patterns, operating questions, role takeaways and implementation considerations are Lighthouse Advisory interpretation, stated as questions to validate locally rather than guaranteed outcomes. Vendor and operator claims are labeled as claims. Full research method.
- Vendor claim
- A supplier-provided assertion that has not been upgraded to independent evidence.
- Academic research
- Research produced through an academic institution or peer-reviewed venue.
- Independent reporting
- Independent reporting with attributable sources but without a formal evaluation design.