Run AURA in Slack without opening a single inbound port

October 30, 2026

Run AURA in Slack without opening a single inbound port

Making an SRE agent available in Slack sounds straightforward until you start thinking about what that agent can access.

If it's connected to Kubernetes, you need to consider how Slack communicates with the agent, what infrastructure the agent can inspect, and who can ask it to do something. Making operational tools easier to use shouldn't mean exposing another service or giving everyone unrestricted access to production.

We recently added direct Slack integration to AURA, our open-source agentic harness for SRE work. It uses an outbound connection to Slack, works with the MCP tools already configured in AURA, and lets engineers investigate production issues without leaving the incident channel.

Here's how it works, along with a few things worth considering when connecting an agent to your operational environment.

Slack is now a first-class interface to your infrastructure

There's a difference between asking a chatbot what might be wrong with a Kubernetes deployment and asking an agent that can actually inspect it.

In our demo, a backend service is unhealthy and a deployment is stuck in ImagePullBackOff.

Rather than manually checking pod status and events with kubectl, we ask AURA to investigate from Slack.

AURA uses the connected Kubernetes MCP server to inspect the workload and identifies the problem: the deployment references an image version that doesn't exist in the repository.

It returns the diagnosis in Slack, giving the engineer enough information to correct the image tag without ever having to open a terminal or read raw logs.

The important part isn't that AURA answered a question in Slack. It's that the answer came from investigating the actual workload rather than guessing at possible causes.

AURA didn't change the deployment or attempt remediation in this example. It investigated the issue and identified what needed to be fixed.

For SRE teams, that distinction matters. Finding the cause of a problem and having permission to change production are two different responsibilities.

Try AURA in your environment

AURA is an Apache 2.0 licensed open-source harness for SRE and production work. Whether you use it for ad-hoc queries, or embed it into your SRE workflows for automated root-cause analysis, the operational model stays the same. The agent runs in your infrastructure, connects to the systems you configure through MCP, and operates with the access those connections provide.

Today’s announcement makes it easier to use AURA in the channels where your team already works, without opening your cluster to inbound traffic.

Choosing an open source agent harness means you always have full ownership. You are never limited on inspecting or modifying the implementation and you have full control over your configuration.Because it’s built for SRE use cases, it only takes a few minutes to safely start exploring it for your own environment.

Try AURA on GitHub

‍

Ask about this page
Perplexity
Grok
Table of contents

    More blog posts

    Builder in the loop: what production agents were missing before AURA
    Builder in the loop: what production agents were missing before AURA
    AURA
    Site Reliability Engineering (SRE)
    The pager shouldn't be what starts the investigation
    The pager shouldn't be what starts the investigation
    Root Cause Analysis
    AURA
    Alerting & Incident Response
    What an AI SRE agent actually finds when you point it at a broken Kubernetes cluster
    What an AI SRE agent actually finds when you point it at a broken Kubernetes cluster
    AURA