AI Agent Security Best Practices for Small Teams

The AI agent security best practices that matter most for a small team are these: never put a secret where an agent can read it; give every agent its own identity and its own credentials; run coding agents in the narrowest permission mode that works, inside a sandbox; give browser agents a separate machine or profile with nothing signed in that they do not need; decide in advance which data agents may read; have a person review agent output before it ships; and write a one-page incident plan before you need it. None of this needs a security team. It needs a few settings and a habit of asking one question of every agent: what can it reach, as whom, and where can it send things?

This piece is about agents in general. If your concern is agents connecting to your tools over MCP, the protocol has its own pair of posts: MCP security risks and MCP security best practices for teams.

Three kinds of agent, one question

• Coding agents in a terminal, such as Claude Code, Codex CLI or Gemini CLI. They read your files, run shell commands and can reach the network. Their risk is your machine and everything your machine is signed in to.
• Browser and computer-use agents. They see the screen, click and type. Their risk is every website the browser is logged in to, and every page they read, since any page can carry instructions.
• Agents inside software you already use: the assistant in your document editor, help desk or CRM. Their risk is whatever data that product lets them read, and whatever actions it lets them take on your behalf.

The same question sorts all three. Write down, for each agent, what it can reach, whose identity it acts with, and where it could send data. The practices below are ways of making each answer smaller.

1. Keep secrets out of prompts, rules files and context

Anything an agent can read, it can repeat, and anything it can repeat can end up somewhere you did not intend. The 2026 edition of the OWASP Top 10 for LLM Applications↗ (opens in a new tab) puts the rule plainly: do not embed credentials or secrets in system prompts or hidden context, and assume everything available to the model could also be available to users. For a small team that means three habits.

• Never paste a password, API key or connection string into a chat with an agent, even “just to test”. Chat history is stored, and it is read again every turn.
• Keep secrets out of CLAUDE.md, AGENTS.md, Cursor rules and any other file an agent loads automatically. Those files are instructions, and they get committed.
• Stop the agent reading the files where secrets do live. In Claude Code a Read deny rule does this for its file tools, and the documentation notes that it also blocks edits to the same path.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

A deny rule is enforced by Claude Code rather than by the model, which is the point: an instruction in CLAUDE.md saying “do not read .env” shapes what the agent tries, and changes nothing about what it is allowed. The documentation is also candid about the limit. File rules cover Claude’s own tools and the file commands it recognises, not a script that opens files by itself. For that you need the sandbox, below.

2. One identity per agent, never a shared one

An agent working under a person’s ordinary login is indistinguishable from that person in every log, and cannot be stopped without stopping them. Give each agent its own credentials: its own token for each tool, its own browser profile or machine, and where a product supports it, its own seat. OWASP’s Top 10 for Agentic Applications↗ (opens in a new tab) describes the failure precisely: without a distinct identity of its own, an agent works in an “attribution gap” that makes least privilege impossible to enforce.

For tools with scopes, grant the least that does the job, and start read-only. How that works on a shared board, with roles for people and assistants alike, is set out in roles and permissions for humans and AI agents.

3. Coding agents: the narrowest mode, inside a sandbox

Claude Code’s permission modes↗ (opens in a new tab) are a good example of the controls a coding agent should have, and the documentation describes them clearly. Manual (the mode named default) asks before the first use of each tool. acceptEdits accepts file edits and common filesystem commands inside the working directory. plan reads and explores without editing your source files. auto approves actions with background safety checks, and from v2.1.283 it is the built-in starting mode for interactive terminal and VS Code sessions, as our guide to auto-approve in Claude Code explains. dontAsk denies anything that would otherwise prompt. bypassPermissions skips prompts, and the documentation warns to use it only in isolated environments such as containers or virtual machines.

Rules sit on top of the mode, and they are evaluated deny first, then ask, then allow. A deny rule cannot be overridden by a narrower allow rule. An organisation can switch off bypassPermissions or auto in managed settings so that nobody can turn them on.

The sandbox↗ (opens in a new tab) is the stronger boundary, because the operating system enforces it for every command and its child processes. Turn it on with /sandbox. By default, sandboxed commands can write only to the working directory, a per-user temp directory and any directories you added. No network domain is allowed in advance: the first time a command needs one, you are asked. It runs on macOS, Linux and WSL2; native Windows is not supported.

Two details are worth knowing before you rely on it. By default a sandboxed command can still read most of the machine, including files such as ~/.ssh/ and ~/.aws/credentials, so add those to the sandbox’s denied reads or credential settings. And the documentation says plainly that sandboxing reduces risk but is not a complete isolation boundary. For work you do not trust at all, use a dev container or a virtual machine.

4. Browser and computer-use agents: a clean room

An agent driving a browser inherits every session that browser holds. If it is signed in to your bank, your email and your cloud console, so is the agent, and so is any web page that manages to give it instructions. Anthropic’s documentation for its computer use tool↗ (opens in a new tab) lists the precautions: use a dedicated virtual machine or container with minimal privileges, avoid giving the model access to sensitive data such as account logins, limit internet access to an allowlist of domains, and ask a person to confirm anything with real-world consequences, such as a payment or accepting terms.

The small-team version: a separate browser profile, or a separate machine, used only by the agent, signed in to only the sites that particular job needs, with purchases, sends and account changes left for a person.

5. Agents inside your SaaS tools

Built-in assistants are easy to forget because nobody installed them. Before switching one on, find out three things from the vendor’s admin settings or documentation: what data the assistant can read (one document, one workspace, or everything the user can see), which actions it can take without asking, and whether an administrator can limit either. If it can connect to other products, treat each connection as a new agent and ask the same questions again.

6. Decide what data agents may read

You do not need a classification scheme with seven levels. Three tiers cover most small teams, and writing them down once saves a debate every time someone connects something new.

• Open: anything already public, and ordinary internal work such as tasks, code and documentation. Agents may read it.
• Careful: contracts, finances, unreleased plans. Agents may read it on a named person’s instruction for a named job, and not keep it in shared notes.
• Never: credentials, payment details, customer and personal records, anything under a regulation. No agent reads it. Where a job needs it, the agent prepares and a person handles the data.

7. Boundaries on what an agent can send

The dangerous combination is an agent that reads untrusted content, can reach sensitive data, and can send things out, all in one session. Break any one of the three and most attacks stop working. In practice, the easiest to break is the third: limit network access to an allowlist of domains, and keep sending, publishing and payment tools on “ask”.

8. Review agent output before it ships

Agent-written code goes through the same review as a colleague’s, on a branch, before it merges. Claude Code includes a /security-review command for a security pass over the changes on your branch↗ (opens in a new tab); use it as an extra reader, not as the reviewer. Anything customers will see, anything that spends money, and anything that changes live data is prepared by the agent and released by a person. Where exactly people should step in is covered in human in the loop for AI agents.

9. Write the incident plan now

When an agent does something wrong, the first hour decides how bad it gets. Write this on one page, keep it with your other runbooks, and rehearse the first two steps once.

1. Stop it: end the session, revoke its tokens (not the person's login)
2. Contain: rotate any secret it could have read
3. Read the records: tool history, version control, provider logs
4. Undo: revert commits, restore deleted items, reverse moves
5. Tell: whoever owns the affected system, and customers if data left
6. Fix the cause: narrow the access that allowed it, write it down

Step three only works if each tool records changes under the agent’s own name. What that record should contain is in an audit trail for AI agents, and the routine that checks it monthly is how to audit AI agents.

Where a task board fits

Most of these practices are about the agent’s environment. A shared board is where its work is written down, and on fenbs it follows the same rules. Each assistant connects with its own token, holding the role of the person who connected it, narrowed by the scopes read, write and comment. Every change is recorded in History as “Claude via” that person. Revoking a token in Settings stops it at once and leaves the person signed in, and a deleted task can be restored. That covers steps one, three and four of the incident plan for the board itself.