Tool Use and Capability Design

What tools an agent can use determines what damage it can do. Designing tool grants is one of the most important safety decisions in fleet architecture.

The Principle of Least Privilege, Applied to AI

In security engineering, the principle of least privilege says every component should have access to exactly the resources it needs to do its job - and nothing more. The same principle applies to AI agents, with an important twist: unlike a service account that can only do what its access control list permits, an AI agent with a broad tool grant can decide to use any of those tools in ways the designer did not anticipate.

A content-creation agent that has write access to all repository files can, in theory, modify the site’s CSS, alter unrelated pages, or overwrite the sitemap with incorrect entries. An agent with a narrower tool profile - write access only to its course directory, read access to the files it needs, and the GitHub MCP tools for creating a PR - can only affect the files it is supposed to affect. The tool grant is a hard constraint, not a soft one.

The Tool Stack for Each Fleet Agent

Here is the actual tool profile for each agent in our fleet, and the reasoning behind each grant:

The Read-vs.-Write Design Rule

A useful starting point for tool design is to categorize every tool as read or write, and ask whether the agent strictly needs each write capability to do its job. Read tools are almost always safe to grant broadly - reading a file, reading the git log, reading a PR description does not change state. Write tools are where you need to be careful.

Our ContentCreation-Draft agent needs write access to several files: the new course directory (to create HTML), ai-school/index.html (to add the course card), main.js (to add searchData and autoMarkProgress entries), sitemap.xml (to add URLs), and TODO.md (to mark the item in-progress). These writes are specific and enumerable. The agent does not need write access to the CSS, the images directory, any other course, or any infrastructure file. The write grants are scoped to exactly what the task requires.

MCP Tools: The GitHub Integration Layer

Model Context Protocol (MCP) servers provide a structured way to expose external service APIs as agent tools. Our agents use a GitHub MCP server that gives them the ability to create branches, push files, and open pull requests - without giving them direct git push access to master.

This architecture is important: the GitHub MCP tools let agents propose changes through the PR process, but the underlying branch-protection rules on the repository prevent any direct push to master. Even if an agent interpreted its spec incorrectly and tried to push directly, the branch protection would block it. The MCP tool layer and the repository access controls work together as redundant safety layers.

The Tool Design Heuristic: Can It Hurt?

For each tool you are considering granting, ask: if this agent uses this tool in the worst plausible way, what is the maximum damage? Tools that can cause damage to production with a single call need the strongest justification. Tools whose worst-case misuse is a trivially reversible change can be granted more freely.

What Agents Should Not Have

Some capabilities that seem useful are more dangerous than they are valuable at the fleet stage:

• Merge access. The PR gate is the primary human checkpoint. Giving agents merge access eliminates the most important human review opportunity. Even a well-specified agent will occasionally produce output that needs correction before going live.
• Access to production credentials. If an agent does not need a credential to do its job, it should not have the credential. ContentCreation-Draft does not need the GoDaddy FTPS credentials, the Google Analytics service account, or the LinkedIn page credentials. It writes HTML files and opens PRs. That is all.
• Ability to modify other agents’ specs. An agent that can change its own spec or another agent’s spec can change its own instructions. This is a capability that should require explicit human action.
• Access to delete files or branches. Deletion is rarely the right tool for any agent task we have defined. Creation and modification, yes. Deletion, no.