Every agent we build starts with the same question: what is the least it needs in order to do its job? Not what would be convenient, and not what would make the build faster. The least.

This is an old idea from security, usually called least privilege. Give a person or a program only the access required for the task, and nothing more. It matters more with agents, because agents act quickly, act without hesitation and sometimes act on things they should not trust.

Why agents need tighter limits than people

A new employee with too much access usually has common sense to fall back on. They pause before deleting a customer list. They notice when a request feels off. An agent has only what its spec and its permissions say.

There is a second reason. Agents read things. Emails, web pages, documents, form entries. Some of that text may be written by someone who is trying to steer the agent into doing something it should not do. This is often called prompt injection. You cannot fully prevent an agent from ever being fooled, so you design for the case where it is. If the agent can only do small, safe things, a fooled agent can only do small, safe damage.

Assume the agent will sometimes be wrong or misled. Then make sure being wrong is cheap.

Start from zero

The easy way to set up access is to start broad and trim later. The safer way is to start with nothing and add one permission at a time, each with a reason you can write down.

For every tool an agent uses, we ask three questions:

  1. What exactly does the agent need to do with it?
  2. What is the smallest permission that allows that?
  3. What is the worst thing that happens if the agent misuses it?

If the answer to the third question makes you uncomfortable, the permission is too wide, or it needs a person approving each use.

A ladder of access

It helps to think of access as steps on a ladder. Move up only when the job requires it.

  1. Read only. The agent can look but not change anything. Many useful agents never need more than this.
  2. Draft. The agent can prepare something, like an email draft or a proposed record change, but a person must act on it.
  3. Write with approval. The agent can make a change, but each change waits for a person to approve it.
  4. Write on its own, within limits. The agent can make changes without approval, but only of a narrow type and size.
  5. Irreversible actions. Sending money, deleting data, changing permissions. These stay with people.

Most of the agents we see people build jump to step four because it is the demo that looks impressive. Most of the value is in steps one to three.

What we give an agent

  • Its own identity. One agent, one set of credentials. Never a shared login. If something goes wrong, you need to know which agent did it, and you need to switch off that one without breaking the others.
  • Scoped keys. API keys limited to the specific actions and data the job needs, where the tool allows it.
  • Allowlists. A short list of approved places it may read from, write to or send to, instead of a list of what is forbidden.
  • Limits on volume. Caps on how many actions it can take per hour or per day. A runaway loop should hit a wall quickly.

What we never give it

These are our defaults. Your situation may justify a different line, but if you cross one, do it on purpose and write down why.

  • Admin or owner level access to any system.
  • The ability to change its own permissions or another agent's permissions.
  • The ability to delete records, as opposed to flagging them for review.
  • Access to payment methods or the ability to move money.
  • Your personal login. Agents get their own accounts.
  • Broad access to data it does not need for the task, such as the whole inbox when it only handles one folder.

Build an audit trail from day one

Permissions limit what can go wrong. An audit trail tells you what did happen. Without one, you cannot answer simple questions like "why did it send that?" or "when did this change?"

For every action an agent takes, we want a record with:

  • Which agent acted.
  • When it acted.
  • What it did, and to which record or system.
  • What input triggered it.
  • The reason it gave, in one plain sentence.
  • Whether a person approved it, and who.

Keep this log somewhere the agent itself cannot edit. A log the agent can rewrite is not an audit trail.

Review on a schedule

Permissions drift. A temporary access gets added during a build and never removed. A new tool gets connected and inherits more than it should. Put a review on the calendar, monthly to start, and for each agent ask:

  • Is every permission still in use? If not, remove it.
  • Did the log show anything unexpected?
  • Has the job changed in a way that changes what the agent needs?

Also keep a simple way to switch an agent off fast. Know where the off switch is before you need it.

A short checklist

  • One agent, one identity.
  • Start with no access and add only what the job requires.
  • Prefer read and draft over write.
  • Keep irreversible actions with people.
  • Use allowlists and volume limits.
  • Log every action somewhere the agent cannot edit.
  • Review access on a schedule.
  • Know how to switch it off.

None of this makes agents slower to build in any way that matters. It makes them easier to trust, which is what lets you give them more work over time.