NVIDIA nvmath-python is a library designed to bridge the gap between the Python scientific community and NVIDIA CUDA-X math libraries. It gives Python users...
NVIDIA nvmath-python is a library designed to bridge the gap between the Python scientific community and NVIDIA CUDA-X math libraries. It gives Python users access to CUDA-X performance for common math operations without disrupting existing workflows. Depending on the API, operations can run on a CPU, CUDA-enabled GPU, or distributed multi-GPU, multi-node systems.
OpenAI is sharply reducing the prices of two models in its GPT-5.6 frontier series, cutting GPT-5.6 Luna, the smallest and fastest model in the series, by 80% and GPT-5.6 Terra, the mid-tier model, by 20%, while adding a premium Fast mode for its flagship GPT-5.6 Sol model.
OpenAI is successfully undercutting Google's price per intelligence and attempting to sway Anthropic users, who may not mind paying more, with a speed boost.
OpenAI says Luna will now cost $0.20 per million input tokens and $1.20 per million output tokens, for a combined input-plus-output price of $1.40 per million tokens.
Terra will cost $2 per million input tokens and $12 per million output tokens, for a combined price of $14.
Pricing for Sol Standard remains unchanged at $5 per million input tokens and $30 per million output tokens. OpenAI is also adding Sol Fast mode at twice the Standard price: $10 per million input tokens and $60 per million output tokens.
The company says Fast mode delivers up to 2.5 times the throughput without changing the model’s underlying intelligence.
Pricing is shown per one million tokens. Total cost is calculated as input price plus output price. Cached-input pricing is excluded to keep the comparison consistent across providers.
OpenAI moves Luna into the low-cost tier
The most consequential change is the Luna price cut.
When OpenAI introduced the GPT-5.6 series, Luna was priced at $1 per million input tokens and $6 per million output tokens, for a combined total of $7. The new pricing reduces that combined figure to $1.40.
That places Luna below Google’s Gemini 3.5 Flash-Lite, which costs a combined $2.80 per million input and output tokens, and far below Gemini 3.6 Flash at $9. Luna also now costs less than OpenAI’s own GPT-5.4 and Terra models by a wide margin.
It is not the cheapest model in the broader market. Xiaomi’s MiMo-V2.5 Flash, DeepSeek’s flash model and several other APIs remain less expensive on a pure token basis. But the reduction brings an OpenAI frontier-series model into direct competition with the market’s low-cost inference tier.
OpenAI says the GPT-5.6 series represents its frontier model family, with Sol positioned at the top of the lineup, Terra as the middle tier and Luna as the smallest and fastest option.
The lineup was initially released in late June 2026 through a limited rollout by U.S. government request, before broader access, with each model intended to offer a different tradeoff among intelligence, latency and cost.
Sol is aimed at the most complex reasoning-heavy and agentic workloads, including advanced coding, multi-step planning and tool-using systems, while Terra is designed for general production use where a balance of capability and efficiency is required. Luna is positioned for high-throughput, low-latency tasks such as summarization, classification, routing, and lightweight real-time assistants where cost per request is the primary constraint.
Terra drops to match Google’s Gemini 3.1 Pro pricing
Terra’s 20% reduction moves its combined price from $17.50 to $14 per million tokens.
At that level, Terra now matches Google’s Gemini 3.1 Pro Preview pricing for context windows of 200,000 tokens or less.
It also undercuts OpenAI’s GPT-5.4, which remains priced at $2.50 per million input tokens and $15 per million output tokens, offering the same intelligence for about 1/13th the cost, as Krea AI's Nic Dunz noted on X:
The adjustment creates a wider separation between OpenAI’s three GPT-5.6 tiers. Luna costs one-tenth as much as Terra on a simple combined input-plus-output basis, while Terra costs 60% less than Sol Standard.
Sol Fast moves in the opposite direction. At a combined $70 per million tokens, it is the most expensive model configuration in the comparison below, reflecting OpenAI’s decision to charge a premium for latency-sensitive workloads rather than lower Sol’s base price.
Cuts follow Google’s low-cost Gemini releases and Anthropic's Claude Opus 5
Google priced Gemini 3.6 Flash at $1.50 per million input tokens and $7.50 per million output tokens. Gemini 3.5 Flash-Lite costs $0.30 per million input tokens and $2.50 per million output tokens.
Google framed both models around the economics of agent deployment, arguing that lower token usage, fewer reasoning steps and reduced tool calls could lower the total cost of long-running software engineering and knowledge-work tasks.
Gemini 3.6 Flash reportedly uses 17% fewer output tokens than Gemini 3.5 Flash on the Artificial Analysis Index, with savings reaching as high as 65% on some long-horizon engineering workloads. Gemini 3.5 Flash-Lite is positioned as the fastest model in Google’s 3.5 series.
However, OpenAI's models are more performant than Google's, according to third party analysis outfits like Artificial Analysis, with even the Luna model outperforming Gemini 3.6 Flash and the older Gemini 3.1 Pro model, making the cost-per intelligence much more favorable to OpenAI.
As AI coding startup Cognition noted on X, GPT-5.6 now "sits on the pareto curve of price/performance efficiency," posting an animation of the GPT-5.6 series moving left on a chart representing intelligence on the y axis and cost on the x, showing that the models now offer among the most superior intelligence for lowest cost on the market.
And yet, rival Anthropic's Claude Opus 5 remains about as performant as GPT-5.6 Sol, yet is 6% cheaper.
The model costs $5 per million input tokens and $25 per million output tokens—the same rates as Opus 4.8—but Anthropic says it delivers nearly all the intelligence of its more expensive Fable 5 model at roughly half the cost.
Unlike OpenAI’s Luna and Terra changes, Anthropic did not reduce the Opus API sticker price. Instead, it effectively lowered the price per unit of capability by replacing Opus 4.8 with a more capable model at the same $30 combined input-and-output rate. Anthropic also added an adjustable effort setting that allows developers to trade reasoning depth for speed and token savings.
That distinction matters for enterprise buyers. OpenAI is directly cutting per-token rates, Google is pairing lower prices with reductions in token use and tool calls, and Anthropic is emphasizing stronger task performance at an unchanged price. All three approaches target the same operational metric: the total cost of completing production work, rather than the advertised cost of an individual token alone.
The timing highlights how quickly pricing has become a competitive lever among frontier model providers. OpenAI’s response does not introduce a new model generation. Instead, it changes the economics of deploying models that were released only recently.
The market shifts from model access to model economics
The cuts indicate that access to frontier-level capability is no longer the only point of competition. The next question for enterprises is how cheaply and predictably those models can run in production.
OpenAI is still not the lowest-priced provider on a pure token basis. But Luna’s 80% reduction materially changes its position, moving it from the middle of the market into a pricing tier populated by smaller models from Google, Xiaomi, DeepSeek, MiniMax and other vendors.
That matters most for high-volume applications, where relatively small differences in token pricing can compound across coding agents, document systems, internal search tools and automated workflows.
OpenAI’s latest move therefore looks less like a routine adjustment and more like a repositioning of the GPT-5.6 series. Sol remains the premium option, Terra moves closer to competing pro-tier systems, and Luna becomes the company’s direct answer to the industry’s growing low-cost model segment.
Knowledge workers are increasingly integrating AI agents into their workflows. Agents that function as "digital coworkers" offer clear benefits. For example,...
Knowledge workers are increasingly integrating AI agents into their workflows. Agents that function as “digital coworkers” offer clear benefits. For example, they can review a bug report, implement and test a fix, push a patch, and ping a human for review. By handling routine tasks, agents have the potential to deliver large productivity gains. On the other hand, connecting a large language model…
OpenAI has lowered API prices for two GPT-5.6 models only three weeks after their launch. On Thursday, the company announced that GPT-5.6 Luna is now 80% cheaper and GPT-5.6 Terra is 20% cheaper, while the price for its main reasoning model, GPT-5.6 Sol, stays the same.
“Major price cuts today,” OpenAI CEO Sam Altman writes in a post on X published on Thursday. “We want to offer the best price/intelligence tradeoff at every level.”
“We want to offer the best price/intelligence tradeoff at every level.”
Luna now costs $0.20 for a million input tokens and $1.20 for a million output tokens, down from $1 and $6. Terra is priced at $2 per million input tokens and $12 per million output tokens, reduced from $2.50 and $15. Sol’s price stays at $5 per million input tokens and $30 per million output tokens.
Developers using Luna do not need to change their processes, but their inference costs will go down. High-volume tasks will now be much cheaper to run, without requiring any code updates or model changes.
major price cuts today:
*80% drop for GPT-5.6 Luna, now $0.20 per million input tokens and $1.20 per million output *20% drop for GPT-5.6 Terra, to $2/$12 *GPT-5.6 Sol gets Fast mode in the API, up to 2.5x the speed for 2x the price, same intelligence pic.twitter.com/erC6u4VoDR
This timing is unusual because AI vendors usually keep prices steady for several months after launching a new model family. OpenAI cut prices less than a month after GPT-5.6 became available on July 9.
…serving costs can be more important than small differences in benchmark performance between models.
Infrastructure gains drive savings
The company says these price cuts were possible because of improvements to the infrastructure behind GPT-5.6, which lets the company offer “substantially more intelligence per dollar.”
OpenAI engineers rewrote the production GPU kernels, cutting serving costs by about 20%. They also redesigned Sol’s speculative decoding system, making token generation over 15% more efficient. The company updated its agent runtime as well, reducing repeated prompt computation by using prompt caching more during multi-step workflows.
The elephant in the room is that the competition has intensified from overseas. Lower-cost open-weight models from Chinese AI companies like Moonshot are pushing commercial providers to show not just better performance, but also better pricing for production use. OpenAI and Anthropic know that leaning on performance just isn’t an option anymore, which is pushing them to match Chinese prices.
The issue here is that most of those steps don’t need a model like Sol, and Chinese labs have figured out how to pack better capabilities into efficient models; a helpful option for companies running through billions of tokens a day.
The ability to send the easy tasks to open models and save the pricey APIs for the tough stuff makes a difference; OpenAI is banking on its 80% price cut on Luna to narrow that gap. Suddenly, switching to self-hosted models doesn’t look worth the hassle.
This announcement highlights a trend in the industry for infrastructure. Now, every percentage point of serving efficiency can lead directly to lower API prices, turning cost optimization into a competitive advantage instead of just an engineering goal.
One of a series of striking AI-assisted math discoveries, this one feels a little different.
As millions of people were coming down from the excitement of the FIFA World Cup Final at the start of last week, a different kind of excitement was building within the mathematical community.
Levent Alpöge, a mathematician working at the artificial intelligence company Anthropic, made a very casual announcement on X that he had found a counterexample to the Jacobian conjecture, a very old and well-known problem in a field of mathematics called algebraic geometry. He had done this using Anthropic’s large language model Claude Fable 5, released to the general public only a few weeks ago.
This is just the latest of many striking mathematical breakthroughs made by mathematicians working with large language models. But this one feels a little different to those that have come before.
What Is the Jacobian Conjecture?
First, what is a conjecture? It’s an idea that some mathematicians believe is true but nobody has been able to prove or disprove.
Now to the Jacobian conjecture. It’s fairly abstract but not too difficult to describe.
The conjecture involves functions, which are like little machines which you put one or more numbers into and out pop other numbers according to some rule or equation. In this case, the functions use what are called polynomials.
Specifically, it’s about situations where the numbers represent points in a space, like coordinates on a map. So we can imagine that when the function takes in some numbers and puts out some other numbers, it is moving the points in space.
You can test how “nicely” a function moves everything around in space by calculating something called the Jacobian determinant. If the Jacobian determinant is always a constant number that is not zero, then the function never folds or crushes space around a particular point.
The Jacobian conjecture states that when the Jacobian determinant is a non-zero constant, there should always exist another function, also made up of polynomials, that reverses the original one. This will return all the points to their starting positions.
Not every function is reversible. For example, if our starting function moves two of the original points onto a single point, then we cannot reverse it. Once the points have been merged, we cannot distinguish between them to send them back to the right positions.
A Long History of Attempts—and Failures
The two-dimensional version of the Jacobian conjecture was stated by Czech mathematician Ludwig Kraus in 1884. It was generalized to any number of dimensions by German mathematician Ott-Heinrich Keller in 1939.
During its long history, the Jacobian conjecture has been the subject of many claimed proofs, including by Beniamino Segre and Wolfgang Gröbner, two famed 20th-century mathematicians. However, in each case, subtle errors were found that invalidated the arguments.
Despite this, there have also been a number of valid efforts showing the conjecture is true with various restrictions. Computational results have also shown it is true in two dimensions for polynomials up to degree 100 (that is, including powers of the variables up to 100).
But nobody had proved the general case—or found an example showing the conjecture was wrong.
A Deceptively Simple Answer
One of the key reasons the Jacobian conjecture is so intriguing is that, in theory, it should be easy to find a counterexample. It is straightforward to come up with examples of functions that merge points, and also examples of polynomial mappings that have a constant Jacobian determinant.
However, finding a polynomial mapping with both properties is the challenge. Indeed, as one Math Stack Exchange user noted in a post from 2017, “for all what we know, some smart undergraduate can simply write a formula […] that will be a counter-example to this conjecture.”
Indeed, this did turn out to be the case for Alpöge’s function, which is short enough to fit into a single X post. He found an example of a function in three dimensions which has a constant Jacobian determinant of -2, and which moves multiple input points to the same output point, so it is not reversible.
It shows the conjecture is false for every dimension larger than 2, with the original conjecture in two dimensions remaining open. The brevity of the counterexample made it easy for other mathematicians to verify.
Both examples illustrate one of the most striking strengths of AI models. They can draw on ideas from different areas of mathematics, combining them in a novel way to prove astonishing results.
At the time of writing, details have not been made public regarding exactly how Alpöge prompted the AI model to produce the Jacobian conjecture counterexample and what its output looked like. However, so far this result appears to be of a different nature.
Unlike many other recent AI-assisted breakthroughs, the counterexample itself is remarkably simple. The difficulty in finding it seems to have lain not in an intricate construction or a lengthy proof, but rather in finding a good way of navigating an enormous search space of possible polynomial mappings to find one with the right properties.
This suggests AI may prove to be just as valuable for discovering unexpected mathematical objects as it is for constructing proofs. What this means for the future of mathematics—and human mathematicians—remains to be seen.
This week on Uncanny Valley, we discuss the open- vs. closed-source debate in AI, key players in White House AI policy, and how to stop your chatbot logs from showing up in search-engine results.
Training a machine learning model to handle multiple objectives simultaneously is a bit like trying to follow GPS directions to several destinations at once: the routes often conflict, and compromising between them can leave you farther from every destination. A paper we presented at this year’s International Conference on Machine Learning (ICML) addresses this problem in the context of graph self-supervised learning (graph SSL), where the goal is to train a neural network to process graph data. Graph SSL objectives include inferring links between graph nodes, reconstructing nodes that have been masked out, and maximizing the mutual information between a given node and the nodes in its neighborhood. Our framework, ControlG, borrows an idea from industrial control systems: rather than blending all objectives together at every training step, it dedicates computational capacity to one objective at a time and lets a proportional-integral-derivative (PID) controller decide which objective needs attention next. Karish Grover, an Amazon PhD fellow, performed this work during an internship at Amazon Web Services, and Amazon Scholar Christos Faloutsos and I served as his mentors. The problem: Multitask tug-of-war The goal of graph self-supervised learning is to learn useful representations of graph data that can be used in downstream tasks like node classification. Research in the area has produced a rich tool kit of training objectives, each encoding different structural intuitions about the data. Link prediction captures local connectivity. Feature reconstruction captures node attributes. Contrastive methods capture invariant features. No single objective dominates across all datasets and downstream tasks, so a natural strategy is to combine several objectives. For each batch of training examples, the machine learning algorithm calculates a gradient: a vector that indicates the direction and distance we should move in the parameter space. Based on the gradient, the algorithm updates the model’s parameters. The standard way to handle multiple objectives is per-step mixing: at every training step, blend gradients from all objectives into a single update. This makes every parameter update a compromise. When objectives disagree about the direction in which to modify parameters, three types of failure occur: Disagreement: Conflicting gradients cause negative transfer, where optimizing one objective actively degrades another. Drift: An objective that helps early in training may become redundant later, but fixed or slowly adapting weights cannot track this shift. Drought: Adaptive weighting schemes can starve objectives by driving their weights toward zero, making it impossible to tell whether an objective ever meaningfully shaped the learned representation. Coordination is a scheduling problem Our key insight is that multitask coordination is fundamentally a temporal allocation problem. Rather than asking, "How should I blend these objectives right now?", we should ask, "Which objective should receive the next allocation of my computational budget?" This reframing has a surprising consequence: even random scheduling, where you pick an objective uniformly at random for each block of training steps, often matches or beats sophisticated gradient-manipulation methods. On node clustering, random scheduling (average rank 5.0) outperforms AutoSSL (7.3), WAS (10.0), ParetoGNN (8.1), PCGrad (7.8), and CAGrad (8.4). The temporal separation alone eliminates instantaneous gradient conflict. But random scheduling leaves performance on the table. Some objectives need more computational capacity than others at different points in training. ControlG uses the PID controller to allocate adaptively. PID controllers are feedback loop controllers often used in industrial settings to manage processes that require continuous adjustment and automated control. You can find such systems in both industrial machinery and consumer devices, from your car’s cruise control system to a high-end espresso machine regulating water temperature. ControlG: Sense, plan, control ControlG decomposes multitask coordination into three loops, each operating at a different time scale. The loops draw on the theory of Pareto efficiency: in multiobjective optimization, the Pareto front is a boundary in parameter space along which it is impossible to improve the outcome on one objective without diminishing it on another. 1. Sense (slow time scale): Estimate per-objective difficulty using two signals computed on the full training graph: Spectral demand: When a graph neural network (GNN) aggregates information from neighboring nodes, it naturally smooths signals across the graph, much the way averaging nearby pixels blurs an image. Some objectives produce learning signals that vary smoothly (neighboring nodes want similar updates), while others produce sharply varying signals (neighboring nodes want contradictory updates). We measure this by computing how much each objective's desired update direction disagrees between connected nodes (formally, the Rayleigh quotient of the per-node gradients with respect to the graph structure). The sharper the disagreement, the harder it is for the GNN's smoothing architecture to make progress. We prove this formally: this disagreement score (Rayleigh quotient) upper-bounds how much progress a single training step can achieve. Interference: How much does optimizing this objective conflict with the optimization of other objectives? We use the multiple-gradient descent algorithm, which calculates a gradient that reduces error on at least one objective without increasing it on any others, as a measurement oracle: its weights identify which objectives are currently constraining the Pareto trade-off. 2. Plan (epoch timescale): Convert difficulty estimates into a target allocation of computational capacity across objectives. For this, we use the log-hypervolume metric, which measures the distance between the current parameter values (the reference point) and the Pareto front. In particular, we consider log-hypervolume sensitivities, which measure how strongly improvement on one objective would increase the log-hypervolume. In the context of graph SSL, this naturally prioritizes objectives that are lagging (close to the reference point) while tempering allocation by estimated difficulty. The planner produces a target fraction of compute blocks per objective for each epoch. 3. Control (block time scale): Track the allocation plan with a proportional-integral-derivative (PID) controller. The proportional term prioritizes objectives behind schedule. The integral term eliminates steady-state tracking bias. The derivative term damps oscillations. Results We evaluate ControlG on nine graph benchmarks spanning homophilic graphs (graphs where connected nodes are likely to share features, such as Cora, CiteSeer, PubMed, Coauthor-CS, Wiki-CS), heterophilic networks (graphs where connected nodes tend to have dissimilar features, such as Chameleon, Squirrel, Actor), and large-scale graphs (ogbn-arxiv, 169K nodes). Across three downstream tasks (node classification, link prediction, and node clustering), ControlG achieves average ranks of 1.4, 1.9, and 1.8 respectively, consistently outperforming all baselines. Key findings Homophilic graphs: ControlG delivers strong gains over the next-best multitask method (Cora +1.5% over CAGrad, PubMed +1.1% over PCGrad, Coauthor-CS +1.8% over CAGrad on node classification). Heterophilic graphs: Where gradient conflicts are most pronounced, ControlG outperforms all multitask baselines and remains competitive with the best single-objective method (masked-feature reconstruction), which benefits from avoiding conflict entirely but lacks breadth. Scale: On ogbn-arxiv (169K nodes), ControlG achieves 72.86% node classification accuracy, a 1.2 percentage point improvement over the next-best multitask method (CAGrad at 71.62%). Efficiency: ControlG adds modest overhead (16-31 milliseconds per step depending on dataset) compared to simple scheduling (8-15 milliseconds) but remains substantially faster than heavyweight methods like AutoSSL (125-414 milliseconds) and ParetoGNN (35-764 milliseconds). Interpretable and auditable training Beyond performance, ControlG provides visibility into the training process. The scheduling timeline shows exactly when each objective received allocations of computational capacity. The deficit traces, which indicate the difference between the planned allocation and the actual allocation, confirm that the PID controller tracks allocation, and the state trajectories show how difficulty estimates adapt to training dynamics. This auditability matters in practice: when a downstream task unexpectedly degrades, the training log reveals which objectives drove the learned representation and when. Every component matters Removing components in isolation confirms what each piece of ControlG contributes: Removing the planner (uniform allocation) causes the largest drop (up to 3.4% on some datasets), confirming that adaptive allocation is essential. Removing both state signals (spectral demand and interference) yields similar degradation, showing that the planner's effectiveness depends on accurate difficulty estimates. Removing spectral demand diminishes performance across all graph types, while removing interference matters most for heterophilic graphs, where cross-task conflicts are stronger. Replacing the PID controller with independent and identically distributed sampling from the plan degrades performance by 1-2%, demonstrating that deficit tracking improves allocation fidelity. Broader implications While we demonstrate ControlG on graph self-supervised learning, the framework addresses a general problem: how to coordinate multiple training objectives without forcing per-step compromise. The control-theoretic decomposition (sense difficulty, plan allocation, track with feedback) is applicable whenever multiple objectives share parameters and can conflict; the relative importance of objectives changes over training; or interpretability of the training process matters. We are exploring applications to LLM continual learning and multitask fine tuning, where similar tug-of-war dynamics arise when models are trained on diverse instruction-following, reasoning, and safety objectives simultaneously. Acknowledgments This work was led by Karish Grover (Amazon AI PhD fellowship '25-'27, Carnegie Mellon University) during his internship at Amazon, with Han Xie (applied scientist, AWS AI), Sixing Lu (applied scientist, AWS AI), Xiang Song (applied scientist, AWS AI), Christos Faloutsos (Amazon Scholar, Carnegie Mellon University), and me. The code is available as open source.
The two Chrome updates in June patched more bugs than the 23 updates before them. Now, Google is ramping up its patching schedule thanks to AI-assisted vulnerability discovery.
Every time a Mastercard gets tapped, the network has less than a tenth of a second to judge how likely the purchase is to be fraudulent. It made that call across 175 billion transactions last year. Now the buyer on the other side of that judgment is starting to change, and Greg Ulrich, the company's chief AI and data officer, spelled out the consequence for the VB Transform 2026 audience in Menlo Park on July 14. "We've built a bunch of risk rules over time that were intended to stop a bot from transacting," Ulrich said. "Now we need to enable the bot to transact, so that requires a change to our risk framework and our risk rules."
Ulrich joined Mastercard eleven years ago when an analytics company he worked at was acquired, and said trust struck him from day one on the job. "It's what enables a merchant that's never met you to accept payment and ensure that they're going to get paid. It's what enables you as a consumer to transact and ensure that things are going to work out in a trusted, secure way. And if something goes wrong, there's a safe and secure path for a dispute and to resolve this," he said.
175 billion transactions, scored in under 100 milliseconds
He took the audience inside each of those calls. "When you tap your Mastercard to pay for a product or service, we're providing a score to that transaction," he said. "We have under 100 milliseconds to look at that and give a score from zero to 999 about how likely is that to be fraudulent or real. And we pass that on to the issuing bank."
Generative AI widened what that score can see. "Because we have new technology, we can bring in more data, we can bring in more context, and now we're finding that we can identify 300, 400% more fraudulent transactions at those high-risk bands," Ulrich said, without adding friction or false positives for consumers. The company's Safety Net system has stopped more than 70 billion fraudulent transactions, he told the audience, and Mastercard is building its own transformer model on its transaction data as a foundation for new safety, security, and personalization solutions. VentureBeat's Beyond the Pilot podcast took that production fraud stack apart in detail earlier this year.
A third of the services business already runs on AI
The business stakes reach past fraud. About 40% of Mastercard's company is now based on services, Ulrich said, including marketing services; fraud, safety and security; and business intelligence. "A third of those are predicated on AI, and those are growing at a much faster clip than everything else," he said.
One line he returned to all session went further. "What's going to enable AI to continue to scale is not the capabilities of the agents, it's how much we trust those agents to do on our behalf as a consumer, as a business, as a financial institution, or otherwise," he said.
Five layers stand between agents and the network
Agentic commerce changes the object being secured. "Instead of a single atomic transaction where I say go buy something, I'm effectively delegating authority, or a consumer's delegating authority, a business is delegating authority," Ulrich said. "And when that happens, it's a much more complicated transaction." Trust, in turn, has a precondition. "The only way it's going to work with trust is if we can identify what was the intent, what are the behaviors, what are the constraints that were intended in that transaction."
Ulrich walked through five layers Mastercard has built against that problem. Identity comes first. "I want to make sure I can understand not just who the consumer is, but who the agent is, that I combine them together and that I have KYA or know your agent, that I'm validating that it's legitimate technology, that it's a legitimate agent," he said. "We can register it into our system."
Verifiable intent settles the "wrong-Nikes" problem
Verifiable intent is second, a tamper-proof cryptographic record of the original instructions that travels with the transaction. "If you've asked for Nike black Nikes in size 12, but you got them on a final sale and they're not returnable and that wasn't in your instruction, there's a way to look at that in an objective and clear way on the back end," he explained.
Controls form the third layer, defining which merchants an agent can buy from, at what limit, and under what constraints. Execution runs through Mastercard Agent Pay, which carries "the tokenization, authentication, the acceptance framework embedded within it" and has launched with Microsoft, OpenAI, Google, and others, Ulrich said. Intelligence is the fifth layer, spanning risk rules, insight tokens that grant "consented or permissioned access to insights" for personalized recommendations, and monitoring through Recorded Future to identify threat actors in the system.
The bigger prize is a procurement agent with a budget
Consumer purchases are where agentic commerce started. Ulrich pointed the room past them, to business-to-business procurement as the larger opportunity. His example was a manufacturer that wants an always-on assembly line, with an agent that manages inventory levels, tracks when stock runs low, replenishes automatically, and understands the budget and the approved suppliers. "When you can start enabling that, you require those same five layers for that type of transaction," he said.
Making it work across companies multiplies the parties that have to trust each other. "You need clear standards for identity, you need clear standards for intent, you need these to work across. You're gonna have a procurement agent, a supplier agent, a banking agent. They're all gonna need to communicate to enable this to happen in an autonomous way, and that's gonna require really scaled trust infrastructure."
Powerful new models, same security motion
Mastercard sat in the early wave of Project Glasswing with Anthropic's Mythos model, and worked with OpenAI's GPT-5.5-Cyber, he said. "What we've seen from both of those is incredibly powerful models finding new vulnerabilities in the ecosystem that were difficult to detect previously, but it's really a new tool as opposed to a new motion," Ulrich said.
Inside the company, the chief security officer leads that work. A dedicated team has prioritized the most critical assets, runs them through the models routinely, tracks findings by high, medium, and low severity, and uses the same technology to handle patches. Ulrich said the approach has already been extended out, and that Mastercard is working to make the same architecture and patching available to others as well.
What Mastercard would build differently after 14 months
"The guardrails, the security, all this stuff has to be embedded at the front end. These can't be things that we're adding on at the back end. That's lesson one. Lesson two is you have to be operating for scale, and the other one is around observability and accountability matter as much as the intelligence," Ulrich said, counting off what building inside Mastercard taught the team. The company built what he described as an agentic factory, an operating system with the compliance, the observability, and the guardrails built in rather than bolted on per agent. Model drift, once tracked manually by dedicated teams, is now automated into that factory.
Asked by an audience member about the gotchas, Ulrich did not soften the pilot-to-production trap. "If you're trying to extend that and then add guardrails in as you're extending it, once you've already built it, I think you're doomed to fail," he said.
Mastercard built a series of agents last year for its 4,000 consultants, covering deep research, text to SQL, Excel, and PowerPoint, tools that by his account did not exist at the level Mastercard needed. Were the company starting today, Ulrich said, it would build them fundamentally differently. "I don't know that we anticipated when we built things fourteen months ago that we would be rethinking the fundamental architecture and the approach already."
Agentic identity joins KYB and KYC
The identity layer is where Ulrich expects the market to move next. Inside Agent Pay, Mastercard authenticates the consumer the way it does in traditional e-commerce and binds the agent to that person. "Outside of that framework, I think there will be open standards to identify who an agent is and bind the agent with the consumer," he said. "And then we can tie that with verifiable intent."
He called identity "one of the faster-growing ecosystems," noting Mastercard has been expanding there organically and inorganically for about six or seven years, with the work now spanning "agentic identity as well as the traditional KYB and KYC identity." The risk rules that keep bots off the network came out of more than two decades of applying AI to those transactions. The rewrite, for the agents Mastercard now wants to let in, is already underway on the same network that scored 175 billion of them last year.
Less than a year after emerging from stealth to tackle non-human identity security, Israeli cybersecurity startup Hush Security believes the enterprise AI security conversation has fundamentally changed.
The company, which earlier this week announced a $30 million Series A round led by returning investors Battery Ventures and YL Ventures with Akamai Technologies joining as a strategic investor, argues that organizations are rapidly moving beyond experimenting with generative AI assistants and into deploying autonomous software agents that require an entirely different security model.
While the funding will help expand engineering, U.S. sales and enterprise integrations, Hush is framing the announcement primarily as evidence that identity—not models—is becoming the critical control plane for enterprise AI.
"The discussion has moved incredibly fast," CEO and co-founder Micha Rave told VentureBeat in a video call interview following the funding news.
When Hush launched last year, the company's focus was securing non-human identities—API keys, service accounts, machine credentials and other identities used by software rather than people.
Since then, Rave says, customers have increasingly asked a different question: how do they safely allow AI agents to operate inside production systems? This is a pertinent and urgent question ever since Hugging Face revealed in mid-July it was hacked by an autonomous AI agent, later identified as an OpenAI test agent running internally that escaped its secure sandbox, powered in part by an unreleased model.
The company's original thesis was that enterprises had accumulated thousands of long-lived machine credentials that were difficult to rotate, audit and secure. Rather than relying on static secrets, Hush developed an identity-based system that brokers short-lived, policy-driven access for machines.
Rave says AI agents amplify that same problem.
"Software now acts autonomously, on its own initiative, inside your most sensitive systems," he said. "AI agents need strict identity, not just API keys."
Unlike traditional automation, AI agents frequently act across multiple enterprise systems, invoke external services, make decisions independently and often execute actions using the permissions of the human who launched them. In practice, organizations often grant an agent broad OAuth permissions or administrator credentials simply to enable it to complete tasks.
That creates what Hush describes as an identity problem rather than simply an AI problem.
During the interview, Rave said virtually every security leader he speaks with faces the same dilemma: either slow AI adoption until appropriate controls exist or allow employees to connect new agents directly into corporate systems despite limited governance.
"The answer," he said, "is that they let everything in. You cannot stop innovation in the name of security."
Identity becomes the control point
Rather than treating AI agents as another application requiring credentials, Hush is extending its existing non-human identity platform into what it calls an "Identity Gateway" for AI agents.
The platform sits between agents and enterprise resources, allowing organizations to discover agents, assign each one its own identity, associate it with a responsible human owner, broker task-specific permissions at runtime and maintain centralized audit logs.
Instead of allowing an agent to inherit all of a user's privileges indefinitely, Hush attempts to enforce what it calls "least agency"—granting only the permissions necessary for the specific task being executed.
The company says every action can be logged, attributed and revoked from a single control plane, while administrators retain the ability to terminate an agent's access immediately if necessary.
This represents a broader shift in enterprise identity management. Human identities have long been governed through identity providers, single sign-on and privileged access management systems. Machine identities have increasingly received similar attention as organizations modernized cloud infrastructure. Hush argues autonomous AI agents now represent a third identity category requiring dedicated governance.
Hush has not publicly posted its pricing for the Identity Gateway solution, nor its offerings more generally. But the company did release a Free plan that gives organizations access to runtime visibility for AI agents and non-human identities, risk analysis, and identity-based access controls intended to replace long-lived credentials, with no credit card or time limit required.
Governing every kind of enterprise agent
Hush says enterprises are no longer dealing with a single category of AI software.
During the interview, Rave described three broad classes emerging inside organizations:
Desktop coding assistants and productivity agents such as Claude, Cursor and VS Code integrations.
Enterprise AI platform agents running on services such as Microsoft Foundry, Salesforce Agentforce or AWS AgentCore.
Custom agents organizations build internally for business processes or customer-facing applications.
Each introduces different governance challenges, but all ultimately require controlled access to enterprise systems.
The problem, according to Hush, is that many agents currently authenticate using inherited human credentials or long-lived API keys, making it difficult to determine whether an action originated from a person or from an autonomous system acting on that person's behalf.
"If I see something in the Salesforce logs," Rave said during the interview, "did the user do that, or was it the agent the user was using?"
That attribution challenge becomes increasingly significant as organizations begin deploying multiple autonomous systems capable of initiating actions without direct human approval.
Existing identity tools weren't designed for AI agents
Rather than replacing identity providers or secrets managers, Hush positions itself as filling a gap between them.
Traditional IAM platforms authenticate employees. Secrets managers store credentials. Neither, the company argues, governs the runtime behavior of autonomous software acting on behalf of humans across multiple systems.
Hush says its platform continuously discovers known and shadow agents across enterprise environments, assigns ownership, brokers just-in-time credentials and records every interaction in a centralized audit trail. According to its product documentation, organizations do not need to modify their existing agents because the platform operates by brokering access requests rather than changing application logic.
That identity-first approach is attracting customers already deploying enterprise AI initiatives.
IT infrastructure services provider Kyndryl says it has deployed Hush internally and has begun offering the platform to enterprise customers.
"Our collaboration with Hush is rooted in a shared security philosophy: identity is the ultimate control point for the modern agentic workforce," said Adeel Saeed, senior vice president and CTO for Global Cyber Resiliency at Kyndryl, in a prepared statement.
Akamai's participation in the funding round similarly reflects what the company sees as an architectural rather than incremental shift.
"AI agents are driving the next transformation, and identity is the piece most companies haven't solved yet," said Ramanath Iyer, Akamai's chief strategist.
Security priorities are moving beyond the model itself
The broader AI security market has spent the past two years focused largely on prompt injection, model vulnerabilities, jailbreaks and LLM safety. Those remain active research areas, but enterprise deployments increasingly face operational questions around what autonomous systems are permitted to access and how those actions can be governed.
Hush argues that identity is becoming the enforcement layer for answering those questions.
Rather than asking whether an AI model can safely generate code or summarize documents, enterprises increasingly need to determine which systems an agent may access, whose authority it exercises, how permissions are delegated, and how every action can be traced back to an accountable owner.
Whether Hush's identity-centric approach becomes the dominant model remains to be seen. But as enterprises move from experimenting with AI assistants to deploying thousands of autonomous software agents, the company is betting that the next major security challenge won't be securing the models themselves—it will be securely managing the identities of the software acting on their behalf.
AI growth exposes data centers to power limits, cooling issues, water scarcity and regulatory pressure. Explore the key questions to raise with vendors.
Google's open-source TPU microbenchmark suite provides developers with granular performance metrics across Network, Compute, HBM, Host Transfer, and Attention components to validate real-world hardware capabilities. By leveraging these benchmarks to establish a Roofline model, engineers can accurately diagnose whether their machine learning workloads are compute-, memory-, or network-bound. This empirical baseline directly guides targeted software optimizations—such as kernel tuning, mesh sharding, and rematerialization—to maximize hardware utilization for large-scale model deployments.
Two AI computing clusters built from identical NVIDIA H100, GB200 NVL72, or GB300 NVL72 systems can deliver materially different training throughput. We...
Two AI computing clusters built from identical NVIDIA H100, GB200 NVL72, or GB300 NVL72 systems can deliver materially different training throughput. We routinely see 8% to 12% gaps between partner deployments and the corresponding NVIDIA reference architecture (RA) on the same workload, same model, same global batch size. The cause is often a stack of configuration choices in the kernel…
The latest version of Google DeepMind's AI model includes a significant jump into “physical AGI.” But plopping AI into the real world comes with risks.
VentureBeat’s June research found that 69% of enterprises are still running AI agents that share credentials, a practice associated with higher rates of security incidents and near-incidents.
But at VB Transform 2026, Mukesh Karki, CTO of NTT DATA AIVista, and Mayank Upadhyay, chief security and trust officer at Snowflake, argued that fixing identity is only the first step. Enterprises also need action-level authorization and tamper-resistant audit trails built into every agent interaction if they’re going to deploy autonomous systems safely at scale.
"These organizations need to be able to prove to their auditors in a very tamper-resistant fashion that those records showing what they did actually prove what they're doing," Karki said. "And the provability is essentially your license to operate in a regulatory environment."
Why shared credentials cause agentic AI security incidents
The problem, Upadhyay says, is many assumptions were carried over from an earlier generation of software.
"In the traditional software world, a human being clicks somewhere and the software does something very deterministic, and you know which API it's going to call," he said. "But in the agentic world, the software has a brain of its own, and it's constantly rewiring itself. If you give this software more permission than it needs for a particular goal, agents are exploratory by nature, so they're going to try lots of different things, and you'll have unintended side effects."
Embedding a single static API key compounds the exposure, he added.
"It's a really bad pattern if you have one API key, you shove it into the agent, and it's talking as anybody to a particular SaaS service, because then you're giving this agent the union of everybody's needs," he said, noting that the second failure mode is forensic, since "things may go wrong, and you wouldn't be able to attribute it to the right agent."
Scoped credentials are only the starting point in regulated industries
Karki, whose clients are mostly in insurance, healthcare, and finance, treats scoped credentials as table stakes.
"In a regulatory setting, an agent that's not broadly scoped with shared scope credentials is not going to run, period," Karki said. "Having a scope credential is just a starting point. There are actually two layered constraints. One is the jurisdiction in which the agent operates, and then it's the jurisdiction or the rules of that organization."
For instance, a claims adjustment agent in Washington State operates on different regulations than one in California, he adds, and every claim is different.
"Those scoped credentials are not enough, because it has to be action-based and rules-based at the time it's taking action," he added.
Where the employee analogy for AI agents breaks down
The employee analogy, Karki argued, only goes so far. Agents still need to learn an organization’s unique context, much as a new employee does. But unlike people, enterprises can’t realistically build trust with thousands of agents over time.
“A star employee in one organization might not be the best employee when they move to a different organization, not because they became worse, but because they don’t have the context of this new place, and the same is true with agents,” Karki said. “If every employee has 100 agents, you can’t say you’re going to onboard these agents and do a background check on them.”
Upadhyay said the employee analogy should place agents one rung lower in the organizational hierarchy.
"Treat them like interns," he suggested. "They have good intent, but they don't always know what they're doing, and you have to keep your eye on them while you gradually build trust."
On the Snowflake platform, administrators can impose platform-wide guardrails such as read-only operations, while developers further narrow an agent’s permissions when they launch each session.
A three-layer approach to AI agent governance
There's no question where governance belongs, Karki says.
"Governance has to happen at every agent action, and it has to sit outside the agent," he explained. "That's the only way you'll be able to prove later that the agent took an action it was allowed to take."
Upadhyay broke governance into three layers:
The agent layer covers identity, tool permissions, and MCP governance.
The model layer addresses indirect prompt injection and enables models to run inside the customer’s VPC so prompts remain invisible to the model provider.
The data layer covers least-privilege access, zero-copy architecture, and role-based access control.
For agents to work properly, governance is required across all three.
What enterprises should audit first
For enterprises auditing the governance of existing AI agents, Upadhyay recommends starting in two places. The first is auditing permissions for static secrets, the largest fixable attack vector. Next is addressing shadow AI through an MCP gateway, so developers no longer have to run bootlegged open-source MCP servers under their desks and administrators have visibility into who’s talking to which MCP server.
There's a tradeoff between constraint and capability, and that can be addressed at the task level, with confidence scoring used to withhold autonomous execution on high-risk actions, and sandboxing as a middle path. But Karki cautions enterprises already scaling their agentic systems.
"A lot of this can't be retrofitted after you have an agentic system running, and it's even harder to retrofit if you have to prove to your auditors why exactly the agent behaved the way it did," he explained. "Provability has to be built ground up when you're designing the system."
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.
Login
NVIDIA nvmath-python is a library designed to bridge the gap between the Python scientific community and NVIDIA CUDA-X math libraries. It gives Python users...