Guardrails for AI agents acting on a live network

The challenge

An agent connected to network devices through MCP acts with whatever access its tools give it. MCP does not standardize per-tool authorization, and an MCP server exposes its full tool list to every agent. Behind the server, shared static credentials make every connection look the same to the device. In the demo, an insecure raw-command tool let a viewer’s agent read a full device configuration, list open ports and stop the BGP process.

What was at risk:

• Arbitrary commands on production devices through prompt injection, no per-user attribution at the device, and no way to keep agents off the network while an administrator repairs it

What we did

• User identity carried to the MCP servers as a signed token with roles and MCP tool scopes, so the agent acts on behalf of a real user
• Tool access checked twice: unauthorized tools are hidden when the agent starts, and every tool call is checked again with input validation and a role check
• Attribute-based access to devices by site, environment and tenant, evaluated by a policy engine against the device inventory
• A maintenance-window switch that lets an administrator lock every other user’s agent out of the network
• Shared device credentials replaced by just-in-time SSH certificates bound to the user, mapped to role-based service accounts on each device
• A second, independent layer on the device: each command validated against the user’s role locally or through TACACS+, with shell injection refused
• Correlation IDs injected at every component and audit logs collected centrally, so a trace view groups activity by time, user and prompt
• Configuration changes held for human confirmation before they apply

How it works

Every agent action passes through identity, tool, device and command checks before it reaches the network, and leaves a correlated audit record, in five stages.

1. Identity The user logs in to Net-Inspector through the identity provider (Keycloak) and receives a signed JWT. The token carries the user’s role, MCP tool scopes and the sites, environments and tenants the user may reach. The application never sees device credentials.
2. Agent initialization When the agent starts, it asks the MCP servers for their tools and passes the user’s token. Each server returns only the tools that role may use: a viewer gets read tools, an operator also gets probe tools such as ping and traceroute, and an administrator also gets tools that change configuration.
3. Tool call On every call, the MCP server validates the token, validates the tool input and checks the required scope. It then asks Open Policy Agent whether this user may reach this device right now, given the device’s site, environment and tenant and any active maintenance window. A denial comes back with a clear reason.
4. Device access The MCP server exchanges the user token for a just-in-time SSH certificate from OpenBao, mapped to a role-based service account on the device. On the device, OpenSSH ForceCommand runs a validation script on every command, or delegates the decision to TACACS+ where the device supports it. Commands with disallowed characters are refused.
5. Audit User, role, session, agent ID, request ID and certificate serial are injected into the logs of every component. syslog-ng ships them to a central Loki server, and the trace view shows each prompt’s path from agent to device, including where it was allowed or denied.

The demo network runs in Containerlab: nine multi-vendor nodes across three sites (Chicago, Denver and Seattle), with production and lab environments and several tenants. Five MCP servers (topology, control plane, data plane, alerts and logs) expose about 47 tools to a LangGraph ReAct agent.