An Agent Can Now Own the Containers It Starts ​

August 20, 2026 · InfraScout Team

An agent can host an MCP server for you, launching it inside your network so nothing has to be published to reach it. Plenty of MCP servers ship as a container image, so the natural command to hand the agent is something like podman run --rm ….

There is a subtlety in that command, and this release addresses it.

A run command is a client, not the workload ​

podman run is a client for the container rather than the container itself. The workload reparents away from the process the agent is supervising, which means the signals a supervisor relies on to stop a child reach the client and never touch the container.

Two consequences follow, and neither is recoverable by anything the agent can observe, because from its point of view the child is running:

  • A stop leaves the container running. Nothing owns it afterwards.
  • A failed start can leave both behind, and a retry adds another pair.

Declare it, and the agent takes ownership ​

There is now a Container toggle on an agent-hosted registration. Tick it when your command runs a container, and the agent owns that container's whole life:

  • It names the container deterministically, from the registration.
  • It removes any container left under that name before starting a new one, so a container an earlier agent generation abandoned cannot collide with the start this one needs.
  • It removes the container after a deliberate stop, and on both of the paths where the protocol handshake fails.

Teardown no longer depends on the client process dying cleanly, which was the whole problem.

A container that exits on its own is deliberately left alone — the engine's own --rm has already removed it, and reaping there could race a retry that has just created a fresh one under the same name.

Two things follow from the agent needing to know the name. A --name you put in the arguments is replaced, because a name the agent cannot predict is a lifecycle it does not own. And toggling the flag restarts the server, since it changes how the child runs rather than just how it is described.

Why it is a toggle rather than automatic ​

We could have detected this from the command — check whether the program is podman, docker or nerdctl and whether run is among the arguments.

We rejected that, because realistic variations defeat it. An absolute path to the engine binary. A wrapper script your platform team maintains. A /bin/sh -c 'exec podman run …'. Each is a container the check would miss.

And a wrong guess is harmful in both directions. A false negative leaves a container with nothing responsible for it, which is what this exists to fix. A false positive has the agent run an engine command against a binary that is not an engine at all. An explicit declaration is one tick, and it is never wrong.

Existing container-hosted registrations default to off, so nothing changes until you opt one in.

What this does and does not cover ​

To be clear about the boundary: this makes a container-hosted server's lifecycle deterministic. It does not make every container-based MCP server work.

Some server images do not start cleanly under a supervised, non-interactive parent even though they run fine from a shell — that is a property of the image rather than of InfraScout, and it needs solving on the image's side. What has changed is that such a failure now leaves nothing behind: a predictable name, a guaranteed teardown, and no accumulated processes to clean up by hand.

See MCP Servers for the toggle.

Questions or feedback? Reach us at info@infrascout.cloud.