Skip to main content
Via Credentials and controlled provisioning on target machines, you can hard-cap what an agent can affect - independent of what the prompt says.

​
The credential layer

When an agent SSHs into a Linux machine, it does so as a specific user. Give it the least-privileged user that still gets the job done. A common pattern: create an agent-2501 user on each managed host with only the permissions agents need. Critical commands (package installs, service restarts on specific units) go via sudoers allowlists. Every authentication layer - SSH, WinRM, MCP, API keys - can be scoped:

​
Plugin access during a task

A plugin’s credential is the cap on what its agents can do through it, so revoking access means changing the plugin. For an MCP server or an HTTP API, a running task notices:
  • At once, at its next call: the plugin turned off, removed from the agent or its connection changed, or, for an MCP server, its OAuth account changed or reconnected.
  • At its next turn: a rotated secret, a withdrawn credential grant, or a credential or Vault path that is gone.
  • Late, during an outage: if the database or Vault cannot be read when a turn resolves the plugin, the plugin keeps its client for at most three turns in a row or five minutes, and only while its assignment, connection and account are unchanged.
A plugin never falls back to anonymous access or to another account.

​
Calls are never sent twice

A plugin call that fails may have reached the server, so 2501 reports its outcome as unknown and never sends it again on its own, for MCP servers and HTTP APIs alike. The agent is told to check the call’s effect before trying again, and an MCP call that was in flight when the engine stopped is answered the same way when the task resumes. An MCP server that answers 401, or 404 on an ended session, processed nothing: only then is the call sent again, once.

​
What an MCP server controls

The MCP server writes the tool names, descriptions and input schemas the agent reads, so treat it like any input that steers the agent. A description is cut at 2,000 characters and a schema larger than 16 KiB is left out. A tool keeps its name for the whole task, and a call planned against a changed schema is refused, so a server cannot change a tool under a call the agent already chose. The task reports each plugin it cannot use, and why.

​
Match permissions to the agent’s mission

If an agent only needs to read AWS EC2 to produce a resource report, give it an IAM role with ec2:Describe* only. The agent literally cannot terminate an instance with that role, no matter what the prompt says. This is the most reliable safety layer in the system. Prompts can be jailbroken; IAM cannot.

​
When to relax

As you grow confident in an agent, you may want to give it more capability. Two things to update together:
  1. The credential’s permissions - broaden the IAM role, add sudoers entries.
  2. The specialty and rules - the agent was previously prompted that dangerous operations are out of scope. Update that text to reflect what’s now allowed and what’s still off-limits.
Promote permissions and prompt together. A relaxed prompt with locked-down creds frustrates the agent into retry loops; relaxed creds with a strict prompt is a footgun waiting to fire.

​
Quick checklist

  • Each host has a dedicated agent-2501 (or equivalent) user - not root, not the human admin
  • Sudo entries are explicit allowlists, not NOPASSWD: ALL
  • Cloud credentials use scoped IAM roles, not long-lived admin keys
  • Read-only investigation agents have IAM/RBAC matching their mission
  • When you promote an agent’s capability, you update both creds and prompts