Week 30

Enterprise AI Weekly: July 20–25, 2026

By Attila · Jul 25, 2026 · 15 min read

This was the week the “agentic enterprise” stopped being a slide and started being an operations problem. The vendors moved on all three fronts at once: Microsoft looked for a cheaper engine to run its agents on, OpenAI shipped a managed way to deploy them, and Okta shipped a way to govern their identities. And the security news was the reminder that both halves of that stack — the AI tooling you build with and the network gear you build on — are already being attacked. Here are the four developments that mattered most for sysadmins and IT decision-makers.

1. Microsoft Tests a Chinese Open-Weight Model, Kimi K3, to Run Copilot

What happened: Two weeks after Microsoft began routing some Office AI prompts to its own in-house models to reduce what it pays OpenAI and Anthropic, the cost logic took another turn. Multiple outlets reported on July 20 that Microsoft is now testing Kimi K3 — a Chinese open-weight model from Moonshot AI, released July 16 — to see whether it can power Copilot features that today run on OpenAI and Anthropic systems, and is working to bring the model to Azure. Kimi K3 is a 2.8-trillion-parameter multimodal model with a one-million-token context window, and Moonshot plans to publish its full open weights on July 27, which would let enterprises download, customize, self-host, and audit it on their own infrastructure. The reported prize is cost: industry estimates put the inference savings at roughly 60% per token versus premium proprietary models, or up to around $600 million for Microsoft.

Several caveats are worth keeping straight. This is still internal evaluation, not deployment — Kimi K3 has not appeared on the Foundry pricing page, and Microsoft engineers have to clear it on quality, reliability, safety, and latency before it goes anywhere near Copilot. But there is a clear precedent: GitHub Copilot has offered Moonshot’s earlier Kimi K2.7 Code model since July 1, hosted on Azure and gated behind enterprise admin controls that default to off, and older Moonshot versions are already listed in Foundry. The move also runs into a live geopolitical question — the Trump administration is reportedly weighing an executive order or other measures to restrict Chinese open-weight AI models in the US, so Microsoft is stress-testing a Chinese model at the same moment Washington is debating whether to cut off that path entirely.

Why it matters to sysadmins and IT decision-makers: The near-term takeaway is the same discipline last edition called for, now with sharper stakes: the model behind a Copilot feature is a moving part Microsoft controls, and “which model answered that prompt” can change for pure cost reasons. What is new here is the origin. A Chinese open-weight model entering the Copilot and Azure supply chain is a data-governance and vendor-risk question your security and compliance teams will want to weigh in on before it becomes a default, not after — where inference runs, what your contractual data-handling guarantees are, and whether a model whose availability could be curtailed by a US executive order belongs in a workload you cannot easily move. The GitHub Copilot precedent is the reassuring detail: it arrived Azure-hosted and admin-gated to off, which is exactly the posture to insist on — opt-in, not opt-out, with a named owner deciding.

The open-weights angle cuts both ways, and it is worth understanding rather than reflexively fearing. Weights you can self-host are weights you can run inside your own VPC, keep prompts and data off a third party’s servers, and audit — a genuine advantage for regulated or air-gapped environments that the big proprietary APIs can’t offer. The flip side is that “you can run it anywhere” also means the model can show up in shadow deployments with no governance at all. The practical position is neither “block all Chinese models” nor “chase the cheapest token”; it is to treat model provenance as a first-class procurement attribute — know which model runs each workload, keep the ability to swap providers without a rewrite, and make the sourcing decision deliberately with your risk team in the room.

2. OpenAI Launches Presence to Deploy and Manage Enterprise Agents

What happened: On July 22, OpenAI introduced Presence, a managed platform for putting AI agents into production across voice and chat — customer support, sales, and internal operations. The pitch is that raw model access was never the hard part; running an agent reliably in production is. Presence bundles the pieces teams need to do that: connections into company systems, policies and standard operating procedures, guardrails, a defined set of approved actions, pre-launch simulations against common requests and edge cases, evaluation tooling, escalation rules, and a Codex-powered loop that keeps improving the agent after it ships. Guardrails can intervene when a conversation moves outside the company’s defined boundaries, and the system is evaluated on whether it follows policy, uses tools correctly, and hands off to a human when it should.

Two details define who this is for. First, it is not self-service: Presence is rolling out as a limited general availability program to eligible enterprise customers, with deployments led by OpenAI’s own Forward Deployed Engineers and select global systems integrators — a boots-on-the-ground, consulting-style delivery model rather than a sign-up page. Second, OpenAI is using its own operation as the proof point: Presence runs OpenAI’s English-language phone support line, where the company says it now resolves 75% of inbound issues without human assistance and cut human handoffs by 15 percentage points in ten days through the improvement loop. OpenAI says enterprises including BBVA, SoftBank, and IAG are exploring the product.

Why it matters to sysadmins and IT decision-makers: The most important word in this launch is “managed.” Presence is OpenAI acknowledging that the gap between a capable model and a production agent is filled with unglamorous operational work — policy definition, tool permissions, evaluation, escalation design, monitoring — and offering to own that work with embedded engineers. If your organization is being pitched a customer-facing or internal voice/chat agent, this is a real option to shorten the path to production, but it comes with the same strings any deep-integration engagement does: the agent needs access to your systems and data, which makes identity scoping, least-privilege tool permissions, logging, and a human-escalation path non-negotiable design requirements, not afterthoughts. The delivery model — forward-deployed engineers plus systems integrators — also means you are buying a services relationship, so scope the data access, retention, and exit terms the way you would for any consultant with hands on production.

There is a strategic read, too. Like the large services push a major vendor announced earlier this month, Presence is a bet that deployment, not model capability, is where enterprise AI actually stalls — and that the company that solves deployment captures the account. The 75%-resolution figure is a strong internal result, but it is OpenAI’s own support line under ideal conditions; treat it as an existence proof, not a forecast for your environment, and insist on running the pre-launch simulations against your real edge cases and measuring resolution and escalation on your own traffic before you let an agent talk to customers. The capability is genuinely useful; the discipline is refusing to skip the evaluation because a vendor’s engineers are doing the wiring.

3. Okta Ships Runtime Identity Governance for AI Agents

What happened: The same day OpenAI made agents easier to deploy, Okta made them easier to govern. On July 22, Okta announced a set of new capabilities within Okta for AI Agents — the identity platform it took generally available at the end of April — aimed squarely at the problem that agents act autonomously with standing credentials that human-oriented identity tools were never designed to handle. The centerpiece is Agent Gateway, an identity-native gateway that sits between agents and the systems they access without requiring code changes. Rather than just routing traffic like a conventional API or MCP gateway, it validates the agent’s identity, evaluates policy, and issues temporary credentials at runtime — which means downstream secrets are isolated from the agent, a rogue agent can be revoked without rotating everyone’s credentials, and every action lands in an audit trail attributed to both the agent and the human on whose behalf it acted. Okta says it works with agents including Claude Code, GitHub Copilot, Salesforce Agentforce, and Amazon Bedrock AgentCore.

Two more pieces round it out. Agent-to-Agent Connections, now generally available, secures the handoffs in multi-agent workflows by verifying authorization and baking the full chain of custody into the token, so a request that passes through several agents stays traceable. Resource Access Certifications for AI Agents, in early access, brings agents into the same automated access-review workflows organizations already run for people — unified visibility across human and machine identities, automated remediation of excessive permissions, and audit-ready logs — to fight the standing, over-broad access that agents accumulate over time. The framing throughout is the one Okta has pushed all year: every agent needs an identity, and it should be a governed one.

Why it matters to sysadmins and IT decision-makers: This is the control plane the last two stories quietly assume. An agent you deploy through a platform like Presence, or a coding agent running Kimi or Claude, is a non-human actor with credentials and system access — and Gartner’s projection that the average global Fortune 500 company will run more than 150,000 agents by 2028 tells you the scale you are heading toward. Identity is the discipline that keeps that from becoming an ungoverned mess: if every agent authenticates as a named identity with least-privilege, time-bound access and a human owner, then “what can this thing touch, and who is accountable for it” has an answer you can audit. The Agent Gateway model — brokering short-lived credentials at runtime instead of handing agents standing API keys, and being able to kill one agent’s access without a fleet-wide rotation — is the pattern to look for whether you adopt Okta’s version or build the equivalent with the identity stack you already run.

The practical near-term move is inventory before architecture. Most organizations already have agents in their environment that no one registered — a Copilot extension here, a scripted integration there — holding credentials nobody is reviewing. Before you evaluate any agent-identity product, find the agents you already have, give each one an owner, and get them into your normal access-certification cycle so their permissions are reviewed like any employee’s. That work is vendor-neutral and pays off regardless of which platform you standardize on; the tooling announced this week is useful, but the governance gap it addresses is one you can start closing today with discovery and least-privilege, not a purchase order.

4. CISA Flags a Check Point Firewall Zero-Day and a Critical RCE in an AI-Agent Platform

What happened: The security news split cleanly into the two halves of the stack this newsletter keeps circling: the network gear underneath your AI, and the AI tooling on top of it. On the infrastructure side, CISA added CVE-2026-16232 to its Known Exploited Vulnerabilities catalog — a critical (CVSS 9.3) authentication-bypass flaw in Check Point Security Management and Multi-Domain Management. It lets an unauthenticated remote attacker obtain an application login token and use it to sign into SmartConsole with full administrative privileges, then change security policy and configuration at will. Check Point confirmed active exploitation against a handful of customers, released a Jumbo Hotfix on July 22 for supported versions including R81.20, R82, and R82.10, and stressed that exploitation requires the management interface to be internet-reachable with no Trusted Clients restriction. CISA gave federal agencies until July 25 to remediate.

On the AI-tooling side, CISA added CVE-2026-0770, a critical remote-code-execution flaw in Langflow — a widely used visual framework for building AI agents and workflows. The bug lives in how the /api/v1/validate/code endpoint handles an exec_globals parameter, and it lets an unauthenticated attacker run code as root in a low-complexity attack. This one is not theoretical: researchers logged in-the-wild exploitation starting June 27, with more than 220 attempts from 64 unique IP addresses, and the payloads went straight for the crown jewels — downloading second-stage malware and scraping environment variables, cloud metadata, and AWS credential files. Federal agencies were ordered to patch by the end of the week under Binding Operational Directive 26-04.

Why it matters to sysadmins and IT decision-makers: The Check Point flaw is the urgent one because of what the compromised device is. This is not a random web server — it is the management plane of your firewall, the thing whose entire job is to enforce your security policy, and the vulnerability hands an unauthenticated attacker administrative control over it. If you run Check Point management exposed to the internet, apply the Jumbo Hotfix immediately and treat any exposure window as a policy-integrity incident: review the security policy and configuration for unauthorized changes, not just the patch level. And take the mitigation as a standing rule beyond this CVE — SmartConsole and management interfaces should never be reachable from the open internet, and restricting Trusted Clients to known administrative IP addresses would have blocked this attack outright. Management planes belong behind the network, full stop.

The Langflow entry is the one to sit with, because it is the pattern from recent editions made literal: the AI tooling itself is now an actively exploited attack surface, and the payloads are already stealing cloud credentials rather than merely proving a point. Agent-building frameworks like Langflow tend to get stood up quickly by developers and data teams, often on internal networks or a convenient cloud VM, without the hardening a production internet-facing service would get — and this flaw needs no authentication and yields root. Find every Langflow instance in your environment, patch or take it offline, make sure none are exposed to the internet, and — because attackers were harvesting AWS keys and environment variables — rotate any credentials those instances could reach and review logs for suspicious calls to the validate endpoint. More broadly, the AI experimentation happening across your organization is running on real infrastructure with real secrets; it needs to be in your asset inventory and your patch cycle, not treated as harmless prototyping.

The Week in Summary

The through-line this week is that the agentic enterprise is assembling into a real stack, and every layer is now something IT has to own. Microsoft went shopping for a cheaper engine to run its agents on — a Chinese open-weight model that could cut inference costs by hundreds of millions, and drag a fresh data-governance and geopolitical question into your model supply chain. OpenAI shipped the deployment layer, a managed platform with embedded engineers to get agents into production. Okta shipped the governance layer, giving those agents identities, runtime-scoped credentials, and access reviews. Read together, they describe an operating model taking shape faster than most organizations’ policies for it: sourcing, deploying, and governing autonomous software that acts on your behalf.

The security stories are the reminder that this stack is being attacked from both ends. A firewall-management zero-day hands attackers control of the device that enforces your policy; a critical, actively exploited flaw in a popular AI-agent framework hands them root and your cloud credentials. Neither is exotic — both come down to management interfaces and experimental tools that ended up reachable when they shouldn’t have been. The AI layer does not get a pass on the fundamentals; it inherits all of them, plus a few new ones.

Three things worth doing before next week: decide, with your risk team, how a model’s provenance and hosting factor into which workloads it is allowed to run before a cheaper option becomes a silent default; start an inventory of the AI agents and agent-building tools already in your environment, give each an owner, and pull them into least-privilege access reviews; and patch any internet-exposed Check Point management or Langflow instances now, rotating the credentials and reviewing the configurations they touched.

Next edition publishes August 1.

More Enterprise AI Weekly coverage:

Enterprise AI Weekly: July 6–11, 2026 — Week 28
Enterprise AI Weekly: July 13–18, 2026 — Week 29