How to Lock Down an AI Agent Dashboard Before It Becomes an Attack Surface

An AI security agent can be useful inside an authorized test environment. Put its control panel on a public IP, leave its database reachable, and the same system can become an attack surface for everyone else.

That is not a hypothetical edge case. In a November 5, 2026 report, Check Point Research said it identified 2,557 systems that currently or previously hosted ARTEX panels. Of those, 1,608 were live and publicly accessible when researchers checked. Ten exposed their full databases. The report also describes separate attack campaigns in which agents found weaknesses in target systems, including one unauthenticated API that exposed AWS S3 credentials. Those target compromises are distinct from the exposed ARTEX dashboards and databases, but they underline why a security agent's own control plane and permissions deserve careful isolation. (Check Point Research)

The useful lesson is not that every AI agent is dangerous. It is that an agent dashboard can combine a web interface, credentials, a database, and tools capable of taking actions. If that control plane is reachable from the internet, the risk is larger than an ordinary forgotten admin page.

This guide is a defensive checklist for a self-hosted agent service running in Docker. It does not assume a particular product or deployment. Do not expose a testing tool or run it against systems without explicit authorization.

First, decide whether the dashboard needs to be public

For most individual operators and small teams, the safest answer is no. Keep the dashboard on the host or inside a private network, and connect through a VPN or another authenticated private-access layer.

Docker's documentation is explicit: a published container port is exposed to the outside world by default. Binding the host side to 127.0.0.1 limits access to the Docker host. (Docker port publishing)

A minimal Compose mapping for a local-only interface looks like this:

services: agent-ui: image: example/agent-ui:latest ports: - "127.0.0.1:8080:8080"

The left side is the host address and port; the right side is the container port. Replace the example image and port with values from the software you actually use. Docker's current documentation warns that releases older than 28.0.0 may still allow hosts on the same Layer 2 network segment to reach ports published to localhost. Check your Engine version and local network exposure rather than assuming loopback binding is a universal boundary. This mapping is only one layer of protection, not a replacement for authentication, updates, or network controls.

If a reverse proxy on the same host needs to reach the UI, a private Docker network may be a cleaner design than publishing the application port. The proxy can publish the intended public HTTPS endpoint, while the application remains reachable only by other services on that private network.

Before choosing either pattern, draw the intended traffic path: who connects, from where, through which component, and to which service. If the answer is “anyone on the internet” for an administrative interface, stop and redesign the path.

Check what Docker is actually publishing

Compose files are not the whole story. A container may have been started manually, changed by an override file, or recreated with different options. Inspect the running state.

docker ps --format 'table {{.Names}}\t{{.Ports}}'

Look for bindings that include 0.0.0.0, ::, or a public host address. A mapping such as 0.0.0.0:8080->8080/tcp means Docker is listening on all IPv4 interfaces for that port. The same concern applies to IPv6 bindings.

To inspect one container in more detail:

docker inspect --format '{{json .NetworkSettings.Ports}}' agent-ui

Review the output for host IPs. If the service should be local-only, the expected host address is 127.0.0.1, not a wildcard address. If it should have no host-level exposure at all, remove the published port and connect it through a private Docker network instead.

Then test from outside the server. A local curl only proves that the host can reach the service; it does not prove that the public internet cannot. Use an external system you control, and check the service's actual public address and port. Do not scan systems you do not own or have permission to assess.

Do not rely on UFW alone to contain published ports

A common mistake is to publish a container port and assume a host firewall will block it. Docker documents a specific interaction with UFW: published container traffic is diverted through Docker's NAT rules before it reaches the chains UFW uses, so those UFW rules may not apply as expected. (Docker and UFW)

That does not mean host firewalls are useless. It means you should not treat a generic “deny incoming” UFW policy as proof that a Docker-published port is private. Prefer not publishing the port in the first place. If public access is genuinely required, apply and verify the restrictions at the correct layer, such as the cloud firewall, the Docker-aware host rules, and the reverse proxy or VPN boundary. Test the result externally.

Also avoid “fixes” that disable Docker's firewall management without understanding the consequences. Docker warns that turning off its iptables or ip6tables rules can break container networking and may leave ports accessible to local-network hosts if replacement rules are absent. (Docker firewall documentation)

Put authentication in front of every control plane

A private address reduces who can reach a dashboard. It does not replace user authentication. An authenticated VPN user may still be on a compromised device, and a reverse proxy can be misconfigured.

Use unique accounts where the application supports them, strong authentication, and multi-factor authentication for remote access. Remove default credentials and disable unused accounts. If the application has no meaningful authentication, do not expose it directly to the internet. Put it behind a private-access layer with its own authentication, and restrict who can reach that layer.

Treat API endpoints as part of the control plane. Hiding the web page behind a login while leaving an unauthenticated API path exposed is not a secure design. Check the vendor's documentation for the supported authentication model; do not infer that an endpoint is protected because the main page redirects to a login screen.

Keep secrets away from the dashboard and agent logs

Agent services may need API keys or credentials to call models and tools. Store only the credentials the service needs, and scope them as narrowly as the provider allows. Use separate keys for separate environments where possible, set spending or usage limits when available, and rotate a key if it appears in logs, a database dump, or a support bundle.

Do not put secrets directly into a Compose file that is committed to source control. Use your deployment platform's secret mechanism or a protected environment file with restrictive permissions. Check what the application stores in its database and logs, and whether those stores are backed up or exposed through the UI.

The Check Point report's exposed-database findings make this more than routine hygiene: a dashboard compromise can reveal information about the operators and the agent's work, not just the dashboard itself. Minimize retained data. Avoid recording credentials or sensitive output unless there is a clear operational need and a defined retention period.

Reduce what the agent can do if the UI is compromised

Assume that a reachable control plane may eventually be abused. Limit the blast radius before that happens.

Run the service as a non-root user when the image supports it.
Do not mount the Docker socket into an agent container. Access to that socket can amount to control over the Docker host.
Avoid privileged mode and unnecessary Linux capabilities.
Mount only the specific directories the service needs, preferably read-only when writes are not required.
Keep production credentials and sensitive personal data out of the agent's workspace.
Separate the agent from databases and internal services it does not need to reach.
Require a human approval step for consequential actions, such as changing infrastructure, sending messages, or accessing sensitive systems.

These are layered safeguards. No single Compose option makes a powerful agent safe, and a container is not a complete security boundary for every threat model. Review the image's documented requirements rather than blindly applying settings that might break the service or create a false sense of isolation.

Restrict outbound access, not only inbound access

A dashboard firewall controls who can connect to the agent. Egress controls what the agent can connect to. If an agent only needs a model API and a small set of approved targets, unrestricted outbound access gives a compromised or misdirected process more room to act.

Start by listing required destinations: model provider, package sources, internal services, and explicitly authorized test targets. Deny unnecessary destinations at the network or host layer where practical. If the agent is used for security testing, put it in a separate environment with a clear target allowlist and no route to production systems or personal devices.

This is especially important because an agent can operate for long stretches after an operator submits an objective. Check Point's analysis describes campaigns in which agents received an initial task and then worked with little further operator interaction. That autonomy increases the importance of defining limits before execution, not relying on an operator to notice every action in real time. (Check Point Research)

A short audit you can run today

Use this checklist for each self-hosted agent or administrative tool:

Inventory: Identify the host, containers, listening ports, image versions, credentials, database, and connected tools.
Exposure: Check docker ps and docker inspect. Remove public bindings that are not required. Bind local-only services to loopback or keep them on a private container network.
Boundary: Confirm access from a separate machine you control. Verify both IPv4 and IPv6 paths and any cloud firewall rules.
Identity: Remove default accounts, require authentication, enable MFA where supported, and restrict who can reach the VPN or proxy.
Permissions: Remove Docker socket mounts, privileged mode, unnecessary capabilities, broad host mounts, and unneeded credentials.
Data: Check whether logs, backups, and databases contain secrets or sensitive agent history. Set a retention period and limit access.
Egress: Document the destinations the service needs. Block or isolate unnecessary outbound paths.
Recovery: Know how to revoke credentials, stop the service, restore a clean database, and review access logs if exposure is found.

If you discover that a dashboard was publicly reachable, do not stop at closing the port. Review access logs, rotate credentials the service could access, inspect database and file changes, and check connected cloud resources. Preserve relevant evidence before rebuilding if you need an incident investigation.

The principle: contain the control plane first

The ARTEX findings are striking because the same systems built to orchestrate security work were themselves left reachable. The core defensive response is practical: keep administrative interfaces private, verify Docker's real port bindings, avoid assuming UFW covers published ports, and limit the agent's credentials, permissions, and network reach.

An AI agent does not need to be malicious for this to matter. A vulnerable dashboard, stolen credential, or overly broad tool permission can turn an agent host into a useful foothold. Design the deployment so that a single mistake does not expose the control panel, the agent's data, and the rest of the network together.

Save this checklist and apply it to each agent dashboard, workflow runner, and self-hosted admin panel before it goes online.

If practical, security-focused engineering guides are useful to you, subscribe for more. Have you found an unexpected public port in a Docker deployment? What caught it?