Reading

Insufficient investment in bank cybersecurity is typically attributed to free-rider problems: one bank's protective investments benefit the entire financial network, but the costs are borne individually, leading to collective underinvestment driven by individual rationality. In their 2026 model published in the Review of Finance, Anand, Duley, and Gai identify another opposing force—the threat of bank runs itself can incentivize banks to increase cybersecurity investments.

The mechanism works as follows: a successful cyberattack could disrupt operations and shake creditor confidence, prompting depositors or financiers to withdraw funds or refuse to renew financing. Anticipating these consequences, banks have stronger motives to prevent attacks. The authors thus identify two opposing forces: free-riding discourages cybersecurity investment, while the threat of a run encourages it. When rollover risk is sufficiently high, the latter may outweigh the former, causing banks to invest more in cybersecurity than the socially optimal level.

The direction of this conclusion depends on the failure-driving mechanism. The model distinguishes two scenarios: when failure is driven by insolvency, bank and creditor actions reinforce each other—higher cybersecurity investment leads to a higher debt burden, which in turn strengthens protection incentives, creating a positive feedback loop; when failure is driven by illiquidity, additional cybersecurity investment instead lowers the debt burden, eliminating the bank's risk-return trade-off and dissipating the incentive effect. This implies that regulatory correction tools need to be designed separately for different margins (the protection margin or the resilience margin).

The model also distinguishes between two dimensions: cybersecurity (preventing attacks) and operational resilience (continuing operations after an attack). Stronger cyber threats tend to encourage investment in resilience, while higher rollover risk strengthens preventative cybersecurity investment. The two are complementary but compete for limited resources, requiring banks to allocate resources between protection and recovery.

For investors in the financial sector, the practical implication of this framework is: when assessing a bank's cybersecurity level, one cannot look at technology investment figures in isolation but must combine them with the fragility of its funding structure. A bank with high rollover risk may not invest in cybersecurity out of prudent management, but rather as a byproduct of bank run threats—meaning its protection levels are sensitive to changes in its funding structure, and investments may recede once financing conditions improve. Meanwhile, different banks, custodians, and service providers in a portfolio may rely on the same technological infrastructure; a disruption affecting a single critical provider could simultaneously impact multiple holdings, constituting a concentration risk that diversification cannot eliminate.

US semiconductor manufacturer Texas Instruments Incorporated announced in an SEC Form 8-K filing dated November 9, 2026, that it has consummated the issuance and sale of $2 billion in aggregate principal amount of unsecured senior notes. The offering was divided into four equal tranches of $500 million each: 5.000% Notes due 2028, 5.350% Notes due 2031, 5.500% Notes due 2033, and 5.750% Notes due 2036.

The transaction was conducted pursuant to an underwriting agreement dated October 26, 2026, with J.P. Morgan Securities LLC, Citigroup Global Markets Inc., BofA Securities, Inc., and U.S. Bancorp Investments, Inc. acting as representatives of the several underwriters. The notes were issued under Texas Instruments' Registration Statement on Form S-3 filed in February 2025.

While the filing confirms the completion of the financing, it does not specify the intended use of proceeds. This event indicates Texas Instruments' successful access to long-term capital markets at fixed rates, which may influence its future capital expenditure flexibility and balance sheet management.

In November 2026, Jeanette Manfra, Vice President of Risk and Compliance at Google Cloud, published an analysis based on corporate research, with the core conclusion that the legacy software systems upon which enterprises rely for operations are acting as an 'innovation tax,' actively hindering the AI transformation that leaders are attempting to advance. She partnered with Hypothesis Group to investigate 1,250 enterprise IT and business decision-makers in the United States, aiming to quantify the specific forms of this friction.

The mechanism described by Manfra is a zero-sum game. As AI-driven vulnerability discovery accelerates, the number of flaws exposed in legacy codebases has exceeded the actual processing capacity of human security teams. IT teams are not unwilling to shift toward AI modernization; rather, their engineering cycles are fully occupied by daily patching and maintenance. In the survey, 49% of respondents indicated that reliance on on-premises software has actively delayed, reduced the scope of, paused, or canceled AI or other technology projects. This proportion approaches half, meaning that for nearly half of the responding enterprises, the maintenance costs of legacy systems have directly crowded out resources for AI investment.

However, Manfra believes that enterprises' continued reliance on legacy environments may not stem from architectural preference, but from vendor lock-in. 39% of decision-makers reported that dependence on legacy software and their cloud providers forces them to navigate complex licensing rules, contract terms, or limited negotiating flexibility. She describes this concentration of single-vendor dominance—where operating systems, productivity applications, cloud hosting, and emerging AI models all come from one provider—as a massive single point of failure risk. She wrote that the security of an autonomous AI agent depends only on the operating system and network it traverses; when the underlying technology stack is vulnerable, organizations are not deploying resilient intelligence, but expanding their attack surface.

The survey also showed that 80% of leaders believe a provider's existing installed base should not determine which AI technology an organization adopts, and 78% believe that providers who led the previous era of enterprise technology may not be best suited to lead the AI era. Based on this, Manfra proposed three recommendations: demand freedom in architecture and vendor selection; promote secure-by-design foundations to eliminate entire classes of vulnerabilities before code release rather than patching afterward; and for organizations already running millions of lines of legacy code, deploy AI-driven defense to continuously discover active exploitation paths, prioritize critical exposures, and automate remediation.

It is worth noting that the publisher of this analysis is itself a supplier of cloud and AI services. Google Cloud mentions in the text that 'nearly 90% of the Fortune 100 are already using Gemini Enterprise to build, scale, and govern agents,' which serves as both background information and commercial positioning. The survey was commissioned by Google Cloud, and its directional conclusions—shifting from local legacy systems to cloud-native architectures—are consistent with the publisher's commercial interests. This does not mean the data itself is unreliable, but readers should be aware of this interest structure when applying the 'innovation tax' framework to their own decision-making, and independently assess whether the technical debt in their own organizations truly constitutes an obstacle to AI modernization to the same extent.

US networking giant Cisco announced on November 9, 2026, that its enterprise AI security solution, "AI Defense," will integrate Anthropic’s Claude Mythos model to strengthen its adaptive AI red teaming framework. This marks one of the first instances where frontier large language model reasoning is directly embedded into enterprise security testing workflows.

Cisco stated that while standard red teaming detects common vulnerabilities like prompt injection and jailbreaks, it often misses unique risks arising from AI agents connected to complex toolchains in specific organizational environments. The new adaptive red teaming allows users to define testing criteria in natural language; the system analyzes the target and generates tailored attack scenarios. Claude Mythos contributes by generating attack ideas and payloads, but operates under strict controls: it targets only customer-authorized systems, has no open interface for free prompting, and all actions are audited and attributed to a named operator.

Michael Moore, Cybersecurity Lead at Anthropic, noted that enterprises want to thoroughly test their AI agents before deployment, and integrating Claude Mythos helps security teams use advanced reasoning to plan tests and generate attack ideas. Cisco emphasized that this deployment reflects a broader trend of making frontier security capabilities available to defenders under verified, controlled access.

Standard and adaptive red teaming are currently available in AI Defense, but the integration with Claude Mythos is not yet generally accessible. Cisco said the feature is "coming soon" for select enterprises, with broader availability planned on a when-and-if-available basis.

Most enterprise AI deployments go live with only one guardrail: the model's own judgment. In a November 2026 blog post, Johnny Mai, Director of Product Strategy for Qwen at Alibaba Cloud, wrote that incidents under this setup are typically discovered by customers first, rather than through internal monitoring. His core concept is the 'guardrail tax'—the sum of latency and token costs paid for every request to ensure safe deployment. The key argument is that the goal is not zero tax, but a known tax.

Mai arranges seven controls along the request path: input filtering (intercepting jailbreaks and prompt injection before the model call), output moderation (checking generated content before the user sees it), PII handling (masking data at three points: the model, tools, and logs), tool permissions (separating read/write access, whitelisting systems, and requiring approval for irreversible actions), spend caps (setting limits per request/user/day/step), human escalation (defining which results enter a human review queue), and logging & evaluation (end-to-end tracing and re-running fixed test sets on every change). He emphasizes that order itself is part of the guardrail: controls placed in the wrong position protect nothing.

The cost argument is the most actionable part of the article. Mai uses a set of explicitly labeled 'illustrative' assumptions for his calculation: 1 million requests per month, using qwen3.8-max (Singapore region, $2.00 input/$6.00 output per million tokens), with 2,000 input tokens and 400 output tokens per request, resulting in a monthly cost of $6,400. Guardrail checks use qwen3.8-flash (input $0.15/million tokens), sending an extra 200-token instruction and returning a 10-token verdict per check, costing $174.40 monthly. The guardrail tax is 2.7%. He also notes that if using the managed Guardrails service in Model Studio, a billing rule applies: requests under 1,000 tokens are billed as 1,000 tokens, meaning actual costs in short-conversation scenarios could be 2.9 times the text cost itself.

Regarding latency, Mai presents three designs: sequential checks add about 10% latency; parallel input checking (discarding the answer if flagged) adds about 5%; and streaming output checks (checking token-by-token during generation) do not increase first-token latency, though flagged answers are truncated mid-stream. His conclusion is that latency is a design choice, not a fixed penalty.

Half the article is dedicated to warning against symmetric failures: over-blocking. Mai performs a similar magnitude of calculation—assuming a 2% false block rate on 1 million requests, 20,000 legitimate requests are blocked monthly. At 5 minutes of support ticket handling per block, this requires approximately 1,667 hours of labor monthly, equivalent to ten full-time staff absorbing the cost of a guardrail tuned once and never revisited. He lists four signs that guardrails are backfiring: rising block rates without traffic changes, one category dominating blocks, escalation queues filled with obvious cases, and teams requesting exceptions via email.

Gravity compensation is a fundamental validation for robotic torque control: motors continuously calculate and output torques that exactly counteract their own weight, allowing the robotic arm to be guided by hand while feeling weightless.

Holoscan 5 decomposes this loop into three operators: JointStateSourceOp reads the state of seven motors every 2.5 milliseconds; PinocchioGravityOp invokes Pinocchio’s Recursive Newton-Euler Algorithm (RNEA) to compute gravity torques when state data arrives; and MotorCommandSinkOp sends commands to the motors. These three operators are grouped into a single partition named 'control,' where their callbacks execute serially on one thread at runtime, avoiding cross-thread handoffs and unnecessary system calls. The queue depth between operators is set to one with a drop-oldest policy, ensuring that expired samples do not accumulate.

NVIDIA used NVTX annotations in Nsight Systems to measure latency distributions across four configurations. For the C++ implementation, p99.99 latency dropped to 17.2 microseconds when pinned to a CPU core, compared to 86.6 microseconds when unpinned; for the Python implementation, it dropped to 142.6 microseconds when pinned versus 1373.5 microseconds when unpinned. Pinning plus isolation reduced C++ p99.99 latency by approximately 5 times and Python by approximately 9.6 times. Both implementations call the same Pinocchio C++ solver, but the Python version incurs additional overhead from interpreter execution, object allocation, and Global Interpreter Lock (GIL) coordination before and after the solver.

This comparison demonstrates that in CPU control loops with microsecond-level latency budgets, language runtime overhead is the primary variable. For GPU-accelerated workloads taking milliseconds to tens of milliseconds, these overheads are usually less critical, making Python a practical composition choice—provided pipeline components are implemented in CUDA. Tutorial code and full build instructions have been made public in the Holoscan 5 SDK repository, supporting Jetson Orin Nano, Jetson Thor, and x86 Ubuntu 24.04 systems.

Most document extraction tasks can be completed in a single pass: read the content, locate the corresponding values according to the schema, and return structured results. From the outset, the Microsoft Azure Content Understanding team designed this as the default path. However, in a blog post on November 9, Principal Product Manager Joe Filcik pointed out that there is a category of tasks that cannot be solved with a single inference—answers are scattered across different pages, require exclusion before normalization, involve cross-row calculations, or need a different perspective to re-examine after the initial read.

He used data from the U.S. Department of the Treasury to illustrate this boundary. The schema requires extracting the total agency outlays for January 2003, but the relevant data is distributed in tables spanning two pages within a 137-page bulletin. Not every number in the row for that month should be included—receipt items and reported totals need to be excluded, revision marks need to be removed, and negative signs need to be retained. The final calculator yields $180,681 million. Filcik emphasized that a single-pass model must simultaneously handle page relationships, exclusion rules, symbol annotations, and arithmetic; this is precisely where the agentic mode intervenes.

The mechanism of agentic mode is not simply increasing the number of conversation turns. Filcik described it as wrapping the language model in a document-native harness: a reasoning loop equipped with tools for navigating document text and tables, inspecting visual evidence, performing calculations, and validating results. The model first plans the steps, then calls the corresponding tools, and returns to the source document to re-check if necessary. The output is still defined by the schema, and the returned result remains structured fields.

He provided two additional examples to demonstrate the scope of this loop. A set of economic charts requires different interpretation strategies—the plotted numerical values alone are insufficient; subtitles, axes, and surrounding text jointly determine the meaning, and when the chart is ambiguous, the process can return to the source file for re-verification. Another network log spanning 19 pages requires merging the same table into a unified view, ignoring repeated headings, and then filtering rows based on conditions to count or sum them. Filcik specifically pointed out a common trap: inferring the total count from the first and last event IDs seems quick, but the IDs have gaps, so one must count page by page.

Standard mode and agentic mode are not old versus new replacements, but two points on a price-performance curve. The agentic mode consumes more tokens and typically takes longer. Filcik's advice is to start with standard mode; when the task involves synthesizing evidence across content, calculations or reconciliation, exhaustive analysis of long documents, complex rule conditions, or difficult visual structures, then try the agentic mode. Compare both modes on representative files and decide whether the quality improvement justifies the extra cost and latency.

Modern AI workloads rarely execute in just one place. A task may start in a high-level framework, switching back and forth between native CPU code and kernels running on a GPU. When bugs cross these boundaries, developers need to understand both the host application and the device state simultaneously. In a technical article published in November 2026, Greg Clayton and other Meta engineers explained how their accelerator plugin architecture in LLDB's lldb-server addresses this challenge, and why they chose to represent CPUs and GPUs as separated debugging targets rather than merging them into a single process.

Traditional debuggers operate on an implicit assumption: a process has only one architecture, and views of threads, registers, and memory are consistent. GPU programs break every one of those assumptions. A host process might run on x86-64, while its kernels use a completely different instruction set; CPU threads have familiar register contexts, but GPUs synchronize execution in lane groups and can expose thousands of execution lanes; host and device pointers can point to different address spaces, where the same address, such as 0x1000, might refer to entirely different locations in the CPU and GPU processes.

Forcing all this state into an artificial process model makes the debugger exceptionally complex. Every operation must first determine whether it applies to the CPU or the GPU. Register handling, memory reads, breakpoints, stepping, and stop events all become conditional logic dependent on the selected hardware. Consequently, the Meta team chose the opposite path: giving these differences a clear boundary.

The specific approach introduces a plugin interface in lldb-server. lldb-server is the companion process for LLDB, responsible for launching or attaching to target programs and performing low-level debugging operations, with the LLDB client communicating via the GDB remote protocol. Since lldb-server already controls the native process, it is also the correct location to coordinate with accelerator runtimes. Hardware vendors implement a backend plugin that translates their device's debugging API into concepts LLDB already understands—processes, threads, registers, memory, modules, and stop reasons.

This separation brings three practical consequences. First, the LLDB client remains vendor-neutral, meaning common improvements to the command line, remote protocol, symbol handling, and IDE integration benefit all accelerators. Second, each vendor is only responsible for details unique to its hardware and driver stack. Third, GPU debugging support is activated only when the debugged application uses a supported GPU runtime; for pure CPU applications, LLDB and lldb-server continue along the existing native debugging path without incurring any runtime computational overhead.

During a debugging session, the CPU and accelerator each become a separate LLDB target, possessing their own architecture and debugger process, maintaining their respective threads, registers, address spaces, and execution states. To the debugger, the two targets remain technically independent; to the developer, they can appear in the same LLDB or IDE session. Coordination is achieved through a set of structured actions: plugins can request setting internal breakpoints in the host process, which identify important runtime events (such as the moment a GPU debugging session can begin); when the host reaches these points, lldb-server notifies the plugin, which initializes the vendor debugging API and prepares the accelerator debugging endpoint; LLDB then creates a second target for the accelerator and connects.

Elastic, the search, security, and observability platform company, announced on November 9, 2026, that it has achieved ISO/IEC 42001:2023 certification for its Artificial Intelligence Management System (AIMS). This standard is the first international benchmark for AI management systems, requiring organizations to meet specific criteria for establishing, implementing, maintaining, and continually improving their AI governance.

The certification covers the development and operation of Elastic's core AI capabilities, including Elastic Agent Builder for building context-aware AI agents, Elastic AI Agent for investigating alerts and analyzing logs, the Elastic Inference Service (EIS) for managing inference, and Jina embedding and reranking models hosted on EIS.

Elastic stated that this independent third-party audit result aims to provide customers with confidence to adopt AI at scale on mission-critical data. For customers, the certification helps simplify vendor assessments in security and procurement reviews and supports their own compliance efforts through a framework closely aligned with regulations such as the EU AI Act.

US-based enhanced geothermal energy company Fervo Energy disclosed in its third-quarter earnings report released Monday that its contracted revenue has reached $11.9 billion, a significant increase from $7.2 billion in the previous quarter. This jump reflects the surging demand for electricity from hyperscalers building AI data centers and Fervo's progress in securing orders and meeting delivery deadlines.

Fervo is currently constructing a 396-megawatt power plant for Google at Cape Station in Utah, scheduled to be grid-connected by the end of 2028. The project, now named "Cape Google 400," allows Google to draw power or sell it to other customers if not immediately needed. Co-founder and CEO Tim Latimer stated that both parties are proceeding on independent schedules. Earlier this year, Fervo successfully connected its first 100-megawatt plant to the grid.

Beyond order growth, Fervo's unit economics are improving. The company reported that the first phase of Cape Station cost $7,000 per kilowatt of capacity, while the Google project's cost has dropped to $5,500 per kilowatt. This reduction suggests Fervo is effectively lowering costs through deeper wells and standardized modules called GeoBlocks. With subsidies, this cost level is roughly equivalent to a new natural gas plant running on fuel priced at $6 per million BTUs, narrowing the gap with conventional sources.

Despite these advances, Fervo remains in an early stage of development. The company posted an operating loss of $43.7 million for the quarter but holds $1.9 billion in cash and equivalents, providing ample runway. Fervo's long-term target is to reduce costs to $3,000 per kilowatt, which would allow it to significantly undercut natural gas power even at current market prices, potentially cementing its role in the AI infrastructure supply chain.

Following Nvidia's board announcement of an independent investigation into CEO Jensen Huang, several U.S. shareholder rights law firms have moved quickly to launch securities fraud probes. TechCrunch reports that Schall, Brown & Schwartz, a Los Angeles-based firm, was among the first to announce an investigation into whether Nvidia made false or misleading statements or failed to disclose pertinent information to investors. Robert Bartlett, a Stanford Law professor and securities law expert, expects many other firms to follow suit, noting that a lawsuit could have been filed by Monday's close.

The legal action centers on Nvidia's previous public statements. When The New York Times first reported last month on Huang's ties to Alice Huang, an executive at Singapore data center company Megaspeed, an Nvidia spokesperson described the relationship as "not unusual or unexpected," stating that Megaspeed was no different than other regional cloud customers. However, after Huang acknowledged an intimate relationship to the board, and reports emerged that U.S. intelligence had monitored Alice Huang for over a year on suspicion of spying for China, experts view the earlier statement as "clearly a misleading statement." As CEO, Huang's knowledge is legally imputed to the company.

Bartlett explains that these cases typically rely on the "fraud on the market" theory, where investors argue they paid inflated prices based on false or incomplete public information and suffered losses when the truth emerged and the stock dropped. Nvidia's shares slid more than 4% on the first trading day after the board's announcement, providing a basis for calculating damages. Given Nvidia's status as one of the world's most valuable companies, potential settlements could be exceedingly expensive. Such litigation often settles after long proceedings, with payments coming from the company and its directors-and-officers insurers, though shareholders ultimately bear the cost through premiums or direct impacts.

Beyond direct securities claims, Nvidia faces governance risks. If the investigation reveals that directors failed in their oversight duties or lacked proper reporting lines to escalate critical risks once media reports began, board-level liability is possible. A third category of exposure would arise if the board finds Huang knew about the intelligence connection, which Bartlett calls "a whole other ball game." This could theoretically lead to SEC officer-and-director bars, although current political dynamics make immediate regulatory action less likely.

A recent report by the Electronic Frontier Foundation (EFF) highlights a dramatic collapse in the number of Inter Partes Review (IPR) petitions filed with the Patent Trial and Appeal Board (PTAB), a unit of the U.S. Patent and Trademark Office (USPTO). Established by Congress in 2012, IPR allows the public to challenge improperly granted patents within the Patent Office at a fraction of the cost of federal court litigation. It has been a crucial line of defense against low-quality software patents used by patent trolls. However, USPTO leadership is increasingly refusing to consider well-founded challenges for reasons unrelated to their merits, rendering the process so unreliable that many potential challengers have stopped filing altogether.

According to USPTO trial statistics, only 97 IPR petitions were filed in the third quarter of 2026 (July–September), down from 327 during the same period in 2025—a drop of over 70%. Furthermore, the institution rate (the percentage of petitions accepted for full review) plummeted to 41% in fiscal year 2026, compared to a historical range of 66–68% between fiscal years 2022 and 2024. This means fewer people are attempting challenges, and those who do face significantly lower odds of having their case heard.

Beyond higher barriers to entry, USPTO Director John Squires has engaged in unprecedented retroactive intervention by vacating cases that had already been instituted. The report notes that Squires has vacated at least 29 institution decisions, terminating proceedings before a final written decision on the merits. In one notable example, Revvo Technologies v. Cerebrum Sensor Technologies, the Director reversed two separate institution decisions based on inconsistencies in claim construction arguments between different courts. Such actions destroy the predictability that previously encouraged companies to invest in IPRs as a viable defense strategy.

For the technology sector, the erosion of the IPR system signifies a sharp increase in defensive costs. Startups and software developers previously relied on this administrative process to quickly and cheaply clear invalid patents blocking product development. With this avenue closing, victims are forced into expensive and protracted federal court litigation. The EFF warns that if this trend continues, bad patents will regain their power as weapons for extracting settlements, stifling innovation and freedom to build new technology.