AI agent setup & security

Agents that act need a boundary

An AI agent does more than answer. It runs code, writes files, calls tools and reaches across your network, often for hours without supervision. That is where the value is, and it is why an agent cannot be trusted to police itself.

This summer, agents in several frontier-lab evaluations escaped the environments meant to contain them. In August the NCSC published interim guidance on agentic AI: sandbox the environment, keep activity observable and attributable, and keep an emergency stop. We set agents up so they meet that guidance before they touch real systems or data.

What we set up

The agents themselves

Coding agents for your engineers, document and case-file agents for your analysts, and operations agents for IT service management and infrastructure work. Each is routed to models you approve, including open-weight models on your own GPUs.

A sandbox around every agent

Deny-by-default network egress, filesystem limits, system call filtering and no stored credentials inside the sandbox. We use NVIDIA OpenShell where it fits, with its policy compiled from code and checked before every change.

Least privilege on every tool

Scoped, short-lived credentials for each connected system. New network destinations and consequential actions wait for a named person to approve them.

Logs you can attribute

Every action, policy decision and model call goes to your SIEM, and outbound traffic is identifiable as yours. When someone asks what the agent did last Tuesday, you can show them.

A kill switch someone has practised

One control that halts an agent, cuts its network and interrupts its access to the model. We rehearse it with your team before go-live, because a stop nobody has tested is not a control.

Security review of agents you already run

Many organisations already have agents in use: coding assistants with repository access, copilots wired into mail and documents, automations with service accounts. We inventory them, map what each can reach, test whether the limits hold and write down what to change first.

On DGX, HGX or your cloud

Agents run on the infrastructure you already have: NVIDIA DGX and HGX estates, ordinary Linux servers or a UK cloud region. On DGX and HGX systems with BlueField DPUs we also enforce egress outside the host and prepare for NVIDIA Sentry. Our guide to OpenShell and Sentry on DGX and HGX covers what runs on BlueField-3 today.

Mapped to NCSC guidance

Each control maps to the NCSC's considerations for agentic AI and to the Cyber Assessment Framework: permissions and sandbox configuration to B2 and B4, activity logs to C1, and the stop procedure to D1. The standards we build to apply here as everywhere else.

How an engagement runs

Weeks 1-2: Inventory and threat model. Agents, harnesses, hosts and credentials listed. Red lines agreed. One agent class chosen to start.

Weeks 2-6: Set up and contain. Agents configured, sandboxes and policy in code, credentials scoped, logs flowing to your monitoring.

Weeks 4-8: Prove it and hand over. We attempt escapes on purpose, rehearse the kill switch and hand over the evidence, runbook and policy repository.