Built for the Enterprise, Run by the Enterprise: Traversal Introduces Seven Launches That Put Platform Teams in Control
Traversal is the AI SRE for the enterprise. In practice, that means working inside production environments that took decades to build and won't be rebuilt for a new tool.
So Traversal asks for very little: no agents on your hosts, no sidecars, no required markdown files, and no schemas to define up front. It connects to the tools you already use and can run in your own cloud (BYOC) or with your own LLM keys (BYOK), so your data stays within your boundaries.
That approach is why some of the world's largest financial institutions, consumer brands, and technology companies run Traversal in production today. As those deployments expand from a single team to entire engineering organizations, Traversal becomes an enterprise platform operated at scale and governed across the organization. The people who own platforms ask a specific set of questions: What exactly is it connected to? Does it reach the systems we actually run? Can we deploy and maintain it ourselves? Who can act through it, and how is that audited? What does it cost, and can we cap it?
Today we're launching seven capabilities that answer them. Together, they give enterprise teams the same visibility and control over Traversal that they expect from the rest of their infrastructure. And this is only the start. The next wave will go further in deepening how enterprises govern Traversal: tighter control over who can act through it, what data they can access, and also what Traversal agents can access on their behalf, across every surface they act through. Together, these will bring enterprises every control they need and have come to depend on.
See Traversal in action today.
Know exactly what Traversal can see, with Integration Health Checks and Datasets
An AI SRE is only as good as what it can see. If an integration is broken, or connected but missing half your log indices, every investigation downstream inherits that blind spot. We've made both problems visible.
- Health checks, step by step. Until now, an integration health check returned one of two answers: pass or fail. A failure told you something was wrong, but did not isolate where or why. Health checks now report each stage separately: connectivity, authentication, and querying the source. When one fails, you know exactly which step broke. Each failure comes with remediation guidance, so an admin can fix it directly instead of filing a ticket and waiting.
- Datasets. Knowing an integration is connected isn’t the same as knowing what data Traversal can actually access through it. Traversal groups these underlying sources into datasets: for example, the individual indices logs. Admins can see exactly what’s covered, catch gaps, and understand what Traversal has available when it investigates.
Investigate deeper into your AWS stack with CloudWatch and AWS Account
Most enterprise production runs, at least in part, on AWS. Two new integrations connect Traversal to it the same way your security team already approves AWS access: through a cross-account IAM role with short-lived credentials, and no long-lived access keys to manage. Amazon CloudWatch brings your metrics and logs in as native telemetry, so they become part of every investigation alongside the rest of your data. AWS Account lets Traversal inventory resources and inspect their configuration across AWS services. Traversal can also inspect EKS and other Kubernetes clusters directly.
Every expansion of what Traversal can see has made it sharper: first logs and metrics, then code, then the tickets and docs in tools like Linear and Notion. AWS may be the biggest leap yet. SREs can diagnose problems in AWS managed services directly, and issues that start elsewhere, like a failed connection between two services, become far easier to explain with the network underneath in view.
Bring your Azure environment into every investigation
Traversal now integrates with Microsoft Azure, bringing the telemetry and infrastructure context from your Azure environment into every investigation. Azure resources and the signals they produce become part of the same picture Traversal already reasons over, alongside your code, your deploys, and the rest of your observability stack.
Many enterprises don’t run on a single cloud. Some workloads live in AWS, others in Azure, and the dependencies between them don’t stop at the boundary. With both connected, Traversal can follow an incident wherever it leads, from a service in one cloud to a dependency in the other, without anyone switching consoles or piecing the story together by hand. Traversal fits the way your organization already runs, whichever clouds that includes, so you don’t have to standardize on one first.
Connect your internal tools to Traversal through MCP
Every enterprise relies on tools that aren’t readily available as off-the-shelf integrations: an internal deploy system, a homegrown service catalog, a team’s custom runbook tool. The Model Context Protocol (MCP) has quickly become the standard way to make tools like these available to AI systems.
Customers can now connect any MCP server to Traversal as an integration. Once connected, that server's tools become available to Traversal during investigations, right alongside its native integrations. Multiple authentication methods are supported, so teams can connect MCP servers in whatever way their security standards require.
The result: if a tool is critical to how your team runs production, Traversal can use it, whether or not we've built an integration for it.
Securely connect your telemetry to Traversal, now Self-Service
Traversal links to your environment through two lightweight components, Traversal Connector and Traversal Processor. Both can now be deployed and managed self-service from the Traversal web UI:
- Traversal Connector securely connects to your data sources through outbound-only, mutually authenticated connections.
- Traversal Processor turns high-volume logs into structured, searchable signals and tuned as your data volume changes.
A guided flow takes you from sizing to deployment in minutes. You can manage mTLS certificates yourself, and monitor connectivity, data flow, and component health, all directly in Traversal.
For enterprise platform teams, this is the difference between a vendor-managed install and infrastructure you own. Your team decides when to deploy, where, and how to roll it out. And at any moment, you can see whether each component is healthy, without a support ticket or a call.
Give your automations their own identities with Service Accounts
As Traversal moves beyond interactive investigations into automated workflows, such as pipelines, scheduled jobs, and internal tools that call Traversal’s API, those workflows need identities of their own.
Traversal now supports Service Accounts: machine identities built for automation, separate from any individual user. Admins can create, view, and revoke API keys from one place. Automations no longer depend on a person’s credentials. Access can be revoked the moment it’s no longer needed. And every automated action is attributable to a known identity.
Service accounts are the first step in a broader set of access controls. Role-based access control (RBAC) and fine-grained authorization (FGA) are next, giving admins precise control over who can act through Traversal, what data each person and automation can access, and what Traversal’s agents can reach on their behalf. Together, they’ll give security and compliance teams what they need before letting any system run at scale: clear ownership, least-privilege access, and a clean audit trail.
Keep Traversal spend predictable with Metering and Usage
Rolling an AI platform out across thousands of engineers raises a fair question from whoever owns the budget: what will this cost, and what keeps it predictable?
Admins can now set usage limits across their organization, giving them direct control over Traversal spend. Engineering teams get room to adopt Traversal broadly, while finance gets predictability and visibility.
Built for the enterprise, run by the enterprise
Before platform, security, and finance teams trust a system with production, they need to know what it can see, how far it reaches, who deploys it, who can act through it, and what it costs. These seven launches give them clear answers to all five, and there’s more on the way.
