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.