The Ecosystem Forming Around AI in Production Infrastructure

Last week we shared what we saw at Datadog DASH 2026. The short version: AI has moved from research budgets into platform engineering, and the buyer is now asking the same questions about model calls that they have asked about databases and APIs for the last decade.

This post is the companion piece. It goes deeper into the ecosystem forming around that shift, the partner companies shaping how production AI actually runs, and where Eden fits at the runtime control layer. A separate post coming later this week covers the AI gateway category specifically, including how Eden sits relative to LiteLLM, the newly acquired Portkey, Cloudflare, Kong, and the rest of the field.

A few things have become clear over the last six months, and Datadog's DASH put a sharp point on all of them.

The first is that the gateway layer is no longer optional. A recent engineering reference put it cleanly: the LLM gateway has "graduated from a convenience to critical AI infrastructure." That is not marketing language. It is what platform teams are actually telling each other in private. Once you have multiple models, multiple agents, and multiple teams calling AI services, you cannot govern that traffic from inside application code.

The second is that prompt injection is now the central security problem for AI in production. OWASP ranks it as LLM01 for the third year running. Anthropic's Claude Opus 4.5 brought adversarial attack success rates down to roughly 1%, which is the best in the field, and Anthropic itself says 1% still represents meaningful risk at scale. The conclusion most teams have reached is that model-level defenses are necessary but not sufficient, and the architectural controls have to live at the gateway and tool boundary.

The third is that organizations are behind. Kiteworks' 2026 Data Security, Compliance & Risk Forecast surveyed 225 enterprises and found that 41 to 44 percent had not implemented basic governance controls like human-in-the-loop oversight for AI agents, and 55 to 63 percent lacked purpose binding, kill switches, or network isolation. The investment in watching agents has run ahead of the investment in stopping them.

All three of these point to the same architectural answer. Production AI needs a runtime control plane. Datadog is building observability and detection at that layer. Eden is building enforcement and policy at that layer. The partner ecosystem at DASH is building the catalog, secrets, resilience, eval, and supply-chain pieces that compose with both.

Here is how that composition works.

How Eden Fits With Datadog

The simplest way we describe the relationship with Datadog is this: observability tells you what happened. Eden decides what happens next.

That distinction matters more in 2026 than it did a year ago because Datadog itself is moving from passive observation to active intervention. The DASH 2026 announcement included over 100 features, and the headline products were unambiguously about closing the loop: Bits AI SRE that investigates and remediates, Bits Code that proposes fixes, Bits Release that validates deployments, Bits Testing that generates synthetic tests, and AI Guard that watches for prompt injection and agent poisoning attempts. The pattern is clear. Observability platforms are building agents that act, not just dashboards that report.

Eden's role is complementary. Datadog watches traffic from the outside. Eden sits inline and enforces decisions on the traffic itself: routing across providers, capping cost per workflow, masking sensitive data before it leaves the VPC, blocking unauthorized model calls, enforcing sanctioned model lists, mirroring traffic during migrations, and producing audit trails as a property of being in the path. AI Guard can detect a prompt injection attempt. Eden can refuse the credential, block the tool call, or quarantine the request before the model ever sees it.

The two layers compose cleanly because Eden exports first-party telemetry into Datadog. Every request Eden parses produces structured metrics, traces, and logs that flow into the dashboards platform teams already built. Datadog gets a richer picture of AI traffic because Eden is parsing it at the protocol level, including OpenAI-compatible payloads, model identifiers, token counts, routing decisions, cost attribution, and policy outcomes. The customer gets one workflow.

The new Bring Your Own Cloud Logs option announced at DASH makes this even cleaner for regulated environments. Eden already runs in the customer's VPC. With BYOC Logs, the telemetry Eden emits can stay inside the customer's storage while still being indexed and queried through Datadog. The data residency story is now defensible end to end.

The four-party partnership we are running with Microsoft, Redis, and Datadog around the Azure Cache for Redis migration is the clearest production example of how this composes. Eden runs the migration. Datadog provides the observability layer. Redis built the destination. Microsoft is making it available through the Azure Marketplace. One deployment, four organizations coordinated.

The Partner Ecosystem in Depth

The companies on the floor at DASH were not selling overlapping products. They were each solving a different slice of the same underlying problem: AI is now production infrastructure, and production infrastructure needs governance.

Here is how the major categories compose with Eden.

Internal developer portals. Port, Cortex, Backstage, OpsLevel, and Atlassian Compass are all in this category, with Port now extending into AI agent orchestration through their Context Lake layer. The pattern across all of them is the same: models, routes, agents, and cost data become first-class catalog entries the same way services and pipelines are today. Eden plugs in cleanly here. Every endpoint, model, and route Eden manages can be surfaced as a catalog entry with live cost, latency, policy state, and audit history attached. A platform engineer looking at the catalog should be able to see which agents are using which models, what they cost last week, who owns them, and whether they are inside sanctioned policy. Eden produces the data. The portal makes it browsable.

Secrets management. Doppler is positioning credential isolation as the structural defense against prompt injection, and we agree. The same logic applies to HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, and Infisical. The pattern is consistent: if the agent describes intent and credentials get attached at the gateway, secrets never enter the model context. This is the only architectural defense that actually holds when a model is compromised by indirect injection, because the model never had the credential in the first place. Eden enforces credential isolation at the request layer. A secrets manager is the natural upstream source. The agent says "I need to query the customer database." Eden resolves that to a scoped credential, attaches it at the proxy, executes the query, and returns the result. The model sees structured intent and structured output. It never sees the credential.

Deterministic simulation and autonomous testing. Antithesis is the sharpest answer we have seen to a question every serious team eventually asks: how do you find the bugs your test suite was never going to catch? OpenAI has had multi-hour outages. Anthropic has degraded availability. Provider failures, race conditions, and rare state transitions are real failure modes now, and unit tests do not surface them. Antithesis runs your system inside a deterministic hypervisor and autonomously explores the state space, finding the failure paths that production would eventually find for you. Eden is the layer that enforces fallback, retry, and circuit breaking at request time. Antithesis is the layer that proves those paths actually hold under pressure. The composition is straightforward: run Eden inside the simulator, let Antithesis find the conditions where routing breaks, and feed the findings back into policy before the bug ships.

LLM observability, eval, and tracing. LangSmith, Helicone, Langfuse, Maxim, and Arize Phoenix are all building variants of this. The common thread is understanding what the model produced, why it produced that, and whether the output was correct. This sits alongside Eden rather than competing with it. Eden governs the request. The eval layer helps you understand the response. In practice, Eden's per-request telemetry is what gets piped into these tools so the eval traces have full context: which model was called, what policy was in effect, what the routing decision was, what the cost attribution looked like. The two layers reinforce each other.

Performance optimization. Akamas was on the floor with a clear pitch: turn Datadog telemetry into autonomous, continuous optimization decisions for Kubernetes, JVM, Node.js, and cloud workloads. This is the kind of partner that becomes more valuable when Eden is in the path, because Eden produces structured per-request metadata that an optimization platform can act on. A workflow that costs more on Provider A and runs faster on Provider B is a routing decision Eden can enforce. An optimization platform can recommend it.

Supply chain and code review. Cloudsmith is treating package security as table stakes given the rise of supply chain attacks, which is the right read. The 2024 and 2025 supply chain incidents, including xz, the npm and PyPI campaigns, and the recent CI/CD agent compromises, have made every serious team rethink what they pull from where. Greptile is building agent-driven code review with the ability to ingest standards and domain knowledge, which is a sharper version of what CodeRabbit pioneered. None of these are gateway products. All of them are part of the same posture shift: AI is production infrastructure, and production infrastructure needs the operational discipline that has always applied to code, packages, and deployments.

Developer workflow. Warp is reimagining the terminal around agents. Cursor and Claude Code are doing the same for the editor. GitHub Copilot has expanded into the same territory. The Datadog Agent Console announced at DASH is meant to give platform teams visibility into all of these coding agents at once. The interesting pattern here is that every developer tool is becoming an AI surface, and every AI surface needs governance. The Eden role in this category is upstream: the model calls these agents make on behalf of developers can flow through Eden the same way customer-facing model calls do. Cost attribution, audit, and policy apply equally.

Database and data-tier evolution. Tiger Data launched Ghost at DASH as a purpose-built database service for the agentic era. The vector database category continues to mature. Redis Cloud, MongoDB Atlas, and PostgreSQL with pgvector are all positioned around agent workloads. The relevant pattern is that databases are being asked to do more on behalf of AI, which means the traffic between agents and databases is becoming the most security-sensitive path in many architectures. Eden's multi-protocol gateway is built for exactly this. The same control plane that governs the LLM call governs the database query that follows it.

The thread that ties all of it together: the companies winning in this category are not the ones with the flashiest AI features. They are the ones treating AI as a layer in the stack that needs the same governance, observability, and operational discipline as every other layer.

Why Eden Matters Here

The honest version of our pitch is short.

Most teams today solve AI governance by adding code to applications. Wrappers around model calls. Custom logging. Per-feature cost limits in business logic. Rate limiters in middleware. PII scrubbing in helper libraries. Audit hooks in the wrong layer.

That approach works for a while. Then the organization has five product teams, three model providers, a few agents in production, and no single answer to "who is using what, how much is it costing, and what data is leaving the company." The controls are scattered across too many places to govern consistently. The Kiteworks numbers are the visible version of this problem: most enterprises know they have a gap and have not closed it.

We think the answer belongs at the gateway level. One layer that every request flows through. One place to enforce routing, cost, audit, redaction, and policy. One control plane the platform team owns, with the application layer staying focused on the product.

That is what Eve, our runtime gateway, does. Adam extends it into the agent surface. Exodus handles the migration path when the underlying systems need to move. Each piece is meant to compose with the rest of the ecosystem, not replace it.

What This Looks Like in Practice

To make the composition concrete, here is what the stack looks like for a platform team building production AI infrastructure today.

A developer or an agent makes a request. The request hits Eden at the gateway boundary. Eden authenticates the caller, resolves the scoped credential from the secrets manager, attaches it at the proxy layer, and routes the request to the appropriate model or database based on policy. Sensitive fields are masked or redacted before they leave the VPC. The request is logged with full context: caller, route, cost, latency, policy outcome, data classification.

That structured event flows in real time to Datadog for observability and to the eval layer, such as LangSmith or Langfuse, for trace analysis. The same event populates the internal developer portal, such as Port, Cortex, or Backstage, so the platform team can see which agents are using which models, what they cost, and whether they are inside policy. If the request was part of a known incident pattern or a triggered alert, Bits AI SRE or AI Guard can investigate and propose a remediation. If the response shows signs of prompt injection or anomalous output, the gateway can quarantine future requests from that path while the team investigates.

Chaos and resilience testing run against the same path. Gremlin can inject a provider outage. Eden routes around it. Gatling can apply load. Akamas can use the resulting telemetry to recommend optimization. The packages running in the agent containers are signed and tracked through Cloudsmith. The pull requests touching the agent code go through Greptile review. The terminal sessions where developers iterate on this run through Warp or Cursor.

None of this is theoretical. Every piece exists today. The work for platform teams in 2026 is composing it correctly, not building it from scratch.

Eden is the runtime control point in that stack. It is most useful when it is one part of a well-composed system, not when it is trying to be the whole thing.

How to Get Started

If you are thinking about how Eden fits with the tools you already run, a few starting points.

The open-source repository is at github.com/eden-dev-inc/eden, released under Apache 2.0 on June 11. The Rust gateway, the service runtime, endpoint schemas for databases and AI providers, shared auth, telemetry, and the control-plane primitives are all included. Redis is the production-ready gateway protocol in this release. Postgres, Mongo, LLM, and agent gateway surfaces are in active development. You can run it, inspect it, modify it, and contribute.

If you are already running Datadog and want to see how Eden's first-party telemetry shows up in your existing dashboards, the integration is documented in the README. If you are evaluating BYOC Logs, Eden's in-VPC deployment composes with it directly.

If you are migrating off Azure Cache for Redis before the March 2027 deadline, Eden is on the Azure Marketplace today and bundled with Datadog observability. The migration that traditionally takes two to three months can be completed in a day.

If you are designing the credential, catalog, or resilience integrations into your gateway and want to compare notes, reach out. We are actively shaping how Eden composes with Doppler, Vault, Port, Cortex, Gremlin, Gatling, and the rest of the platform engineering stack, and we want those integrations designed by people running them in production.

The category is still being defined. The most useful thing any of us can do right now is keep shipping, keep listening, and keep the architecture honest about which layer each problem belongs at.