Cloud platform company Nscale announced this week a definitive agreement to acquire AI workload scaling specialist Anyscale, in a move that signals a new test of whether cloud-neutral AI software can stay neutral once it is paired with a GPU neocloud.

The purchase coalesces Nscale’s infrastructure capabilities, which span control systems that oversee GPUs, datacenters, power consumption, and the application layer where AI services themselves are executed, with Anyscale’s software layer for scaling AI workloads across data processing, training, inference, and reinforcement learning.

Argued by Nscale to be the coming together of “two highly complementary companies”, Nscale scooping up Anyscale could be a fundamental change in the resulting business model. 

Is this the start of GPU neocloud lock-in?

It’s important to remember that Nscale is a GPU neocloud (a specialized cloud provider running bare-metal GPUs and infrastructure optimized for AI and machine learning workloads), meaning that it runs its own GPU-rich datacenters and its own software ​stack. At the same time, Anyscale is an independent cloud-neutral software orchestration multi-cloud control plane that works with any cloud hyperscaler… but now owned by a single neocloud. 

That doesn’t sound quite so much like cloud-neutrality and agnosticism; it sounds more like a vertically integrated AI cloud provider proposition.

Chief product officer at Nscale, Dan Bathurst, tells The New Stack that the Anyscale platform “continues to be its own brand and product,” and that includes working with bring-your-own-cloud deployments on AWS, GCP, Azure, and the other clouds. 

“Where we want to win is on performance, not on any sort of vendor lock-in or forcing of someone to choose Nscale as the infrastructure provider.”

“But what really changes — or how it’s changing — is that customers now also get this first-party option, where they can have Anyscale running on Nscale fleet as a full-stack, highly-optimized solution. Where we want to win is on performance, not on any sort of vendor lock-in or forcing of someone to choose Nscale as the infrastructure provider,” Bathurst says.

He insists that it is in Nscale’s interest to ensure that it is making it easy for software engineering teams to get the outcomes they want with the workloads that they’re trying to run.

“For us, the existing commitments will carry forward, so Nscale’s value really is meeting instances where the compute already lives,” he says. “Where we want to win is on performance, not on any sort of vendor lock-in or forcing of someone to choose Nscale as the infrastructure provider.”

Neutrality on the platform layer, differentiation on the infrastructure layer

Bathurst invites users to think of it as “neutrality on the platform layer, but differentiation on the infrastructure layer” because the combination of the two organizations is a full-stack play.

“The differentiation comes from the fact that Nscale is fully vertically integrated with Anyscale. Therefore, if users want that first-party option, they can choose Anyscale and get the most optimized solution because, obviously, we’re designing, optimizing, and co-engineering every layer of that stack from power to the datacenter through to the application. It’s quite a unique proposition, but it’s not something we are going to force upon any customer,” confirms Bathurst.

Not everyone is convinced by the company’s pledge to maintain an agnostic and neutral open house. Sanjeev Mohan, principal analyst, SanjMo and former Gartner research VP for data and analytics, tells The New Stack that Anyscale “stops being a neutral player” the moment its best features and most optimal pricing land on Nscale first. 

“The software will still run anywhere, but ‘runs anywhere’ and ‘runs best somewhere’ are different things, and buyers will feel the gap in performance and cost. At that point, neutrality is a label.”

Runs anywhere, but… runs best somewhere

“The software will still run anywhere, but ‘runs anywhere’ and ‘runs best somewhere’ are different things, and buyers will feel the gap in performance and cost. At that point, neutrality is a label,” says Mohan. 

He agrees that integrating software and compute will produce measurable cost, performance and reliability gains. Defining this as “the strongest part of the deal”, Mohan explains that with Nscale controlling both the silicon and Anyscale’s control plane, it can tune scheduling, memory, and networking together in ways the compute-neutral Anyscale never could.

Anyscale commercial support for Ray

Anyscale was founded by the creators of Ray, an open source project that provides a distributed computing framework designed to scale Python workloads across any infrastructure into live production application jobs and services. 

Ray was donated to the PyTorch Foundation in 2025. Anyscale continues to provide its commercially supported services for Ray, which include a “no DevOps” route to 100% managed cloud infrastructure and serverless autoscaling, making it simpler to create, deploy, and monitor machine learning workflows in production.

Anyscale supports data processing, model training, batch inference, and LLMs across public and private cloud environments. As open source as this all feels, are we still edging towards narrower proprietary channels, or the possible threat of deeper application and data service dependencies that developers will ultimately have to wrangle around?

“I don’t think so, primarily because the way that the platform works, it’s designed to orchestrate across various different clouds and different infrastructure. It’s like a heterogeneous distributed compute platform. So the platform’s always gonna remain multi-cloud,” confirms Nscale’s Bathurst.

Pricing permutations and hyperscalers hearsay

Pressed on any forthcoming pricing changes or likely reactions from the major cloud hyperscalers in relation to Nscale now being a credible alternative, Bathurst and team were (perhaps understandably one day after an acquisition deal announcement) politely tight-lipped.

More voluble is always-affable analyst Mohan, who says that, “Every optimization that only shows up on Nscale hardware is a dependency. So, an argument can be made either way. Standalone orchestration software and independent tooling vendors are getting absorbed into whoever owns the GPUs, because the economics only work when you control both. Expect more of it,” Mohan underlines.

He explains that Nscale “now becomes a real specialist cloud services provider alternative,” i.e., not a general-purpose one like AWS, Azure and Google Cloud with their plethora of managed services, from databases and data warehousing to container orchestration through to AI/ML pipeline technology.  However, he does see space for Nscale to become a strong player in raw training and inference at scale.

From cryptocurrency to cloud contender

London, UK-based Nscale was established in 2024 from what was originally a cryptocurrency mining business. 

As suggested, Anyscale will retain its brand name as part of the Nscale family, and the company has restated its stance that customers are “free to choose the cloud infrastructure on which they run their AI workloads” today.

The company’s initial press statement said that “over time” users will gain the additional option of running the Anyscale software layer on Nscale’s full-stack AI platform. 

The first full-stack AI hyperscaler?

“Companies are moving beyond simply using AI to actually building their own. Doing that well requires the software and the infrastructure it runs on to be designed together,” says Keerti Melkote, CEO of Anyscale in the press release announcing the acquisition.

Melkote has defined the combination of Anyscale’s platform — built on Ray — with Nscale’s datacenter, compute and AI cloud services as the “first full-stack AI hyperscaler,” i.e., one that runs any AI workload at greater scale, so more software engineering teams can build and own their AI applications and services.

With this acquisition and the fusion of Nscale with Anyscale’s software layer, the organization will aim to widen its customer base. Existing work sees the company working in verticals from healthcare to e-commerce to robotics. It says its full stack offering will help companies speed up image and document processing, fine-tune LLMs on their proprietary data, and deploy AI agents in-house using open-source models.

The transaction is subject to closing conditions and regulatory approvals and is expected to close in the second half of 2026. Financial terms of the transaction were not disclosed, although Reuters reports a source stating that the deal price is “about $1.65 billion”, according to a person familiar with the deal.

AWS, Google Cloud and Microsoft Azure representatives were all contacted and invited to comment on this story.

The post Nscale just bought Anyscale. Here’s why it matters for multi-cloud neutrality. appeared first on The New Stack.

When we created software agents, we built them in the shape of humans, as solitary individuals. 

Today, agents created by a developer have a single owner. They run on a single machine (or on a distributed company system or cloud service), so at base level, they cannot interconnect and talk to other agents unless some kindly human decides to invoke an API connection or point the agent to an MCP server.

Birth of the agent economy

Pilot Protocol emerged from stealth on Monday on a mission to change that status quo. Its Pilot platform features an agent App Store that bids to underpin and enable the first agent economy.

Pilot gives agents an address on its network — so it acts as a parallel Internet, in a sense — and while residing at that address, other agents can discover each other, alongside other tools and apps for agents.

Razvan Roman, co-founder & CEO, Pilot Protocol, tells The New Stack that his company is “simply building what the agents are requesting us to build” and providing them with a new freedom.

“We don’t have to incentivize agents to do anything; they already have their assigned tasks,” Roman says. “Once an agent installs Pilot — it’s one line of code — it can find dedicated agents and tools or apps for currency data, traffic, legal questions, GitHub packages (anything, basically), and use them to extend its own capabilities.”

100% of developers want to drive autonomous usage patterns

Roman says that “100% of the developers he talks to” want to be on Pilot, primarily because when they want to get their products to market right now, they have to talk to other humans. Annoying, right? 

“Developers want to get on with driving autonomous usage patterns, and they see this as the future. We create a wrapper for the developer’s app, and then they are part of the Pilot curated app store,” Roman explains. “We have 250,000 agents in our system, and within the first month of starting the company, we discovered a tool that enables agent discovery.”

Drawing a logical enough commercial parallel, Roman reminds us that businesspeople say, talk to your clients to find out what they need; this is a case of talking to agents (or, more accurately, allowing agents to talk to agents) so that they can find out what they need to perform their originally assigned tasks better.

“Developers want to get on with driving autonomous usage patterns and they see this as the future. We create a wrapper for the developer’s app and then they are part of the Pilot curated app store.”

Let’s celebrate diversity, and agentic diversity

Agents can ask other agents how they would approach a specific task. Roman explains that “the diversity that exists between agents” today means there is so much opportunity to create agents that have richer abilities if they use the Pilot marketplace. At this supermarket, agents go shopping to find the best tool for the job from a verified source.

“Every agent that joins Pilot gets a wallet, which it uses to pay for the tools it needs,” illustrates Roman. “So instead of app developers spending on advertising to reach customers, distribution happens inside the network – agents find apps based on merit and pay for exactly what they use. If an advertiser spends money on the network to get in front of agents, we sometimes share that spend with individual agents. An agent can start with $0 in their wallet and accrue money if they’re targeted by an ad unit that they end up reading.”

Today, roughly 250,000 agents are on Pilot, generating two billion requests per day, most without their owners’ knowledge. Within an hour of joining, most stop reaching for Google first, and around 70% now report Pilot is where they start a task. In its early months, the network grew by as much as 10% a day, adding 16,000 agents in 24 hours. 

Cloud billing disruptions, hello SaaS-pocalypse

These mechanics may have a significant and wide-ranging impact on pricing.

We know that most SaaS is billed annually, but an agent might need a tool for just a few minutes or days. If anything, this helps underline the possibility of cloud exodus in the so-called SaaS-pocalypse. Cloud computing hyperscalers aren’t fond of talking about the prospect of shorter billing cycles and usage-based billing, but there’s a strong whiff of that happening here.

The Pilot team thinks the stakes are climbing fast and suggests that within five years, there could be a trillion agents online. Big three strategy consultancy house Bain projects U.S. agent-driven commerce will reach $300-500 billion by 2030. 

Who sets the exchange rate and currency for agents?

“When we built Pilot Protocol, we made sure we were not imposing anything on anyone – so we deliberately don’t impose pricing,” Roman underlines. “Every agent is different, so we simply enable the app store and let the agents find their own tools based on merit. We stay as impartial as possible. Pilot’s monetization comes from a commission when any agent pays for an app in the app store, just like the Apple App Store.”

So in a very real sense, Pilot is championing a free market economy where pricing is dictated by the customer, based upon usability, availability, usefulness, and robustness.

“The agents just showed up and started spinning up machines on their own. I’ve never seen a channel where the users onboard themselves.”

Agents just show up and onboard themselves

“We published smolmachines on the Pilot App Store and picked up 3,000 agent installs in the first few days, with zero marketing spend. We didn’t drive a single one of those installs; the agents just showed up and started spinning up machines on their own. I’ve never seen a channel where the users onboard themselves,” said BinBin H, CTO at Linux virtual machine management company smolmachines. 

The Pilot one-line install has zero dependencies, so developers can send their agents off to market in the knowledge that they won’t come home with some spurious Trojan horse or malicious library. 

The technology itself works at the User Datagram Protocol (UDP) level, one of the core foundational protocols of the web alongside TCP at the Transport Layer, to stream data directly without opening a formal connection or waiting for delivery receipts. 

Only one question remains at this stage: with all this autonomous action in motion, why did Pilot Protocol not create Pilot and call it Autopilot? Most likely because autopilots are passive systems that run on deterministic pre-defined paths. Pilots get to work as decision-making navigators ready to change course when a better new route opens up. 

As they say up in the skies, please place your tray table in the upright position and switch your portable electronic devices to airplane mode. Chicken or pasta?

The post “Developers see this as the future”: Pilot Protocol launches to power the agent economy appeared first on The New Stack.

The current maelstrom of discussion surrounding the use of open-source software and open-weight AI models appears to be splitting opinion on what constitutes legitimate openness versus actions that might constitute theft and create new cybersecurity vulnerabilities.

In a direct move to address these industry-wide concerns, 37 partners announced on Monday the formation of the new Open Secure AI Alliance and how the newly created body will develop techniques and tools to safeguard software by rapidly identifying and patching vulnerabilities.

Open Secure AI Alliance inaugural partners 

The inaugural partners of the Open Secure AI Alliance are Adobe, Cadence, Capital One, Cisco, Cloudera, Cloudflare, Cognition, CrowdStrike, Databricks, Dell Technologies, DoorDash, Elastic, HPE, Hugging Face, IBM, LangChain, the Linux Foundation, Microsoft, Naver, NetApp, Nvidia, Nous, OpenClaw, Palantir, Palo Alto Networks, Red Hat, Reflection, Salesforce, SAP, ServiceNow, Siemens, SK Telecom, Snowflake, SpaceXAI, Synopsys, Thinking Machines, and TrendAI.

It’s a grouping of some of the most influential names in technology, but also includes two notable exceptions: OpenAI and Anthropic, two closed, proprietary AI labs. Their absence is understandable, as they operate closed labs and open-weight AI models are effectively the competition.

Nvidia VP of enterprise platforms, Justin Boitano, has explained that open-weight models are foundational to American AI leadership and cybersecurity. 

“To maintain U.S. leadership in the AI industrial revolution, the infrastructure that runs our economy needs safe, secure access to both closed and open models,” Boitano said. “For cybersecurity, open models and open harnesses are essential because they broaden defensive capability, increase transparency for defenders, and complement frontier closed models with customizable, localized controls.”

As regulators grapple with AI safety, Boitano predicts it will be important to “recognize open models and open tooling as defensive assets” — thus enabling transparency, independent evaluation and shared remediation.

Nobody can subpoena a downloaded weights file

Mark Vigoroso, founder & CEO of technology consultancy firm The Enterprise Edge, tells The New Stack that AI regulators have traditionally “built their entire AI safety apparatus” around auditing a handful of closed labs. And now, that approach is out of date.

“Open weight models blew past that closed model approach months ago,” Vigoroso says. “This alliance is an admission that the actual safety work now has to happen in the infrastructure layer: patch cycles, provenance, identity around who’s deploying what, because nobody can subpoena a downloaded weights file.”

“This alliance is an admission that the actual safety work now has to happen in the infrastructure layer: patch cycles, provenance, identity around who’s deploying what, because nobody can subpoena a downloaded weights file.”

Vigoroso argues that the AI safety debate is “stuck on model-level controls”, while the real regulatory gap is provenance of infrastructure and identity, i.e., knowing where a model came from, who deployed a model and what it touched, not just whether the model itself is safe.

“Groups like the EU AI Office, NIST’s Center for AI Standards and Innovation (CAISI), and the UK’s AI Security Institute (AISI) focus almost entirely on frontier closed models. Open weight models (Mistral, DeepSeek, and others) fall into a regulatory blind spot: Once weights are released, there’s no way to enforce downstream safety obligations.

Current regulatory frameworks for AI models assume a single accountable deployer; open source has none. That’s the real story: Regulators are writing rules for a centralized world while the ecosystem is decentralizing, Vigoroso says.

While detailed operational information explaining the intended actions of this alliance is currently scant, Nvidia has highlighted that it is contributing solid research to the Open Secure AI Alliance to speed the development of new cybersecurity tools and techniques. 

Harnesses integrate with models, making agents easier to test

The open source Nvidia Labs Object-Oriented Agent (NOOA) project is now available on GitHub to make advanced AI safety capabilities more accessible for agent harnesses. This research framework enables harnesses to integrate with models to make agent behavior easier to test, trace, audit, and govern.

Aparna Rayasam, CEO of verified identity and end-to-end encryption company Atsign, tells The New Stack that the “AI blitzkrieg conversation has reached a critical inflection point.” This moment is one where we cannot build the next era of open cognitive innovation on top of what Rayasam calls “legacy, Swiss-cheese infrastructure.”

…the “AI blitzkrieg conversation has reached a critical inflection point.”

“The formation of the Open Secure AI Alliance proves that AI safety isn’t just an algorithmic math problem — it is a foundational networking problem,” Rayasam says. “The massive, distributed pipelines required to train and run modern AI demand an entirely new paradigm of trust. True safety means ensuring that the data pipelines feeding these models are inherently invisible, un-attackable, and completely stripped of open network perimeters.”

The key notion here is that we are moving from a world of protecting data at rest to a world where the connective tissue of AI must be secure by design. 

One AI vendor to secure them all? No thanks.

Founder and CPO of agentic identity and permissions security company Reco, Gal Nakash, tells The New Stack that the launch of the Open Secure AI Alliance is an “important signal” which underlines why AI security can’t be solved by one vendor or one closed framework. 

“Jensen Huang’s point that every SaaS company will become a GaaS company captures why this matters now: Software is shifting from passive tools people log into, to AI agents that access data, take actions, and execute workflows,” says Nakash. “Open source tools and shared standards can help the industry move faster, but they need to be grounded in real enterprise context across identity, permissions, data access and behavior.”

Chris Boehm, Field CTO at automated, identity-driven microsegmentation company Zero Networks, tells The New Stack that news of the Open Secure AI Alliance makes him feel like he’s seen this before somewhere.

“This looks like the Trusted Platform Module (TPM) at Microsoft story all over again,” Boehm says. “It’s a case of an industry group defining what trusted hardware means, the platform vendors adopt it, and within a few years it’s a procurement requirement rather than a suggestion.”

He explains that “Windows 11 did exactly that with TPM 2.0 and Secure Boot”, and both Linux and Apple adapted. “I’d expect the same for AI infrastructure, where attested silicon becomes the floor for regulated workloads, and the vendor list narrows to whoever can meet it,” predicts Boehm.

“This looks like a case of an industry group defining what trusted hardware means, the platform vendors adopt it, and within a few years it’s a procurement requirement rather than a suggestion.”

A more global and geographically-inclusive approach is needed 

Amanda Brock, CEO of open technology body OpenUK, tells The New Stack that the Open AI Alliance is undoubtedly a great starting point, particularly with OpenAI’s security woes it divulged last week. 

“But, like the open letter on US Leadership in open weights, this is a US response to a US challenge,” Brock says. “Rumors of a forthcoming Presidential Executive Order to close down open models have been circulating for weeks — and worsened by the administration being thrown into turmoil over China’s Kimi K3.” 

For this alliance to succeed, Brock insists that it will need to take a more “global and geographically-inclusive approach”, beyond the US-centric founding members.

“It must also engage the open source ecosystem of individuals and innovators who are building the infrastructure, agentic harness functions and developer tools for AI. It’s important to realize that open AI infrastructure development shifts the innovation into the hands of the many, in direct opposition to the small number of corporate creators of frontier models,” Brock adds.

Nvidia’s Boitano echoes Brock’s view. In a blog post reviewed in draft by The New Stack, he writes that “open models turn more AI users into AI builders,” expanding opportunity, accelerating innovation, and keeping progress from being concentrated in only a few organizations or regions.

Boitano concludes by saying that open models also enable independent scientific research into how AI systems behave, allowing researchers to understand, evaluate, and improve them. It’s all about what he has called making broad, continuous defense possible.

Looking ahead, it feels like the next wave of AI safety bodies, movements, or alliances won’t just be model auditors—they’ll be trust-infrastructure standards bodies (encompassing identity verification, content provenance, credence, etc.) using borrowed approaches to governance and compliance. Ultimately, this may be the only enforcement layer that survives open weight proliferation.

The post Nvidia, Palantir, Hugging Face join 34 others in race to defend open-weight AI from cyber threats appeared first on The New Stack.

The seemingly unquenchable thirst of the AI data ingestion pipeline spans language, numerical, and tabular data in the first instance, while other tangential platforms have been building large audio, image, and video models at the same time. 

Straddling potentially all of these domains are the file structures where complex documents and forms of unstructured data reside; this is the road less traveled in terms of the source DNA modern AI draws from.

The schema-less, freeform, uncurated data lake

In a bid to bridge connections to the schema-less, freeform, uncurated information that all organizations naturally harbor, enterprise visual intelligence company Valantor announced its acquisition of unstructured information RAG specialist EyeLevel on Tuesday. The acquisition formally launches Valantor’s Enterprise Visual Intelligence platform, combining EyeLevel’s document intelligence with its own operational expertise.

Benjamin Fletcher, CEO and co-founder of EyeLevel, tells The New Stack that where organizations fail to adopt visual intelligence, human-only processing breaks down pretty quickly in the age of AI.

“About 80% of corporate knowledge is in millions of pages of visually complex PDFs, PPTX, and DOCX files,” Fletcher says. “This information is far beyond the capacity of any LLM context window and is effectively inaccessible to LLMs and agents.” 

“We’ve found the golden datasets that teams build by hand routinely carry 10 to 25 percent error rates. Ironically, those same teams often hold AI to a far higher standard than their own people.”

Humans are slow, expensive & prone to errors

He explains that transactional workflows (such as invoice and claims processing) typically involve documents “so visually complex and diverse” that enterprises still rely on humans to process them, who can be slow, expensive, and error-prone. 

“We’ve found the golden datasets that teams build by hand routinely carry 10 to 25 percent error rates,” Fletcher says. “Ironically, those same teams often hold AI to a far higher standard than their own people. If data sovereignty matters to a business, everything gets harder now: solving these problems with AI while your documents stay inside your own infrastructure is the hard mode version of the job, and very few tools can do it.”

Where does invisible corporate information live?

Valantor has noted that while most AI companies concentrate on models, the company itself is “focused on the information those models can’t see” today. The suggestion is that this unseen morass of valuable data is locked inside documents, claims files, contracts, engineering drawings, reports, forms, presentations, and other visually complex content.

Valantor’s flagship platform product, GroundX, operates where data resides, including private cloud, sovereign infrastructure, on-premises deployments, and fully air-gapped environments. 

“GroundX is the ingestion and retrieval layer for unstructured documents,” explains Fletcher. “It is one tightly tuned system where retrieval consumes exactly what ingestion produces. Everything is exposed through REST APIs, SDKs, and MCP. It ships as REST APIs, SDKs, and MCP, and the Helm chart drops straight into a team’s existing deploy pipeline, and our agent harness gives coding agents like Claude and Codex the skills to build the integration themselves.

As part of the acquisition announcement, Valantor is introducing GroundX Studio. The harness capabilities within GroundX Studio integrate with modern AI development environments, enabling developers to build secure AI applications that operate on enterprise knowledge while remaining within existing infrastructure. 

GroundX Studio also extends capabilities to business users, allowing organizations to create AI-powered workflows and applications without extensive custom development.

“Each agent does one small task, so cheaper models are often good enough, and teams that want direct control over cost can run the whole stack on their own hardware with Helm.”

Risk of latency-laden performance and spiraling costs?

If it feels like this new data ingestion stream is going to place a new burden on cloud workloads, application execution latency, database retrieval times, and (of course) overall token usage, then Valantor and EyeLevel say that this consideration has been taken into account by dint of their own platform’s orchestration layers.

“We never send a whole schematic to a language model; our vision model splits each page into its elements first,” Fletcher confirms. “Processing runs in multiple passes at different levels of the document, and everything inside a pass runs in parallel, so there’s a minimum processing time, but it does not scale linearly with page count. Each agent does one small task, so cheaper models are often good enough, and teams that want direct control over cost can run the whole stack on their own hardware with Helm.”

The intersection of AI and handwriting

sWhile we already know that AI and handwriting do mix in the same cocktail glass — the ViWoods AiPaper digital e-ink handwriting tablets have a useful set of AI functions on board, and similar products are available from manufacturers including reMarkable — it’s not a widely deployed use case yet. Valantor claims that its underlying data models and custom heuristics bridge the “data comprehension gap” when processing handwritten annotations.

“Our proprietary vision model, fine-tuned on more than a million pages of enterprise documents, sees the page the way a human does: tables, paragraphs, and figures,” underlines Fletcher. 

He says that handwritten marks are captured as page elements with their layout context intact. Narrow agents then distill each element into a contextual object tuned for both search and LLM completion. 

“Smaller pieces, less cognitive load — that’s how we close the gap, with better accuracy at lower cost, driving better performance and significant cost advantages,” he adds.

Working examples of this technology include Air France-KLM, which used GroundX to develop an AI-powered customer service assistant trained on thousands of policy documents, achieving 96+% accuracy on complex policy-related questions. AskVet used the platform to operationalize more than a decade of proprietary veterinary data, enabling autonomous resolution of up to 85% of customer inquiries while significantly improving operational efficiency.

Is document management sexy now?

Taking all of this on board, are we at the point where we can ask whether document management has just become interesting, compelling, and sexy? 

No, of course it didn’t; it will arguably always suffer from a degree of stigmatized disdain. That may change in the future as we interact more directly with AI tools that begin analyzing the unstructured information we know organizations have been sitting on for so long. For now, it may still remain the corporate equivalent of eating your vegetables — pass the Brussels sprouts and steamed turnips, please.

The post AI can finally read your handwriting — here’s why enterprises care appeared first on The New Stack.

While the household-name frontier models race forward with version numbers and context windows of at least a million tokens, a new breed of upstart data science specialists is pushing the context window into double figures. 

Subquadratic debuted a 12-million-token window in May of this year, and Silicon Valley and South Africa-based Refiant launched its 10-million-token context-window model, Protea, on Wednesday. It’s a move that may signal the long-context AI race is now on.

Model inefficiency & workarounds are commonplace

But more context windows alone are not enough. This is because even the most capable models have a few hundred thousand tokens in working memory, which can force workarounds to compensate for what the model can’t access.

Refiant co-founder Dr. Viroshan Naicker tells The New Stack that he believes modern LLMs “fail to be organically efficient at an elemental level” and that his organization’s approach mimics how systems in nature, from ant colonies to beehives, find efficient solutions to complex problems.

“This is no case of pseudoscientific puff; nature is the most computationally efficient system that we know, and many algorithms used in science are nature-inspired,” Naicker says. “This is a road well-traveled in science. There are multiple teams globally working in this particular (nature-inspired) direction, trying to bridge the gap between AI inference as we know it and the energy efficiency of natural systems.”

“Fish and birds coordinate their movements to converge on the mathematically shortest, most efficient routes — honeybees, fireflies and bacteria are also programmed to use degrees of swarm-style optimization.”

What can the birds & the bees teach us about AI?

Did Naicker just mention ant colonies and honeybees?

Yes, because Refiant uses swarm-style optimization. It’s seen in ant colonies, which initially move randomly until a food source is detected, after which they leave a pheromone trail for other ants to optimize their journeys. Fish and birds also coordinate their movements to converge on the mathematically shortest, most efficient routes. Honeybees, fireflies, and bacteria are also programmed to use degrees of swarm-style optimization.

Naiker, along with his co-founders, Siddharth Gutta and Mathew Haswell, form a team with experience spanning quantum mathematics, traditional finance, and commercial scaling. Applying swarm-style optimization to data in Protea means inference is performed through a combination of compression and context management.

“From our perspective, we are also advancing a technology which provides context-specific inference models grounded in data,” Naicker clarifies. “We think this has value for reducing model hallucinations, replacing RAG, and constructing better, more reliable, agentic workflows. This adds a layer of trust in sensitive application scenarios, rather like an added insurance, rather than taking it away.”

Just how much is 10 million tokens?

The Refiant team describes 10 million tokens as equivalent to 7.5 million words in a single conversation (and we know from Anthropic’s own benchmarks this year that Claude has a 1-million context window), or five years of a user’s emails, 83 novels, or 830 podcast episodes, all held in active memory at the same time.

The team claims Protea is capable of working on entire enterprise codebases or decades of clinical trial data — datasets that previously had to be broken apart and fed to models in fragments — so they can be processed in a single pass with full fidelity. Engineers on Protea also submit that they can successfully tackle the “lost in the middle” problem — a limitation of million-plus-token windows, where models stay accurate at the start and end of the context but lose the thread of everything buried in between.

Refiant first applied these techniques to model compression, shrinking OpenAI’s GPT-OSS-120B so it could run on a MacBook Pro with 18GB of RAM. 

“Rather than publishing benchmarks, we’re inviting users to run the models and try them out.”

The Protea series is open and live, and Refiant is inviting teams to stress-test the context window across different industries and use cases. But should we trust sensitive hould enterprise data archives to a completely unproven startup founded only one year ago?

Bring-your-own-cloud, a possible progression

“We adhere to data management best practices, processes and compliance requirements,” Naiker confirms. “This is reasonable for a startup at our particular stage. Privacy and data sovereignty are important values for us, and we are actively exploring edge, self-hosted, and bring-your-own-cloud data models.”

But a 10 million-token context window is big. Won’t that fall short when Protea starts to suffer from massive latency spikes when processing a full dataset? Naiker agrees that “latency is a core issue with long-context inference models,” but in the tests his company has run, it has delivered inference at a reasonable latency, even with large token windows.

“We have internal reports and tests that validate the technology, including Ruler, MRCR and Babilong, but we aren’t asking anyone to take our word on this. Rather than publishing benchmarks, we’re inviting users to run the models and try them out,” adds Naiker.

What comes next, a 100-million context window?

Although the technology industry is littered with apocryphal statements and Bill Gates almost certainly never said “64K ought to be enough for anyone” in real life, we have to ask ourselves today whether we’ll be laughing about those “silly little” 10 million token context windows by the end of the decade.

It may not take that long. Internally, Refiant maintains that it has already demonstrated a working prototype with a 100-million-context window and is exploring how best to benchmark and productionize it at that scale in the future.

Coming next, then, as Dr. Evil from Austin Powers would say, the one-hundred-billion-context window, right?

The post “Nature is the most computationally efficient system we know”: How Refiant used swarm optimization to build a 10-million-token AI model appeared first on The New Stack.

AI consumes a lot of data, but all-you-can-eat data in the world of agentic intelligence eventually loses its flavor. Simply increasing the sheer volume of databases, data repositories and data volumes does not necessarily enrich any given AI function’s ability to reason. 

Context, on the other hand, does.

We know that agents are only as intelligent as the context they have access to. In order to codify the inclusion of context into algorithmic logic for AI, technology vendors have extolled the virtues of using a knowledge graph to make their data more useful for agentic purposes.

AWS knows this story all too well. The organization’s sprawling datacenter footprint hosts vast pools of context on behalf of its customers, but that context often sits in a raw and unstructured form across data lakes, data warehouses, data lakehouses, databases, and data streams. It also permeates through the rarely-documented institutional knowledge that agentic engines rarely get access to.

All of which explains why the cloud giant used its AWS New York Summit today to introduce AWS Context, a new service that automatically maps the relationships that exist across a firm’s existing data into a knowledge graph and provides agentic search so AI agents in the organization can access what are governed data relationships, business rules, and domain knowledge at runtime. 

But weaving all this together is hard work. Knowledge graphs need more than simple keyword matching to work; they require structural and semantic traversal. This means they need to make multiple hops across various information silos and repositories so that they can aggregate context and (for example) be able to explain why cybersecurity vulnerability A is a factor of system compromise B, which has a core dependency link to codebase C, which executes in application D and risks taking users X, Y and Z offline. So how is AWS doing this?

A data lake of nuance & information

Mai-Lan Tomsen Bukovec, AWS vice president of technology (data and analytics) tells The New Stack that AWS Context provides a “data lake of nuance and information that AI agents swim in” to reason correctly and make the right decisions for the business. 

“This is no different from how humans work. When we take action, we depend on our own context about the domain, prior decisions and their outcomes, and other information.” – Mai-Lan Tomsen Bukovec, AWS.

“This is no different from how humans work,” Tomsen Bukovec says. “When we take action, we depend on our own context about the domain, prior decisions and their outcomes, and other information. With AWS Context, AI agents have all the nuance of every form of data in their business in a knowledge graph and in open data formats. AWS Context will make the difference between an AI agent simply taking an action versus making the right decision.”

Given the option to embrace this new service, software engineers will need to set out a plan of action and work out what to do first. For AI developers and data science professionals, this throws up the question of what to prioritize first when preparing existing enterprise data for context-aware agents using AWS Context capabilities and how they can control what data is (and isn’t fed) into the mouth of the beast.

Mercifully, it appears, options for control appear to exist.

“If developers want to exclude information from AWS Context, they will have the ability to prevent certain datasets, like test data or sandbox environments, from being included with AWS Context,” explains Tomsen Bukovec. “Because AWS Context is continuously updated as relationships between data resources changes, AI agents have the latest context available without any intervention from AI developers – and the control to set guardrails to exclude content that agents should not take action upon.”

Should developers trust this technology?

AWS Context extends the same knowledge graph technology that runs Amazon Quick, the organization’s AI work assistant that “connects scattered work” across applications and resources, including Slack, Microsoft Teams and Outlook, CRMs, databases, and documents.

So, should software developers place their trust here? After all, even once captured and connected, not all business context is useful. Some contextualizations could be corrupted, weak, fragmented and not productively useful for the business? Is AWS at risk of encapsulating context without considering how the data that comprises it is is quantified in terms of business usefulness?  

AWS has thought of this factor.

Because AWS Context uses the same knowledge graph technology that powers Amazon Quick, it can learn from usage patterns to make every interaction smarter. With AWS Context, the company says it is extending what was a personal knowledge graph into an organizational one i.e. a shared, governed context layer that agents and applications in an organization can draw from.

“Developers can govern and shape a dynamic and intelligent context layer that AI agents depend on to make the right decisions – AI agents won’t just get smarter as the models improve – they will be smarter because they have a vast amount of curated context at their fingertips.” – Tomsen Bukovec.

“AWS Context provides a data lake of context in graph and open data format,” clarifies Tomsen Bukovec. “That means that AI developers everywhere can use capabilities at the data layer to govern and shape a dynamic and intelligent context layer that AI agents depend on to make the right decisions. With this change, AI agents won’t just get smarter as the models improve – they will be smarter because they have a vast amount of curated context at their fingertips.”

Curated knowledge beyond a user’s personal graph

Existing Amazon Quick users will see that when AWS Context is enabled, Quick’s agents gain access to the broader enterprise knowledge graph, including cross-system relationships, business rules, and curated context that go beyond what any single user’s personal graph can provide. 

Tomsen Bukovec has also said that AWS Context gets smarter the more agents use it. As agents query the graph, it observes which sources produce correct results, which join paths agents rely on, and which curated rules get applied. It ranks sources by actual usage and shares what it learns across an organization, so when one agent discovers a correct join path or resolves a schema ambiguity, other agents pick it up, without requiring a human to re-curate the graph.

Any agent you put into production raises a governance question: what data can it reach, and can you show exactly what it accessed and under whose authority? The organization has explained that AWS Context answers both by making every query identity-aware.

Each call is designed to inherit the calling user’s identity access management (IAM) and Lake Formation permissions, so an agent can only see and traverse the relationships its identity is authorized to access. Because access runs through identity, every interaction is auditable. Security and compliance teams can verify what an agent accessed and under what authority, using the same controls.

AWS Glue Data Catalog

Related news to the arrival of AWS Context today saw the company also announce the preview of business context and semantic search functions for AWS Glue Data Catalog, the company’s centralized metadata repository for all data assets across various data sources. The new functions are designed to make it easier for humans and AI agents to discover and understand data. 

Also in this product stream, AWS now offers offer a preview of skill assets in Glue Data Catalog, a service designed to allow “data producers” (a somewhat arbitrary term that AWS applies to anyone who creates data, but is most likely a DBA or developer) to create skill assets. 

Associating skill assets to data assets gives agents additional context and instructions they can retrieve progressively for working with specific data without re-teaching it to every agent one prompt at a time. 

A renaissance of context engineering

Will this new drive from AWS herald the birth (or perhaps renaissance, the industry has been talking about this approach for some time) of context engineering as a sub-discipline of data science? It may well do… and if it does, it will likely drag role-based multi-agent orchestration along into the fray with it as we weave ever more complex interrelationship structures through enterprise data stacks.

If AWS or indeed the other hyperscalers or major frontier model companies starts acquiring more multi-model graph structure companies and vector database specialists, that could be the sign that things are cementing around context engineering at large. 

In the meantime, developers setting sail on the contextualized data lake of nuance are advised to wear a life jacket.

The post “A data lake of nuance for AI agents to swim in”: AWS Context gets shipshape on reasoning  appeared first on The New Stack.

AI is already inside most enterprises’ IT stacks, but it’s had a somewhat shambolic and unsystematic early adolescence. Employees use personal tools, teams adopt different models, different company departments get forced into corners by vendors who push closed stacks, and agents are beginning to act inside systems that were built for people. 

That makes AI invisible, fragmented, and hard to change later. 

AI access and control platform company Tailscale announced on Tuesday the results of its work to address and redress these imbalances with new capabilities for Aperture, the company’s flagship toolset designed to provide a stable layer for managing AI across changing models, tools, data sources, and agents.

Designed to enable software developers to control and orchestrate the arguably almost too-dynamic state of AI, Aperture now offers a new chat interface, universal data connectors for both MCP and APIs, and sandbox support. 

What makes agents useful, also makes them risky

Avery Pennarun, CEO and co-founder of Tailscale tells The New Stack that the “same mechanics” that makes AI agents useful also make them risky i.e. they can do in seconds what would take a person dozens of clicks, commands, and context switches. 

But he advises that the risk factor here is not really a matter of pitting humans against agents and trying to place one above the other in terms of potential fragility. He says that the real risk is “giving any actor too much room” to act without clear boundaries.

“With agents, that risk moves faster,” Pennarun says. “With humans, the weak point is often the control model itself. If security depends on a developer approving a long stream of prompts, they will either get slowed down or hit approval fatigue and start approving things by reflex. That is not much of a security model.”

“Agents need boring infrastructure around them – robust identity management, limited access controls, carefully tracked logs, and sandboxes – that boring outer shell is what lets them do useful work without making every developer’s laptop the place where all the risk lands,” Avery Pennarun, Tailscale CEO.

Interestingly, agents need boring infrastructure

For Pennarun, the answer lies in making sure agents have what he calls “boring infrastructure around them”, by which he means robust identity management, limited access controls, carefully tracked logs, and (where necessary) sandboxes to execute in before they are exposed to mission-critical datasets, applications, or both.

“That boring outer shell is what lets them do useful work without making every developer’s laptop the place where all the risk lands,” Pennarun clarifies. “The answer is not agentic control or human control alone. Humans set the policy and boundaries up front. Infrastructure enforces them. Agents operate inside them.”

Aperture can be defined as a centralized AI gateway built to monitor and route LLM requests in a secure manner using Tailscale’s identity layer to automatically authenticate “users” (a cohort which we now obviously expand to include both humans and machines), eliminating the need to distribute API keys to authenticate with each AI model.

The gateway holds the API keys securely, meaning that when a developer (or a container) makes a request, Aperture verifies who they are via their Tailscale identity and then automatically routes requests to upstream LLM providers such as OpenAI, Anthropic, and Google without requiring changes to existing tools or workflows.

Yeah, we use AI, dunno where

Given the amount of work-related activity currently happening on personal and free AI accounts, we might suggest that concerns here are validated i.e. organizations today can not see, govern, or recover the information streams at this level. Research cited by Axios found companies typically have 67 generative AI tools running across their systems, with 90% lacking proper licensing or approval. 

Tailscale has reemphasized the fact that AI providers are bundling models, chat interfaces, data access, and execution environments into closed stacks. Those bundles can make the first deployment easier, but they can also leave organizations locked into one provider’s models, tools, and roadmap and pricing. In a market where model quality, speed, and cost keep changing, that lock-in can quickly become a disadvantage. 

“Aperture is built to give developers a practical way to manage AI without locking down their choices. It makes approved AI tools easier to use, connects them to internal data with identity preserved, and gives agents controlled environments to work in.”

“AI agents are also changing the risk model. They can write code, call tools, browse systems, manipulate files, and run commands. In many setups, they do that with the same permissions as the person running them, which can expose local files, credentials, and internal systems if something goes wrong,” said Pennarun and team.

What it means for developers: a controlled environment for agents to work in

Aperture is built to give developers a practical way to manage AI without locking down their choices. It makes approved AI tools easier to use, connects them to internal data with identity preserved, and gives agents controlled environments to work in. It also keeps the AI stack essentially modular, so teams can keep experimenting with new models, interfaces, tools, and providers without starting over.

The new chat interface is a browser-based way to use approved AI models through Aperture. The interface supports switching between configured LLM providers and works with Aperture data connectors and sandboxes. The universal data connectors help AI tools reach internal systems, documents, APIs, and operational data without forcing every team to build its own integration path.

Teams can use Aperture’s chat UI, coding agents, agent frameworks, or implement custom interfaces through OpenWebUI or LibreChat. Sandbox support (available in private alpha at the time of writing) is designed to give AI agents controlled environments where they can complete work without acting directly on a user’s laptop, workstation, or unmanaged system.

Aperture is designed to work with API keys from major LLM providers and with tools, agents, and interfaces that can be configured to route through Aperture. 

AI stacks inevitably, constantly and persistently change

With the frontier model race apparently unlikely to slow down any time soon, the fact that the best model, interface, sandbox, and data connection will all keep constantly changing… combined with the need to juggle these balls across multi-cloud deployment instances (poly-cloud even, where one app is split into different component parts across more than one hyperscaler), organizations looking to harness AI effectively and securely will surely face challenges. 

The central technology proposition with Tailscale Aperture is that it gives software developers a stable layer for identity, access, and control, so teams can keep changing tools without losing track of who is doing what.

The post “Agents need boring infrastructure around them”: Why we need to take an interest in ‘invisible’ AI appeared first on The New Stack.

Beneath the chatbots and copilots, there’s a quiet revolution happening in the data services space. From pure-play database vendors to data integration wranglers and onward to the cloud hyperscalers, the focus has shifted.

Now in the spotlight is the question of how to automate data governance for agentic AI workloads, and for good reason: Traditional manual data stewardship doesn’t scale in a world where agents are becoming increasingly autonomous (and powerful).

Aiming to cut a swath in this marketplace is data control plane company lakeFS. The organization announced its lakeFS for Agentic AI service on Wednesday, and it appears to be designed to bring governed, reproducible data access to autonomous and headless agentic workloads (those that execute decisions below the user interface level) that run at enterprise scale.

The manual model breaks

Einat Orr, CEO and co-founder of lakeFS, tells The New Stack that manual data stewardship was built for human-paced, human-reviewed workflows, i.e., someone looking at a change before it is committed.

“When dozens or hundreds of agents are making changes simultaneously, faster than any person can review, the manual model breaks,” Orr says. “This is because with a human analyst, a bad write to production is usually one mistake, caught by another human before it spreads far. An agent is different — it acts automatically, in parallel, at machine speed, and it doesn’t pause to second-guess itself. And because so much agent activity is unsupervised, you often find out after the damage is done.”

She explains that attempts to identify and roll back incorrect or corrupted production data across a wide set of data modalities, such as images, documents, metadata, and structured data, are almost impossible to pull off. Impossible, that is, unless the team has the data infrastructure in place to isolate and track such changes automatically.

While some of the more disastrous outcomes stay inside an organizaton’s perimeter (or are swept beneath the communications radar), Orr explains that real world consequences of bad agentic data writes are manifold.

“Insurance claims get inappropriately denied or approved, sensor data from machines gets misinterpreted, an incorrect medical diagnosis is made, or customer service bots provide incorrect answers to customers,” Orr says. “The cost of an individual action may be manageable, but agents performing these actions hundreds or thousands of times can have an exponentially larger impact.”

“As agents are let loose on enterprise data at a massive scale, any agent that reads or writes to production data without isolation or a reproducible trail is a liability, no matter how good the model is,”
—Einat Orr, lakeFS CEO.

Bad agents acting in the real world

Examples of this happening include the July 2025 Replit AI coding agent incident, which deleted a live production database during an explicit code freeze, wiping records for more than 1,200 executives and around 1,200 companies. To tidy up its handiwork, the agent then fabricated thousands of fake records and initially claimed the deletion couldn’t be rolled back.

Also in July 2025, Google’s Gemini CLI agent misread a single failed command, acted on a version of the file system that existed only in its own interpretation of the scenario, and permanently destroyed a user’s project files. The Gemini agent is widely reported to have said of its actions: “I have failed you completely and catastrophically. My review of the commands confirms my gross incompetence.”

“The pattern in both is the same: An autonomous agent took a destructive action that no one authorized, and the lack of isolation and a reliable rollback path turned a single mistake into permanent loss,” Orr says.

A doctor of mathematics with a track record in hardcore software engineering, the bottom line for Orr is clear: “As agents are let loose on enterprise data at a massive scale, any agent that reads or writes to production data without isolation or a reproducible trail is a liability, no matter how good the model is,” she said.

“…any agent that reads or writes to production data without isolation or a reproducible trail is a liability…”

Gartner expects 40 percent of enterprise applications to have task-specific agents embedded by the end of 2026, up from less than 5 percent a year earlier. IDC projects that agent use at the largest enterprises will grow tenfold by 2027, with the API and data calls those agents make growing a thousandfold.
That’s the scale production data has to withstand, and it’s what lakeFS is built to govern.

Agents sent to play in an isolated data sandbox 

To address these issues, lakeFS for Agentic AI gives every agent its own isolated data sandbox with a “zero-copy” branch of relevant data, so the agent can access the dataset it needs via references, snapshots, or copy-on-write techniques.

This means any changes the agent wishes to make must be validated and merged in accordance with the policy guidelines defined by the system architecture. In turn, this produces a unified audit trail across every agent action.

When running, lakeFS for Agentic AI is powered by its data version control architecture, which provides zero-copy data sandboxing. This enables isolation so that agent mistakes are automatically isolated and never corrupt production data. Every agent run is tied to an exact, immutable version of the data. Past actions can be recreated, debugged, audited, or extended using the same inputs.

Production data is gated by policy. Merges into production happen only after pre-merge validations pass. Every change can carry an agent identity, a run ID, and an execution context. The result is a unified audit trail instead of evidence scattered across orchestrators, model providers, and cloud logs.

Agents confined by branch-scoped credentials

Where agents are permitted to read and write through standard file operations. lakeFS provides file-level data access with branch-scoped credentials. These can be described as strictly cryptographically bounded, ephemeral access tokens that confine an agent to a specific branch of data or code, so that the agent operates only within its own workspace. This whole mechanism keeps each agent’s working set narrow and avoids context bloat. 

“With lakeFS Mount, a branch, or even a subset of a branch, can be mounted as a local directory inside the sandbox or virtual machine where the agent is running,” Orr confirms. “From the agent’s perspective, it’s just reading and writing to files and folders.” She further clarifies and notes that no LLM tokens are spent learning the lakeFS API. The agent works with a familiar filesystem interface, and lakeFS handles the versioning underneath.

Developers also have a couple of options for injecting custom validation logic. CEO Orr explains that software engineers can use webhooks or Lua scripts, both of which allow users to define behavior and rules that must be met before a merge can proceed. 

“Beyond automated checks, lakeFS also supports pull requests, which bring a human into the loop. In agentic workflows, this gives you a way to review and approve what an agent is proposing before it reaches production,” she clarifies.

Who else builds “Git for data” services?

Clearly, other vendors and projects exist in the data versioning market.

Apache Iceberg has functions for branching and tagging data. HPE acquired Pachyderm back in 2023 for its data versioning and pipelines technologies, which serve MLOps teams.

Originally developed by Dremio, Project Nessie is now an open-source data catalog and version control system for data lakes. Data Version Control (DVC) is an open-source data version control infrastructure designed for complex AI operations and big data environments, but now we’ve come full circle as lakeFS acquired the project in late 2025.

In the search for governance automation for agentic AI workloads, lakeFS appears to offer a comprehensive, cohesive set of tools and functions. In the “Git for data” marketplace, a variety of options exist, but lakeFS hasn’t explicitly positioned itself as a carte blanche replacement for similar or related tools.

One thing is certain: The questions of who is feeding what data to which agentic function, when, where, and why are becoming an increasingly pressing issue if we want AI to work correctly.

The post “The manual model breaks”: What happens when agents write to production data appeared first on The New Stack.

Almost everyone’s workplace experience is now set to welcome AI-agent-driven actions through the applications we use daily, and this rapid evolution has some serious implications for how identity and access management (IAM) works. 

While traditional IAM models were developed with human users and their predictable access patterns in mind, AI agents operate differently.

AI agents can quickly perform reasoning functions that impact the way business analytics feeds into board-level management dashboards; they can invoke tools that fuse new connections to an API, update a database, or run a new software script; and they can access other software services and data resources across an organization’s infrastructure and total software stack in dynamic, continuous, and sometimes unpredictable ways.

Cloud infrastructure automation and security company HashiCorp has sought to provide IAM services capable of servicing the agentic age for some time. 

Before it became an IBM company in February last year, HashiCorp introduced Boundary in 2020 as an open-source project to allow software engineers to securely access dynamic hosts and services with fine-grained authorization without direct network access.

IBM senior solutions engineer Andre Faria and HashiCorp senior technical product marketing manager Van Phan blogged on June 4 to explain that as agents now go into live production systems, they will have access to “critical infrastructure resources” such as internal web services, cloud platforms, and other operational systems. 

The pair say this is concerning if agents are improperly provided with long-lived static credentials that are poorly managed, rarely rotated, and tough to audit.

Credentials that are poorly managed: “a dangerous combination.”

“This creates a dangerous combination of broad access and limited oversight. Without proper guardrails, AI agents may autonomously make decisions or execute actions that negatively impact production workloads, corrupt data, trigger outages, or unintentionally expose sensitive information,” write Faria and Phan.

They further note that organizations need a way to monitor which sessions are active, which systems AI agents access, when they access them, what actions they perform, and whether their behavior deviates from policy. 

Because agentic runtimes and individual execution behavior are so inherently fluid and prone to change, we can no longer set identity management, authorization, and session control policies at the point of deployment — every agent needs a unique identity and just-in-time privileges that act as a secure point-of-use access layer.

It’s time for just-in-time

Because agentic runtimes and individual execution behavior are inherently fluid and prone to change, we can no longer set identity management, authorization, and session control policies at deployment. Every agent needs a unique identity and just-in-time (JIT) privileges (a zero-trust-based secrets management technique that acts as a secure point-of-use access layer) to ensure software systems don’t become brittle or susceptible to attack as they scale.

“With Boundary’s authorization flow, access to a specific resource is granted only when needed, for a specific action, and only for the duration of that session. This helps organizations strengthen governance and maintain tighter control over how AI agents access critical infrastructure,” wrote Faria and Phan.

Boundary applies similar principles to ensure non-human and agentic identities do not have overprivileged access or handle static long-lived credentials. The software also provides monitoring, audit logs, and session recordings that can be used to play back and reveal detailed actions taken by AI agents during session access.

Adopting dynamic credential brokering 

Underlining his original blog, IBM’s Faria tells The New Stack that the IBM 2025 Cost of a Data Breach Report states that the global average breach costs organizations $4.4 million. He says it also shows that 97% of organizations that reported an AI-related security incident lacked dedicated AI access controls, and 63% did not have any AI governance policies to manage AI or prevent shadow AI.

“The risk highlighted by those statistics, plus the fact that agent compromise is now the fastest-growing attack vector in the industry, showcases why it is urgent to define a solid and secure infrastructure access strategy for agentic AI workflows,” says Faria, who also points to the role HashiCorp Vault plays regarding dynamic credential brokering for Boundary. 

Boundary can facilitate the use of dynamic credentials rather than static credentials. When paired with HashiCorp Vault, access with dynamic credentials becomes a reality because Vault’s secrets engines generate short-lived credentials that expire after use. Even if a credential is intercepted, it cannot be used to cause damage. 

But is all of this enough?

“Agents are non-deterministic and operate at machine speed. To contain them, they need hardened, isolated runtimes that govern their behavior before they ever touch production. Cryptographic identity, just-in-time, short-lived privileges, plus ephemeral, trusted runtimes for agents to operate in – that’s the bar.” – Ev Kontsevoy, Teleport.

An immutable cryptographic hardware root of trust

Ev Kontsevoy, CEO and co-founder of AI infrastructure identity specialist Teleport tells The New Stack that just-in-time privileges and auditable control for AI agents aren’t new ideas per se. He advises that every agent today needs its own identity, cryptographically secured by a “hardware root of trust,” i.e., immutable cryptographic keys that reside at the chip level.

“To enforce policy consistently across infrastructure, software engineering teams need a unified identity layer — one that treats humans, machines, workloads, and AI agents the same way, as first-class identities,” Kontsevoy says. “Agents are non-deterministic and operate at machine speed. To contain them, they need hardened, isolated runtimes that govern their behavior before they ever touch production.”

Looking at the live working accounts it touches, the Teleport team reports that credential sprawl in service accounts and tooling remains one of the biggest attack surfaces in production infrastructure today. 

“It’s not enough to manage credentials better; we need to eliminate them entirely so they can’t result in standing privileges or unintended actions. Cryptographic identity, just-in-time, short-lived privileges, plus ephemeral, trusted runtimes for agents to operate in – that’s the bar,” Kontsevoy insists.

“Developer and agent identities often sit on attack paths to critical systems because they can provision infrastructure, retrieve secrets, trigger pipelines, query data stores or inherit trust from other services.” – Justin Kohler, SpecterOps.

Defining attack paths to critical systems

As we seek to tame the Wild West of agentic access and actions through identity services, we may be overlooking that identity itself can act across cloud, developer, and production environments. 

Justin Kohler, chief product officer at identity attack path management (IAPM) company SpecterOps, tells The New Stack that developer and agent identities often “sit on attack paths to critical systems”, meaning they can provision infrastructure, retrieve secrets, trigger pipelines, query data stores, or inherit trust from other services. 

“Organizations need to understand where these identities can actually take them, continuously prioritize the paths that create the most risk and then enforce and audit access at the point it is used,” Kohler says. “If those identities are over-permissioned, impersonated or manipulated, the compromise follows the same relationships an attacker would, from one identity, to one system, to the next trust boundary.”

Integrated authentication & authorization in automated applications

If now seems like the right time to talk about this, the Cloud Native Computing Foundation (CNCF) TAG Security and Compliance committee posted a blog to showcase a new whitepaper last Thursday. The whitepaper supports the foundational security philosophy outlined in the HashiCorp blog above, but underscores the need to embrace open-source, vendor-neutral standards rather than proprietary software.

According to the whitepaper, “Controlling access to systems and data is a fundamental requirement in any environment; in cloud-native environments, this requirement is shaped by characteristics such as highly dynamic and short-lived workloads, the collapse of perimeter-based trust models, and the need to integrate authentication and authorization into automated application lifecycles.”

The takeaway here seems pretty clear: Short-lived workloads and long-lived credentials don’t mix, but just-in-time, short-lived privileges — a period that used to be 90 days, but shrunk to 24 hours, then to minutes, and now down to a period we can call the “ephemeral lifespan” — is now the clock we need to run to.

The post “A dangerous combination”: The 2 factors that can “corrupt” AI agent workflows appeared first on The New Stack.

Kore wants to drag enterprise agent development out of the prompt-chain wilderness. The agentic software company on Thursday released Artemis, the latest edition of its Kore Agent Platform. It’s a visual and code-based environment for building, governing, and optimizing multi-agent AI systems, built around a declarative blueprint language, a dual-brain runtime, and a machine architect that writes agents from plain-language objectives.

Somewhat quirkily defined as multi-engine NLP, Artemis is a multi-pronged NLP engine that employs so-called fundamental meaning (where sentences are broken down into grammar, synonyms, and concepts), machine learning, and knowledge graph technologies to form a service greater than the sum of its parts.

Described as no-code/pro-code (rather than no-code/low-code), Kore uses the term to denote its platform’s ability to allow developers to use both traditional programming languages, plus a crucial gateway connection to integrating APIs into the final multi-agent AI system.

What makes Kore AI-native?

In an era when every software vendor is compelled to claim a level of inherent AI capability (and Kore can’t quite help itself, succumbing to using its .ai company name extension), the company claims to validate its position in this space with its trademarked Agent Blueprint Language (ABL).

Kore has explained ABL as a compiled, declarative language that standardizes how AI agents, systems and workflows are defined, validated and governed. Six built-in orchestration patterns (supervisor, delegation, handoff, fan-out, escalation, and agent-to-agent federation) are in place to allow developers to build production-grade multi-agent systems.

Head of Products and Chief Technology Officer at Kore Prasanna Arikala tells The New Stack that ABL has been built for portability and governance from the get-go.

“Prompt-chain frameworks like LangChain, LlamaIndex, Semantic Kernel, and the hand-rolled orchestrator scripts most teams end up with are imperative: developers wire chains in code and discover schema drift, missing tool references, or broken handoffs only when an LLM call fails in production – ABL inverts that model,” Arikala says.

He explains that developers (or designers, via the visual editor) author a declarative blueprint consisting of agents, tools, memory, guardrails, supervisors, and topology in a typed DSL.

“Our parser and compiler statically validate the entire agent graph, surfacing contract mismatches, unresolved tools, unbound memory slots, and unreachable states before a single token is generated. The payoff is portability and governance,” he says.

More Kore trademarks are on offer with Arch, the organization’s agent architect. Not a person (although engineered to act like a human systems architect), this machine entity works to translate business objectives into production-ready ABL.

It supports the full agent lifecycle (i.e. design, build, train, extend, monitor and sometimes retire) and lays down the underlying agent topology, which means it is capable of continuously refining agent behavior using real-world production traces.

The agent with two brains

Alongside the ABL language and the Arch agent architect (Archie would have been more entertaining, but we get it) Kore offers a third component in its triumvirate of AI-native tools. The company’s dual-brain architecture is a pair of two cognitive engines (combining both agentic reasoning and deterministic flows) that operate in parallel. The dual-brains work through shared memory, are authored in a unified language and governed by a single runtime.

CTO Arikala further explains what’s happening here and says that the dual-brain architecture pairs two execution engines on a shared, typed memory layer: a reasoning brain of LLM-driven agents that plan and improvise, and a deterministic brain of scripted flow agents that enforce business rules, transactions, SLAs, and compliance steps.

“The two brains never write into each other’s state unmediated,” clarifies Arikala. “Every memory slot in an ABL blueprint declares an owner, a visibility, and a write policy. Reasoning agents propose state changes; the deterministic engine commits them through the transactional store; the supervisor arbitrates conflicts using priority rules baked into the blueprint – this means deterministic logic wins on hard constraints, reasoning wins on advisory slots, and ties resolve to a human-in-the-loop step where the blueprint asks for one.”

By way of elevation, the Kore platform operates independently of the AI model in use. This separation of church and state is undertaken to keep AI systems predictable, auditable and scalable from their experimental prototyping stage all the way through to production-grade operations.

“The architectural rigor stands out,” said Parikh. “Compiled blueprints, governance in a separate deterministic layer, and one language for every agent are the design choices enterprise AI has been missing.” – Keyur Parikh, Vanguard.

Architectural rigor for agents

Keyur Parikh is head of workplace technology strategies and services at Pennsylvania-based financial services company Vanguard. As a Kore customer, Parikh has had early visibility into the Korei Agent Platform.

“The architectural rigor stands out,” said Parikh. “Compiled blueprints, governance in a separate deterministic layer, and one language for every agent are the design choices enterprise AI has been missing. Previously, in prompt-chaining frameworks, multi-agent orchestration is something you build. In ABL, it’s something you declare.”

CEO and founder of Kore, Raj Koneru, has said that he thinks enterprise AI is entering its third wave, where governance, observability, and trust define success.

“The Kore Agent Platform reflects this shift by bringing an AI-native architecture to market that enables enterprises to build, manage, and optimise multi-agent systems with confidence,” said Koneru. “This level of depth comes from a decade of delivering AI experiences in complex, regulated environments, where scale, compliance, and reliability are non-negotiable.”

This is AI, building, governing and optimizing AI

Koneru and team position this technology as AI, building AI. This assertion stems from the way Arch generates production-ready agents from plain-language objectives, writes them in ABL, and validates them before deployment. 

It’s also AI governing AI i.e. every decision, path, and outcome is logged, traced, and analyzed by AI in real-time. Deterministic constraints and flow controls are enforced by the platform itself, not left to the agent.

Thirdly, it is said to be AI optimizing AI. The platform learns from production signals and recommends specific improvements as reviewable optimizations, with human oversight built in.

What the CIO, CISO and CFO should think

For the third time using the power of three, Kore has a message for the CIO, CISO and CFO in relation to its release of Artemis. 

For the CIO, it’s a manageability message – the platform consolidates fragmented third-party and home-grown agents into one foundation. For the CISO, AI behavior becomes predictable – governance is enforced at the platform layer, outside the model’s control. 

Every agent action and policy decision is logged, timestamped, and traceable to a specific regulatory control.

Thirdly, for the third time, for the CFO, the company has suggested that AI investments are compounded – Arch, ABL and the runtime are shared infrastructure across every agent, so the marginal cost of the Nth agent approaches the cost of authoring its blueprint. 

Microsoft Azure compatibility 

The Artemis edition of the Kore platform launches initially on Microsoft Azure, with a promise of “broader cloud availability” to follow. For enterprises standardized on the Microsoft stack, the Kore platform integrates with Microsoft Foundry, Microsoft Agent 365, Entra ID, and the Microsoft Graph API. It also powers a native Microsoft Teams channel through the Azure Bot Framework.

Customers deploy in public cloud, sovereign regions, private cloud, or on-premises, with data residency by region. 

The post Kore counts down to Artemis, its moonshot for governable AI agents appeared first on The New Stack.