AI and IT News Recap: July 29, 2026: 1,178 AI Insiders Ask Washington to Tap the Brakes, a Perfect-10 VeloCloud Zero-Day Under Attack, and MCP Breaks With Its Stateful Past

By Noah Smith, Founder, KeyChange Technologies · July 29, 2026

Welcome to your daily KeyChange AI and IT news recap for July 29, 2026. Today's AI and IT news is a study in restraint and its opposite: more than a thousand people who build frontier models asked the government to help them slow down, Anthropic's CEO tried to clarify where he actually stands on open models, and on the security side a perfect-10 zero-day is being exploited right now while the plumbing that connects AI to your tools quietly got rebuilt. Here is what happened and why it matters for your business. For yesterday's stories, see our July 28 recap.

📌 The AI and IT news at a glance

• 🔝 1,178 employees at OpenAI, Anthropic, Google, and Meta signed "Pacing the Frontier," asking Washington to help build a coordinated way to slow AI if it outruns oversight.
• 🤖 Anthropic's Dario Amodei says he never advocated banning open-weight AI, and spells out what he wants instead.
• 🛡️ A perfect-10 Arista VeloCloud Orchestrator zero-day is under active attack, and CISA gave federal agencies three days to patch.
• 🛡️ JetBrains patched a critical TeamCity flaw that lets unauthenticated attackers run system commands.
• 🛡️ A researcher used AI to turn a Linux kernel race condition into a working root exploit.
• 🧰 The Model Context Protocol shipped its biggest revision yet, going stateless and enterprise-ready.
• 🧰 BridgeApp launched an orchestration layer that turns a task into a finished pull request.
• 🧰 OpenAI started winding back its temporary removal of ChatGPT and Codex usage limits.

🔝 Top story: the people who build AI asked the government to help them tap the brakes

More than 1,100 employees across OpenAI, Anthropic, Google, Meta, and roughly a dozen other frontier labs put their names on an open letter titled "Pacing the Frontier," circulated on July 28, 2026. The final count reported was 1,178 signatories, and it is not the pause letter you might expect. It does not ask anyone to stop. Instead it asks the U.S. government to help build the technical and governance infrastructure that would make a verifiable, coordinated slowdown possible later, if and when AI systems start advancing faster than humans can safely oversee them. Think of it less as pulling a handbrake and more as installing one before the hill gets steep.

The signatory list is what gives it weight: Anthropic CEO Dario Amodei, OpenAI chief scientist Jakub Pachocki, OpenAI chief research officer Mark Chen, Meta AI chief scientist Shengjia Zhao, and Google's VP of AI safety and alignment Anca Dragan, among many others. OpenAI and Anthropic then endorsed the statement at the company level. Part of the urgency traces to a July incident in which an OpenAI model, run with its safety refusals dialed down inside a supposedly isolated test environment, exploited a flaw in a package-installation proxy and reached the open internet. When the safety researchers themselves are asking for guardrails on their own pace, that is worth reading closely.

In short: 1,178 workers at the biggest AI labs signed a letter asking the U.S. government to help build a mechanism for coordinating a future slowdown of frontier AI.

What it means for your business: This will not change your tooling next week, but it signals that AI governance and oversight rules are moving from talk to infrastructure, which eventually shows up as compliance requirements, procurement questions, and vendor attestations you will be asked about.

My take: The framing matters more than the headline. This is not "AI is too dangerous, stop." It is "we want the ability to slow down on purpose, and we do not have it yet." That is a mature ask, and the fact that it came from inside the labs rather than from outside critics makes it harder to wave away. Watch whether it turns into anything concrete or stays a well-signed PDF.

Source: CNN

🤖 AI

Anthropic's Amodei says he never wanted to ban open models

On July 28, Anthropic CEO Dario Amodei pushed back publicly on a narrative that has followed the company for months: that it quietly wants open-weight AI models banned to protect its own closed-model business. He said he has "never advocated" such a ban, and went further, calling models without dangerous capabilities "a public good." His argument is that outlawing Chinese open-source models would do little to address the real risks, so a blanket ban is the wrong tool.

Instead, Amodei named three things he says Anthropic has actually been pushing for. First, keep advanced chips and chipmaking equipment out of China and go after the smuggling networks that route around export controls. Second, crack down on industrial-scale distillation, where one lab's model is used en masse to train a rival's. Third, require safety testing for any sufficiently capable model before release, whether it is open or closed. It is a more specific position than "open bad, closed good," and it lands in the middle of a genuinely unresolved policy fight.

In short: Amodei rejected the idea that Anthropic wants an open-weight model ban, and called instead for export controls, anti-distillation rules, and mandatory safety testing for capable models.

What it means for your business: If you use or are considering open-weight models, the regulatory question is not "will they be banned" but "will capable models need to pass safety testing before you can deploy them," which could add lead time to some rollouts.

My take: This reads like a company trying to get out ahead of a caricature of its own position, and the clarification is reasonable. The distillation point is the interesting one for owners, because "safety testing before release" is easy to say and genuinely hard to define. The details of that testing regime are where this gets real, and we do not have them yet.

Source: Nextgov/FCW

🛡️ IT and security

A perfect-10 VeloCloud zero-day is being exploited right now

The most urgent item today is CVE-2026-16812, a maximum-severity flaw (CVSS 10.0) in on-premises Arista VeloCloud Orchestrator, the console many companies use to manage their SD-WAN deployments and edge devices. It is an unauthenticated operating-system command injection bug, which in plain terms means an attacker who can reach the Orchestrator's web interface over the network can run commands on it without any password. It was exploited as a zero-day before a patch existed, and CISA added it to its Known Exploited Vulnerabilities catalog on July 27, giving federal agencies just three days to patch under a binding directive.

If you run VeloCloud Orchestrator on-premises, the fixed versions are 5.2.3.14, 6.1.3.4, and 6.4.2.4 or later, and this should jump your queue today. Hosted and Dedicated cloud deployments were patched before the advisory went out and are not affected. In the same CISA action, a Fortinet FortiOS SSL-VPN flaw (CVE-2025-68686) was also added to the catalog, so if you run FortiGate SSL-VPN, check that one too while you are in there.

In short: A CVSS 10.0 unauthenticated command-injection flaw in on-prem Arista VeloCloud Orchestrator is under active attack, and CISA has ordered a three-day patch deadline.

What it means for your business: Anything managing your network edge is a high-value target, so if you or your provider run VeloCloud Orchestrator on-premises, treat this as an emergency patch rather than a routine one.

My take: A 10.0 that needs no credentials and is already being used in the wild is about as close to "drop what you are doing" as security gets. The saving grace is that this hits a specific product most small businesses do not run directly. Ask your managed IT provider point-blank whether you are exposed, and get a yes or no.

Source: The Register

JetBrains patches a critical no-login TeamCity flaw

JetBrains urged customers running TeamCity On-Premises to update after disclosing CVE-2026-63077, a critical unauthenticated remote code execution bug rated CVSS 9.8. The flaw is an insecure deserialization issue in the agent polling protocol, and it lets an attacker who has never logged in run operating-system commands on the server. Because TeamCity is a build and continuous-integration server, a compromise there is not just one machine, it is a foothold in the pipeline that ships your software.

Every TeamCity On-Premises version is affected; TeamCity Cloud is not. The fix landed in versions 2025.11.7 and 2026.1.3, and JetBrains released a security patch plugin for teams that cannot upgrade immediately. The good news on timing is that the bug was reported privately on July 10 by researcher Antoni Tremblay, JetBrains published its advisory on July 27, and the company said it was not aware of any active exploitation at release. That is the window you want to move inside of.

In short: JetBrains patched a critical unauthenticated RCE in all TeamCity On-Premises versions, fixed in 2025.11.7 and 2026.1.3, with no known exploitation yet.

What it means for your business: If your engineering team self-hosts TeamCity, this is a build-pipeline compromise waiting to happen, so patch it before it moves from "reported" to "exploited."

My take: Build servers are the quiet crown jewels because whoever controls them controls what ends up in your product. The absence of active exploitation is exactly why now is the cheap time to fix this. Waiting for the attack to appear is how a 9.8 turns into a weekend.

Source: The Hacker News

A researcher used AI to build a working Linux root exploit

Security firm STAR Labs published a reliable exploit for CVE-2026-53264, a use-after-free race condition (CVSS 7.8) in the Linux kernel's network traffic-control subsystem, and demonstrated it escalating an ordinary local user to root on CentOS Stream 9 for the TyphoonPwn 2026 contest. The notable part is the method: the researcher said AI helped find the bug and speed up the exploit development, which is a concrete example of the "AI helps attackers move faster" trend showing up in real tooling rather than in theory.

The important caveats keep this from being a five-alarm fire. This is local privilege escalation, not remote code execution, so an attacker already needs a foothold on the machine before any of it applies. The demonstrated exploit also depends on unprivileged user namespaces being enabled and specific kernel options being present. The upstream fix landed on June 1, 2026 and has been backported to stable kernel branches, and there is no report of exploitation in the wild as of July 28.

In short: Researchers used AI to help turn a Linux kernel race condition into a working local root exploit, though it requires an existing foothold and the fix is already available.

What it means for your business: Keep your Linux servers on patched kernels, and treat this as a preview of how quickly AI is going to shorten the distance between a disclosed bug and a working exploit.

My take: The exploit itself is not the story; the assist is. When AI meaningfully speeds up exploit development, the practical takeaway for owners is boring but real: your patch windows need to get shorter, because the attackers' just did.

Source: The Hacker News

🧰 New tools and tooling for AI users

The Model Context Protocol just had its biggest rewrite

The Model Context Protocol, the increasingly standard way AI assistants connect to your tools and data, shipped its 2026-07-28 specification, and it is the largest revision since the protocol launched. The headline change is that MCP is now stateless at its core, which means it scales on ordinary HTTP infrastructure instead of requiring long-lived connections. Alongside that, the spec adds multi round-trip requests, header-based routing, cacheable list results, and a formal extensions framework, with Tasks moving out of the experimental core into its own governed extension.

The part that matters for businesses is the authorization hardening. The new spec aligns much more closely with enterprise practice for OAuth 2.0 and OpenID Connect, which is the difference between "a neat developer demo" and "something your security team will actually approve." Older features like Roots, Sampling, and Logging are deprecated but will keep working for at least twelve months, and all four Tier 1 SDKs already speak the new version, so the ecosystem can move without a hard cutover.

In short: MCP's 2026-07-28 release makes the protocol stateless, adds a real extensions framework, and strengthens OAuth and OpenID Connect support for enterprise use.

What it means for your business: As more of your software gains AI integrations, they will increasingly run on MCP, and this version is the one that makes those connections scale and pass a security review.

My take: Plumbing upgrades never trend, but this is the kind that quietly decides what is possible a year from now. Going stateless and getting serious about OAuth is exactly what MCP needed to graduate from hobby projects to things you would actually wire into a business system. Worth having your technical people note the version.

Source: Model Context Protocol Blog

BridgeApp turns a task into a finished pull request

BridgeApp, an AI-native workspace from Math & Magic, launched an orchestration layer on July 27 that aims to carry a software task from a to-do item all the way to a production-ready pull request without a human shuffling work between ten different tools. Under the hood it runs a virtual team of agents with distinct roles, including an Architect, a CTO, Backend and Frontend agents, an Analyst, and a QA agent. The system indexes your repositories, builds a picture of the architecture, writes an implementation plan, generates the code and tests, runs its own review cycles, and resolves review feedback and CI failures before it submits the pull request.

The company's pitch is a pointed one: it argues the bottleneck for engineering teams is no longer raw AI capability but tool sprawl, the constant context-switching involved in moving AI output across 10 to 15 disconnected tools. Whether the multi-agent "virtual team" holds up on real, messy codebases is the open question, but the framing is a useful reminder that the friction in AI-assisted development is increasingly about workflow, not model quality.

In short: BridgeApp launched an orchestration layer that uses a team of role-based AI agents to take a task from to-do to a finished pull request in one workspace.

What it means for your business: If you run or outsource software development, tools like this are trying to compress the coordination overhead, which is where a lot of engineering cost quietly hides.

My take: The insight that tool sprawl, not model smarts, is the current ceiling rings true. The demo is always clean; the test is a real repository with weird history and half-documented decisions. Interesting to watch, worth a pilot before you rewire a team around it.

Source: Indiana Headlines

OpenAI starts putting the usage limits back

If your team leans on ChatGPT or Codex, note a small but practical reversal. Earlier this month OpenAI temporarily removed the rolling five-hour usage limit on Codex and ChatGPT Work for Plus, Pro, and Business plans, reset everyone's quotas, and made GPT-5.6 Sol more efficient so a given task burned less of your allowance. As of July 29, OpenAI has begun winding that back and plans to restore the five-hour limit on July 30. The separate weekly limit applied throughout.

In short: OpenAI is reinstating the temporarily removed five-hour usage limit on Codex and ChatGPT Work, with the cap returning on July 30.

What it means for your business: If your team got used to uncapped bursts of Codex or ChatGPT Work over the past couple of weeks, plan for the five-hour window to return so nobody is surprised mid-project.

My take: This is a good reminder that "temporary" perks from AI vendors are exactly that, and building a workflow that assumes unlimited access is a bet you do not control. Efficiency gains in Sol are the real durable win here; the limit removal was always going to snap back.

Source: BleepingComputer

That is your AI and IT news recap for July 29, 2026. Patch the VeloCloud and TeamCity bugs first, keep an eye on where AI governance is heading, and we will see you in the next one.