Running infrastructure with AI agents through MCP

How AI agents work with Opfield through its MCP server: scoped OAuth access, the audit log, guards against accidents, Docker tools, and an example of a routine fix.

By the Opfield team4 min read

Opfield has an MCP server next to its REST API. Any MCP client, such as a coding agent in your editor or a chat app, can connect to it and work with the same resources a person sees in the interface: routes, containers, managed databases, Pages, alerts and nodes. This post explains how that access stays safe and what a typical session looks like.

The same rules as for a person

Agents have no separate permission model. An MCP client connects to https://<your-opfield>/api/mcp and signs in with OAuth on behalf of a user. On the consent screen the user picks the scopes the client gets, and those scopes can never go beyond what the user can do. Access limited to folders, nodes or single resources works the same way: an agent with access to one app's folder sees that folder and nothing else. The agent can call get_my_access to see what it was given and where it may create things.

Agents can do nearly everything a person can do with resources. A few things stay in the browser on purpose: impersonation, OAuth consent, creating API tokens or authorizations, and the user's own sign-in and sessions. An agent cannot give itself more access.

The MCP endpoint accepts only OAuth tokens issued for it; REST API tokens do not work there. The user also needs the MCP permission, so an admin decides who may connect agents at all.

Everything lands in the audit log

Every agent action passes the same checks as a click in the interface and is written to the same audit log, with the user and the token it came from. To see what an agent changed overnight, open the audit log.

Guards against accidents

Permissions decide what an agent may do. Some mistakes happen inside those permissions, so Opfield adds guards:

  • Console guard. Agents can run commands in a node console as root, which lets them repair a node. Docker, containerd and Podman are masked there, and a Docker command is refused with the name of the Opfield tool to use instead. This is an accident guard, not a security boundary: it keeps an agent from changing a managed container behind Opfield's back.
  • No SSH into nodes. Agents cannot run commands over SSH on hosts that are Opfield nodes. They use the node console, which has the guard.
  • Changes outside Opfield are visible. If a managed container is stopped, changed or removed by hand anyway, the built-in alert "Container changed outside Opfield" fires.
  • Safe retries. Create operations accept an idempotency key, so an agent that retries after a timeout does not create a duplicate.

Docker tools instead of a shell

Most agent work on workloads goes through dedicated tools rather than shell commands: list containers across all Docker nodes, read logs and stats, restart, update an image, change configuration, manage deployments with slots and rollback, Compose projects, volumes, networks, and Git sources with their builds. Because these are Opfield operations, routes, Secure Links and availability stay consistent after a change, and each step is audited.

Agents can also read Opfield's documentation and skills through MCP before they change anything.

Example: a failing service

A user asks an agent: "The billing API has returned 502 since this morning. Find out why and fix it." A typical session:

  1. find_resource finds the route and the container behind it; get_route shows the upstream.
  2. get_docker_container shows that the container keeps restarting and that its Git source deployed a new build at 07:40.
  3. get_docker_container_logs shows the process exiting on start because a new required environment variable is missing.
  4. The agent reports this and offers two options: roll back to the previous build, or add the variable.
  5. The user chooses the rollback. The agent calls manage_docker_source with rollback, then checks the logs and the route again: the container is running and the route answers 200. The rollback is in the audit log under the user's name.

Nobody needed shell access to the server, and the agent did nothing outside the user's own permissions.

Getting started

Add the MCP server to your client with your Opfield address, sign in and choose the scopes. Start with read-only scopes, watch what the agent does in the audit log, and widen access as you gain confidence. If you would rather not set up a client, the assistant built into Opfield uses the same tools and the same rules.