Building with AI has, until recently, meant calling up someone else’s model. But wiring an app to an API from OpenAI, Anthropic, or Google is a poor fit for government and operators of critical infrastructure. When data legally or operationally cannot leave a secured network, a hosted endpoint in someone else’s cloud is a non-starter, regardless of whether the workload is intelligence analysis, grid operations, or patient records.

“The most revealing aspect here is that Palantir didn’t ship a model, but the apparatus for deploying and owning one.”

That’s the lens through which to read Palantir’s announcement on Monday. The company introduced an “intelligent engine,” built on Nvidia AI and Nemotron open models, for running, customizing, and continuously improving AI inside air-gapped and other sovereign environments while keeping data and model weights in the customer’s hands. The most revealing aspect here is that Palantir didn’t ship a model, but the apparatus for deploying and owning one.

From calling AI to operating it

Most organizations will run a hybrid of hosted and self-hosted models for years, but a second pattern is hardening alongside this workflow. Rather than treating the model as an external service, the application communicates with an internal AI platform that routes requests to one or more models running on the organization’s GPUs. Data never leaves the perimeter, which hands security and compliance teams direct control over governance, auditing, and retention.

So we’re seeing the question shift from which model we should call to which models we should own and operate ourselves. And, just as importantly, what does it cost us to run them?

What’s actually in the box

This is where the announcement gets more concrete than the press release lets on, and where it’s worth knowing what Nemotron is.

Nemotron is Nvidia’s family of open-weight models, released in 2026 in three sizes — Nano (~31.6B parameters), Super (120B), and Ultra (550B). All three use a hybrid Mamba-Transformer mixture-of-experts design that activates only about a tenth of their parameters per token, so they run far cheaper than their headline sizes suggest, with context windows up to a million tokens.

Nvidia publishes the weights, training data, and recipes under a permissive license, and the models are deployable via open runtimes such as vLLM, SGLang, and llama.cpp, Ollama — or as Nvidia NIM microservices, the containerized, TensorRT-LLM-optimized path that ships inside the Nvidia AI Enterprise suite. Palantir, notably, was already on Nvidia’s published list of early Nemotron adopters, so this is less a cold start than a formalization.

An important note for builders weighing the move: Nemotron doesn’t top the raw-capability leaderboards; open families like DeepSeek, Qwen, and Kimi K2 generally score higher on absolute benchmarks. Nemotron’s pitch is efficiency on Nvidia silicon and genuine openness, which is exactly the axis that matters when the deployment target is your own hardware behind an air gap rather than a hosted endpoint.

Palantir’s contribution is the layer that turns “download the weights” into “run this in a classified environment and keep improving it.” The company describes three engineering surfaces: deployment (getting base and customized models into air-gapped and classified networks), context (prompts, workflow structure, and model behavior in production), and model (changing the weights themselves on proprietary data and mission outcomes). Underneath sits Palantir’s existing stack — AIP, Ontology, Foundry, and Apollo — handling data authorization, enforced isolation, and auditability.

The “self-improving” claim is a telemetry loop: The engine captures usage and trace data, then uses it to post-train and align the model toward the tasks where it adds value. This is the part that demands the most operational discipline, because a feedback loop with no evaluation harness is a recipe to drift.

The catch: Owning the stack means owning the stack

The sovereignty pitch is genuinely attractive, and it has a price tag the announcement doesn’t dwell on. Owning your models means owning everything around them. That’s GPU capital expenditure and the power and cooling to match; an inference stack you keep patched and performant; a model lifecycle — fine-tuning, evaluation, rollback — that you staff and run yourself; and a security burden that doesn’t go away just because the box is disconnected.

“Owning your models means owning everything around them.”

Ultra-class models, in particular, are not modest: running a 550B model, even at ~10% activation, requires multi-GPU server nodes, not a spare rack.

For an agency that legally cannot use a hosted API, that cost is simply the cost of doing the work, and the calculus is easy. For a commercial enterprise that could use a hosted endpoint, the math is a real trade — control and data residency on one side, capex and operational headcount on the other. The right answer is workload-specific, and anyone selling it as obvious is selling something.

Read the announcement for what it is

It’s also worth being clear about what this news is not. It’s a packaging-and-positioning announcement between two companies with aligned incentives: NVIDIA sells more GPUs and more AI Enterprise licenses, Palantir sells more platform, and “sovereign AI” is the banner both have been marching under all year. There’s no named agency customer, no contract value, and no benchmarks. Palantir CEO Alex Karp says many U.S. clients already use these models and frames the appeal as avoiding proprietary insight being baked into the weights of closed models; NVIDIA’s Jensen Huang calls open source foundational to national security. Both quotes are doing strategic work. The substance here is the integration and the go-to-market, not a technical breakthrough.

Why it still matters

Strip away the government framing, and the same pattern is spreading through finance, healthcare, manufacturing — anywhere data residency and compliance are design constraints rather than afterthoughts. The reasons it’s newly practical are concrete: open models good enough for production, MoE architectures that cut the compute bill, and an inference tooling layer (NIM, TensorRT-LLM, vLLM) mature enough that air-gapped serving is an engineering project rather than a research one.

“The model becomes a component. The engine becomes the product.”

The takeaway here for developers is that as open models converge on “good enough,” differentiation shifts to everything around them — deployment, routing, governance, evaluation, security, and lifecycle management. The model becomes a component. The engine becomes the product.

Most organizations will keep calling hosted APIs for plenty of work. But for a growing set of them, the interesting question is how much of the stack they’re prepared to own — and whether they’ve counted the cost of owning it.

The post Palantir and Nvidia want to change who owns government AI appeared first on The New Stack.

Workday, the payroll and HR data platform, has been pursuing AI and agents for a while, but while other businesses may allow a little room for error, getting a payroll run in Workday 99% right is not exactly good enough.

Gabe Monroy, Workday’s chief technology officer, tells The New Stack that enterprise AI has to clear this bar before anyone will let it near their HR and finance data.

“There aren’t many systems that are more critical — or less forgiving — than ones that are dealing with people and money,” he says. There’s no tolerance for “well, it works most of the time,” Monroy says in an interview.

At its DevCon developer conference in early June, Workday laid out its plans to clear this correctness bar. The company introduced Agent-Ready Tools, a set of connectors that let agents act across the platform over the Model Context Protocol (MCP), a Developer Agent that lets people build apps and agents on Workday in plain language, and Agent Passport, which tests and verifies agents before they go into production and keeps monitoring them after, with Cisco as the first attestation partner.

Guardrails belong in the inference engine

Monroy spent most of his career in infrastructure and the developer space: at Deis, Microsoft, DigitalOcean, and, most recently, Google. At Google, he focused on building infrastructure for large AI labs to run inference at scale. For someone so focused on infrastructure, coming to Workday might seem a bit like an odd move, but Monroy argues that, at this point, LLM safety is — or at least should be — part of the core infrastructure for enterprises.

“The stakes are higher … in the world of people and money”

“The stakes are higher in the world of Workday and in the world of people and money, and that’s something that I was really excited about tackling at Workday specifically — and I do look at it as a core infrastructure,” he says. “A lot of what I’ve been doing in my recent past has been building infrastructure for large AI labs to do inferencing at scale, and what you pick up pretty quickly is that inferencing is probabilistic.

“[Inferencing] involves prefill and decode, and a whole bunch of really technical machinery in place to stream tokens out to end users, but what is nowhere in that stack today is the concept of native LLM-level enforced guardrails — guardrails that are part of the core inference.”

In his view, making it safe for enterprises to operate inference at scale has to be done at the inference engine layer. Agent gateways and similar add-ons that wrap the model from the outside sit at the wrong layer, he argues.

For a system of record like Workday, the system must strictly enforce guardrails on who the user is, what their budget authority is, and where they sit in the org chart. Those constraints, Monroy says, can be wired deep into the inference rather than checked after the fact. “These are things that we have the opportunity to wire deeply into the inferences at a very, very low level, in a way that produces much safer outcomes,” he says.

Workday’s recent acquisition of Pipedream partially plays into this. With Pipedream, an agent can reach out to third-party systems outside Workday to, for example, pull a policy document from Google Drive, and the platform can then verify that this specific agent has all necessary access rights to do so.

“Bring it to our shop”

All of those agents need to be managed, of course, and while many SaaS companies are currently building out their own agent platforms and agent orchestration services, seemingly all offering the same services, Monroy argues that orchestration should happen close to the data sources.

“If you’re trying to run an agent interaction that is integrating with people and money, that orchestration loop should probably happen closer to Workday, ideally on the Workday,” he says. “I do think there is something to be said for inference engines having proximity to the underlying system, because when it comes to a low-level inference engine and runtime perspective, there are some differentiated things you can do at the inference engine level that are only possible due to proximity to.”

“I do think there is something to be said for inference engines having proximity to the underlying system…”

He likened it to car repair. If somebody hands you a toolbox, you may or may not be able to fix your car’s problem. “Maybe you’ll get the outcome, but I tell you what, if you really want your car repair done right, bring it to our shop. We got the hydraulic lift, we got the trained engineers who know how to do this stuff, and we got the tools — but our tools are the best in the industry.”

For the part of an agent’s orchestration loop that has to run next to HR and finance data, “you really should be running that in our shop.”

For more general-purpose workflows, though, he believes there is room for general-purpose platforms. Not everything needs to run on Workday, after all, and Workday does offer MCP servers that third-party tools can tap into to access its data and tools as well.

To some degree, every system-of-record vendor is making some version of the proximity-and-context case right now. Owning the context for AI agents to work with is a major moat for these companies, after all, even as APIs and MCP servers allow agents to pull in data across vendors.

Meanwhile, there is also a group of other companies positioning themselves as neutral parties benefiting from the fact that these other vendors are now opening their platforms to third-party agents. It seems unlikely that, in the long run, enterprises will want to manage multiple agent platforms, but at this point, it is still far from clear in which direction this pendulum will swing.

Happy to lose the tooling fight

If proximity is where Workday thinks it can win, there is one area where the company doesn’t want to compete: developer tools.

“We’re not going to differentiate Workday on building better tools for developers,” Monroy says. “We’re going to differentiate on safety, on trust, on the inference engine.” It’s telling that the demos at DevCon ran on Claude Code, Cursor, OpenAI’s Codex, and Google’s Antigravity rather than on anything Workday-branded. “On the tooling front, I’m happy to have Claude Code and Codex and others,” he says.

It’s no secret that developer loyalty to AI tools doesn’t really exist at this point. Developers definitely don’t want a one-off tool from a single vendor, and Monroy notes that he isn’t going to ask them to adopt one. Instead, Workday wants to own skills, which he calls “the underlying lingua franca that we’re using to converge across the system.”

Workday is happy to be the system of record for its vertical and to let others fight over the tools.

The post “Bring it to our shop”: Workday’s pitch for keeping AI agents close to your most valuable data appeared first on The New Stack.

Okta has made its AI agent governance platform generally available for FedRAMP- and HIPAA-regulated environments, becoming what it claims is the first independent identity platform to extend AI agent lifecycle management inside the compliance boundaries federal agencies and healthcare organizations already trust.

The product, Okta for AI Agents – Core, elevates AI agents to first-class identities managed alongside human and machine workforces. This is a shift from the practice of treating agents as static service accounts or hardcoded API keys. The launch comes as federal agencies face mounting pressure from the recent executive order on AI innovation and security, which directs agencies to deploy AI agents and mandates that they secure them.

“The message to agencies is clear: Adopt AI aggressively, but secure it as you go,” writes Amy Johanek, Okta’s VP of Federal, in a blog post. “That puts identity at the center of the mission.”

“The fastest-growing class of NHI yet, and the hardest to see.”

Johanek also writes that AI agents are “the fastest-growing class of NHI [non-human identity] yet, and the hardest to see.” Anyone can spin one up, agents can spawn additional agents, and each connects across apps, APIs, SaaS tools, MCP servers, and data systems with little visibility, she says.

For organizations under mandates to harden systems and defend against AI-enabled criminal access, an unmanaged agent is not just an operational gap; it is more like an unguarded door, the company says.

“An unmanaged agent is not just an operational gap; it is more like an unguarded door.”

Johanek laid out four specific risks facing agencies running ungoverned agents: compliance violations when agents touch data outside authorized boundaries; compounding breach risk, where a single compromised credential doesn’t grant access to one system but to everything an agent can reach before a human can intervene; failed audits when agents run as orphaned accounts with no owner or evidence trail; and stalled AI adoption when delay becomes the only compliant option.

Moreover, the platform is organized around three governance questions: Where agents operate, what resources they can access, and what actions they’re authorized to take. Agents are registered in Okta’s Universal Directory inside an organization’s regulated cell, each assigned a unique identity and a named human owner, Johanek says. Every agent becomes a known, owned, first-class identity inside the environment, whether it came from a third-party platform or the organization’s own developers.

The platform replaces static credentials with scoped, short-lived tokens enforced at runtime. Least privilege is applied across authorization servers, third-party applications, and MCP servers. The governance layer mirrors existing federal workforce identity controls: access certifications, entitlement reviews, time-bound permissions, and a full audit logging stream that can be streamed to SIEM platforms for U.S. Government Accountability Office reporting requirements, Johanek says.

The offering also provides a kill switch

The offering also provides a kill switch. When an agent deviates from its intended mission or unexpectedly accesses sensitive data, security teams have a real-time mechanism to contain the risk before it escalates into a larger incident.

Johanek says she sees the offering as continuity rather than new infrastructure.  Agencies already trust Okta to manage human identities. Okta Identity Governance achieved FedRAMP High authorization earlier this year; bringing agents into that same identity fabric, she writes, is the natural next step, not a parallel system to build and defend.

However, there is one caveat: Okta for AI Agents – Core is not authorized in Okta for US Military cells.

The post Okta is the first to bring AI agent governance inside FedRAMP boundaries appeared first on The New Stack.

Over the past few months, four AI giants quietly rebuilt the same thing at once: AWS, Microsoft, Google, and Anthropic each shipped agent runtime updates that point to the same architectural shift.

Microsoft rebuilt its Foundry-hosted agents in April around per-session isolation. Anthropic’s Managed Agents virtualize the agent into a session, a harness, and a sandbox. AWS routes each session to its own microVM, and Google isolates agent code execution in a dedicated sandbox. The common pattern is not another model feature or developer tool. It is a move from request-level load balancing to session-aware execution.

This matters because enterprise agents are not ordinary API calls. They are long-running, stateful, tool-using processes that often run code influenced by user input. At its core, the agent runtime is becoming a control plane for state, identity, isolation, and lifecycle, and the unit it schedules has moved from the individual request to the agent session. The convergence across four platforms suggests session-aware execution is becoming a baseline requirement for production-grade agents.

The traditional cloud scaling model

To appreciate why this matters, it helps to start with what the traditional model got right. NGINX and HAProxy tiers typically sit in front of a pool of workers and route each incoming request to the next available backend. The state is deliberately kept elsewhere, in Redis or a database, so any worker can serve any request. That externalization of state is what enables elastic scaling, fault tolerance, and infrastructure replacement without disrupting the application. Sticky sessions were available, but enterprises treated them as an exception for stateful applications rather than the default.

The model rests on two assumptions: that requests do not depend on one another and that any backend can serve any request. For web APIs and microservices, those assumptions held for nearly two decades and enabled the scaling of the largest systems ever built. Agents challenge both at once, which is why conventional load balancing alone is no longer sufficient.

Why agents break the model

Agents pose two distinct challenges: preserving conversational state across turns and enforcing a security boundary strong enough to withstand untrusted code. Only the first can be addressed by routing alone.

Why can the agent state not be pooled?

Imagine an enterprise support agent processing a refund. It reads the order, calls a tool, and then waits for the model. The next turn asks a clarifying question. If that turn is routed to a different replica without access to the prior context, the agent loses the state it needs to finish the workflow.

The load balancer starts to behave less like a traffic distributor and more like a session router.

The industry already has a name for the workaround, session affinity, and it already concedes the cost. Load-balancing approaches increasingly rely on consistent hashing, using a conversation identifier to keep related steps in a warm state. In plain English, the load balancer starts to behave less like a traffic distributor and more like a session router.

Why the trust boundary forces isolation

The second challenge is harder because it turns on isolation rather than on the state alone. An agent can execute model-generated code shaped by user input, so the backend must be treated as a security boundary rather than a generic compute target. A shared kernel does not give untrusted, agent-generated code the tenant isolation that enterprise security teams require. Session affinity can preserve routing continuity, but it does not by itself provide per-tenant isolation for untrusted execution. For platform and security teams, that is the line where a tuned load balancer is no longer enough.

This is not a theoretical concern. When Asana disclosed a flaw in its MCP server in June 2025, the server had been live since May 1, a window of about five weeks. A tenant-isolation check failed, and around 1,000 organizations could see project data belonging to other customers. Based on the reported details, security researchers traced the issue to a server that validated the user but did not consistently enforce the agent and tenant context behind cached responses. No external attacker was involved, and data still crossed organizational boundaries. The incident shows why user identity, agent context, and session state must be consistently bound together.

The session as a unit of compute

Once that binding becomes a correctness and security requirement, the session becomes the unit that the platform schedules. The clearest evidence is in the lifecycle. A session now has a state it never had before. AWS documents that an AgentCore session remains Active while it processes work and sits Idle when it is provisioned but waiting. It reaches Terminated after a 15-minute idle timeout or an 8-hour maximum lifetime. That is the lifecycle of a long-running execution environment, not of a short-lived HTTP request.

The economics follow the same logic. When billing is tied to active sessions, concurrency, idle time, and agent sizing become the cost drivers rather than request volume. That puts a new line item in front of platform teams and finance. The better mental model is no longer a traditional load balancer. It is closer to a virtual actor runtime, where an addressable identity is instantiated on demand, kept active while it is needed, and deactivated when idle, with one live instance per key.

Four approaches to the same shift

All four platforms are moving away from treating stateful, untrusted agent work as ordinary load-balanced traffic. The key difference is the compute primitive each provider chooses for the isolated execution environment.

AWS AgentCore is the most opinionated of the four. Each session gets a dedicated Firecracker microVM with isolated compute, memory, and filesystem, and a request carrying the same runtimeSessionId is routed back to that microVM through a session header. When the session ends, the microVM is terminated and its memory sanitized.

The agents hosted on Microsoft Foundry implement a similar model through a different set of primitives. The platform creates a per-session VM-isolated sandbox on demand, runs it, and tears it down at session end, with no replica count and no warm pool to size. Each agent gets a dedicated Microsoft Entra identity, and sessions run a 15-minute idle timeout against a 30-day maximum lifetime.

Google Agent Engine is the most instructive hybrid. Its runtime keeps request scaling within the reasoning loop, a managed environment with configurable minimum and maximum instance counts, and a container_concurrency that defaults to 9. Even where Google retains request scaling for the loop, it separates untrusted code execution into an isolated Code Execution sandbox and externalizes conversation state to Sessions and Memory Bank. The provider that kept the load balancer in the loop still would not point it at stateful untrusted work.

Anthropic provides the clearest decomposition of the architecture. Managed Agents virtualize the agent into three components: a session that logs everything that happens, a harness that runs the loop and routes tool calls, and a sandbox where code runs. The harness becomes a near-stateless control plane, while the sandbox becomes a callable, rebuildable resource. The Cloudflare integration shows that the substrate can be decoupled. The agent loop runs on Anthropic while each tool call runs in a Cloudflare sandbox, which can be a full microVM or a lighter V8 isolate.

The four platforms converge on the routing and lifecycle model and diverge on the execution substrate, as the table shows.

Platform	Compute primitive per session	What it means for an enterprise buyer
AWS AgentCore	Dedicated Firecracker microVM, routed by session ID, 8-hour ceiling	The most opinionated answer, with isolation and routing fused at the microVM
Azure Foundry hosted agents	Per-session VM-isolated sandbox, dedicated Entra identity, 30-day max	Identity-led isolation suited to longer multi-day workloads
Google Agent Engine	Request-scaled loop plus a separate isolated code-execution sandbox	A hybrid that load-balances the reasoning and isolates the execution
Anthropic Managed Agents	Decoupled harness and sandbox, microVM or V8 isolate behind the loop	The most portable, with the substrate treated as a swappable layer

No single architecture is the right answer for every enterprise workload. A multi-day research agent fits Azure’s longer-lived session, a code-heavy agent needs microVM-grade isolation, and high-volume automation favors a lighter isolate. Many enterprise platforms will end up combining more than one of these patterns.

The binding the application still owns

The platform can isolate and route a session, but it does not know which human owns it. AgentCore explicitly states that it does not enforce session-to-user mappings, so the application backend must maintain the relationship between users and their session IDs and set per-user session limits. This is why the Asana incident is relevant to enterprise architecture.

Isolation was maintained while the user-to-session binding broke.

In that case, isolation was maintained while the user-to-session binding broke. The platform solves isolation and lifecycle, and it hands back identity mapping, authorization, and tenant context to the application. For an enterprise buyer, the key question is who owns that binding and how it is tested under concurrent, multi-tenant load.

How this differs from sticky sessions

A reasonable objection is that this appears to be sticky sessions combined with autoscaling on a microVM substrate. The distinction is worth drawing out. Traditional sticky sessions are usually performance optimizations, whereas in an agent runtime, session binding becomes a correctness and security requirement. Traditional load balancers route traffic to existing backends and do not own the lifecycle of the execution environment.

The new control plane provisions an environment when it first sees a session key, routes work to it, and tears it down after idle or lifetime limits. The primitive underneath is genuinely old, and its age is what makes the move legible. AWS open-sourced Firecracker at re:Invent in 2018 to pair VM-grade isolation with container speed. I covered it for The New Stack then, and ran more than a hundred microVMs on a single laptop to see that trade firsthand. The same microVM now powers Lambda and Fargate across trillions of executions a month. This is how cloud architecture tends to evolve, with existing primitives recombined around a new unit of abstraction.

The agent session is becoming the operational unit of enterprise AI infrastructure.

In summary, the important shift is not that cloud providers have found a better load balancer for agents. It is that the agent session is becoming the operational unit of enterprise AI infrastructure. Traditional load balancing routed independent requests to interchangeable workers. A session-aware runtime routes work to an isolated environment, preserves state across turns, and owns the lifecycle of the execution context. The dispatch layer did not disappear when agents arrived. It became session-aware, stateful, and lifecycle-aware, making it a control plane rather than a conventional load balancer.

Three practical questions will shape what comes next, and enterprises will need to evaluate each. The economics of per-session billing will decide how costs scale with concurrency. The open-source effort to rebuild this routing model on Kubernetes will determine its portability. The argument between microVMs and lighter isolates will decide the trade-off between isolation and density. For enterprises building agents, a runtime that owns isolation, routing, and lifecycle turns background plumbing into a deliberate architectural choice. It gives platform, security, and operations teams a foundation they can standardize on rather than rebuild for every workload.

The post AWS, Microsoft, and Google agree the session is the new unit of compute. They disagree on how to isolate it. appeared first on The New Stack.

Many agentic projects can sail through development just fine. Then they hit security review — and that’s where things can grind to a halt. Unclear identity models and overly broad permissions quickly become blockers.

You’ve probably seen this play out: A customer support agent is working well; it triages tickets and processes refunds, handles the whole workflow without a hitch. Then security asks a simple question: Under whose identity is this running? The answer stops the process cold: It’s a shared account with broad permission, no clear ownership, no audit trail, and no least-privilege controls in sight.

The root issue isn’t complicated. It’s undefined identity and poorly scoped permissions. And that challenge is accelerating fast. Research from the 2026 Tech Leader Study, conducted with Oxford Economics and IBM, shows surveyed enterprises expect to deploy an average of 1,661 AI agents, a 38% increase from today. Each new agent introduces another identity to secure, and without clear boundaries, the problem compounds quickly. 

As a result, many agentic systems focus on what agents can do without defining what they should do, or under whose authority. Agents also don’t hold a fixed set of permissions. They request access, call new tools, and assume roles as they work, so access paths compound in ways no one explicitly granted or reviewed. Without a verifiable identity, there’s no accountability, making least-privilege enforcement, traceability and incident response difficult.

“Each new agent introduces another identity to secure, and without clear boundaries, the problem compounds quickly.”

To address these gaps, this guide is written for developers, architects and DevOps engineers building agentic systems — and for the IT leaders responsible for approving them.

The four identity decisions every agentic system must make

Identity decisions can’t be treated as an afterthought. Identity shapes how agents authenticate, what they can access, and how their actions are controlled and audited over time. Get it wrong early, and you’re building on a shaky foundation.

Here are the four decisions that matter most:

Workload identity vs. shared service accounts 

Shared service accounts are easy, and that’s exactly what makes them dangerous. When multiple agents act under a single identity, it becomes hard to tell what happened or what went wrong after the fact. If an account is leaked or misused, everything it touched is exposed. 

“Shared service accounts are easy, and that’s exactly what makes them dangerous.”

Workload identity assigns each agent its own identity. Permissions stay scoped, and actions are attributable. It requires more setup but creates isolation and auditability.

Static API keys vs. short-lived credentials

Static API keys tend to stick around forever. They get hardcoded into apps, passed around between systems, and rarely rotated — which makes them a persistent vulnerability waiting to be exploited. 

Short-lived credentials work differently. They’re issued on demand, scoped to a specific task, and expire automatically. In practice, this often relies on identity federation (for example, using OIDC tokens) combined with systems that can issue dynamic credentials at runtime, rather than storing long-lived secrets in code or configuration

Direct credential handoff vs. brokered session access

Handing credentials directly to an agent is simple. It’s also opaque. You don’t have a natural point to evaluate policy or understand what’s happening in real time. 

Brokered access introduces a control point into the flow. Requests go through a broker, policies are evaluated in real time, and temporary credentials are issued per session. It adds infrastructure, but restores visibility and policy enforcement. 

Fragmented logging vs. full identity lineage

Most systems log what happened. Far fewer capture who initiated it or how an action propagated through a chain of agents and services. 

Full identity lineage connects every step. You can trace an operation from triggers to outcomes, which can make debugging faster and enable more credible incident response. The catch is that this requires consistent identity propagation and structured logging from the beginning—it’s hard to retrofit.

When these tradeoffs become real risks

These aren’t abstract architectural preferences. They show up as concrete vulnerabilities.  

Nightfall AI reports that organizations expose nearly 350 secrets per 100 employees each year, with 35% of exposed API keys still active. Combine that with persistent credentials and shared identities, and the potential blast radius grows fast. 

The pattern is consistent: shared accounts and long-lived keys are faster to build but harder to secure. Workload identity and short-lived credentials require more upfront investment but can deliver more security over time.

Debugging breaches by feel

Think about what happens when an agent running on a shared account with a long-lived key suddenly spikes its data access. Was it a bug? A breach? Routine behavior? Hard to say. Revoking the key might stop the issue, but it could also break a half-dozen unrelated workflows in the process. You’re now debugging by feel. 

Shortcuts reduce friction at the start and accumulate risk over time. 

Standardize identity at the platform layer

The answer isn’t to rebuild authentication, authorization and auditing from scratch for every agent you ship. That’s not scalable. 

Instead, standardize identity at the platform layer—centralized identity providers, policy engines and a credential broker to enforce secure defaults and make compliance straightforward rather than a constant negotiation. 

“Shortcuts reduce friction at the start and accumulate risk over time.”

Agentic AI works in production when identity is designed up front and enforced at runtime, rather than assumed from a prior login. When projects are treated as an afterthought, they stall. When it’s built in deliberately, agents can operate with the control that production environments demand. 

IBM supports this through an integrated identity-first approach that spans secrets management, secured access, and identity governance—helping organizations scale agentic systems securely without adding operational complexity. 

Learn how IBM approaches identity-first security for agentic systems

© Copyright IBM Corporation 2026. IBM and the IBM logo are trademarks of IBM Corp., registered in many jurisdictions worldwide. Examples presented are illustrative only. Actual results will vary based on client configurations and conditions; therefore, general expected results cannot be provided.

The post The AI agent identity problem nobody’s talking about appeared first on The New Stack.

We’re more than 20 years past the launch of AWS, the starter gun for the shift of compute and storage from on-prem racks to the cloud. 

The rapid growth of AWS and competing services like Azure and Google Cloud underscores how many companies have made the jump from controlling their own infrastructure to renting capacity from hyperscale public clouds.

For the major providers, the public cloud has proved an incredible business. Amazon’s cloud service generated nearly 60% of its first-quarter operating profit, for example. For cloud customers, however, the tides may be turning.

Think back to the early days of the public cloud. Azure and AWS scrapped for market share, offering price cuts to entice workloads to their centralized silicon. The situation has evolved over the ensuing decades. Today, cloud costs are material and rising, prompting some companies to question whether being cloud-first is the best path forward.

Cloud bills are expanding due to increased usage of hyperscaler infrastructure, yes, but also because many customers today use the cloud for everything, rather than for what it is best suited for.

n the latest episode of The New Stack podcast, Byron Dill, Director of Solutions Engineering at Summit, tells us that shared compute and storage have their place in the modern IT mix, but that many companies would do well to segment their workloads and move some of that work back on-prem. (Think lower costs and simpler management of high-risk data.)

The argument echoes what we’ve seen recently in the AI realm. Many companies quickly adopted AI technology, only to be surprised later by the bills they incurred. The public cloud is a similar frog-boiler, albeit on a slightly longer timeframe.

In both cases — AI and the public cloud — companies have learned that a product once pitched as a way to reduce spend can evolve into the opposite without careful management. Summit, which offers managed private clouds to enterprise customers, thinks that some corporate workloads should be removed from the cloud and moved in-house.

What will that cost? How long does it take to move? And which industries are most primed to benefit from their own private cloud? We get into it all in this episode.

The post Public cloud vs. on-prem: Summit on where each workload belongs appeared first on The New Stack.