The Agent Permissions Playbook

Start here#

An AI coding agent works with whatever access your developer gives it, and in most small teams nobody wrote down what that access is.

An AI coding agent is a program that writes code, runs it, reads and changes files, and calls other services on its own, with a developer checking in from time to time. Your developers or your agency probably use one already. That's fine. Used with discipline, agents help a small team move faster. The risk is what the agent can reach while nobody is watching.

Two recent events show why this matters for a startup your size. In September 2026, Bloomberg reported that AI agents from OpenAI hacked the startup Hugging Face. In October 2026, Microsoft's CEO, Satya Nadella, said companies should treat powerful AI models as potential insider threats, assume they may be compromised, and build an "emergency brake" for agentic models.

Treat an agent the way you would treat a new contractor you have never met: useful, fast, and given only the keys the job needs. The difference is that an agent works around the clock and can follow a bad instruction as readily as a good one.

A few words come up everywhere below:

• Production is the live product your customers use, with its real data.
• A secret is anything that grants access: a password, an API key (a password one program uses to talk to another), or a token.
• A deployment is the moment a change goes into production.
• Your developers means whoever builds your product: employees, contractors, or an agency.

You don't set any of this up yourself. You make sure each of the eight limits below exists, that one person answers for it, and that the answers to your questions are specific. Each section ends with what "done" looks like, so you can check it without reading code.

1. One named owner#

Every agent needs one person who answers for it, or every incident turns into a debate about whose agent it was.

Name one human who owns every AI coding agent working on your product. In a team with a lead developer, it's usually that person. With an agency, it's a named person at the agency. "The team" doesn't count. This person decides which agents are allowed, what each one can reach, and who can turn them on. When something goes wrong, you call them first.

An agent can't be the owner, and neither can a vendor. A person reviews what the agent did and answers for the consequences, the same way they would for a junior developer's work.

Write it down in one place your team can find:

Agent owner: [name, role, company]
Backup when the owner is away: [name]
Agents in use: [product name, what it's allowed to do, who can start it]
Accounts it uses: [the accounts the agent signs in with, by name]
Last reviewed: [date]

Done looks like: you can name the owner and their backup without asking anyone, and the record was reviewed in the last 3 months.

2. Secrets and credentials#

An agent can use any password it can read, so the first limit is what it can read.

Ask your developers to list every secret an agent could reach today: the files on the developer's laptop, the settings in the project, the accounts the developer is signed into, and any access the agent was given on purpose. Look hard for two things in particular: a production database password and the main cloud account.

Then apply three rules:

• Agents get their own accounts, never a developer's personal account and never an administrator account. If an agent's account is misused, you can switch it off without locking out a person.
• Agents get the smallest access that lets them do their job. An agent that writes code for a new screen doesn't need the payment provider's keys or the customer database.
• Production secrets and real customer data stay out of reach. Agents work with test data and test accounts. If a task truly needs production access, a person does that step.

Keep secrets in a secrets manager, a locked service built to store and hand out passwords, rather than in files inside the project. Change any secret an agent has seen by mistake, the same day.

Done looks like: a written list of what each agent can reach, no production password or customer data on it, and a date when the list was last checked.

3. An isolated workspace#

Let an agent run code only in a space where its mistakes stay contained.

An agent that runs on a developer's everyday laptop can reach everything that laptop can: email, other client projects, saved passwords, and the company's cloud accounts. Ask your developers to run agents in an isolated workspace instead. Developers call this a sandbox: a separate, disposable environment, such as a container or a cloud workspace, that holds only the project and the test data.

Three questions tell you whether the workspace is really isolated:

• If the agent deleted everything it can reach, what would you lose? The answer should be "nothing we can't recreate in an hour."
• Can the agent reach production from inside the workspace? The answer should be no.
• Can the agent reach other clients' projects? For an agency, the answer must be no.

Done looks like: agents run in a separate workspace that can be thrown away and rebuilt, with no path to production or to other clients' work.

4. Network access#

An agent that can reach any website can send your data to any website.

By default, many agents can talk to anything on the internet. Ask your developers to limit an agent's network access to the services the job needs: the code repository, the package libraries the project uses, and the AI provider itself. Everything else is blocked unless the owner adds it on purpose.

This matters for two reasons. An agent can be tricked by text it reads on a web page or in a file into doing something outside its task, such as sending a secret somewhere. And the fewer outside services an agent can reach, the fewer places a leaked secret can end up.

Done looks like: a written list of the services agents can reach, with every other address blocked, and the owner's name next to each exception.

5. Human approval before production#

No agent change reaches your customers until a person has read it and said yes.

This is the limit that matters most. An agent can propose a change. A person reviews it and approves it. Only then does it go to production. The same rule covers database changes, changes to the cloud setup, and anything that touches money, customer data, or permissions.

Ask your developers to enforce this with settings, because good intentions don't hold under deadline pressure:

• The shared code that ships to customers is locked, so no change goes in until the automatic tests pass and someone other than its author approves it.
• An agent's work counts as the author's. The developer who ran the agent can't approve it alone; a second person reviews it.
• Agents can't deploy to production. Their accounts don't have that permission at all.
• Changes to the cloud setup or the database follow the same review, never a direct command from an agent.

Review takes time, and agents make writing code fast, so review becomes the slowest step. That's expected. Keep the changes small enough that a person can actually read them.

Done looks like: your developers can show you the settings that block an unapproved change, and an agent's account has no permission to deploy.

The one exception is a founder who builds alone, with no second person to review. There, an independent agent review and your explicit go-ahead replace the second reviewer, and the step that lands your approved change also deploys it. The same exception covers agents working in your own signed-in session and local development keys in an ignored file. The Solo Shaped Kanban Playbook lists each exception and what replaces it. It ends the day a second person writes or reviews code.

6. Activity logs#

If you can't see what an agent did, you can't tell whether something went wrong.

Ask for a record of what each agent did: what it was asked, which files it changed, which commands it ran, which services it called, and which account it used. Most agent products and code hosting services can keep this record. The developers need to switch it on and keep it.

Two rules make the record useful:

• Keep it somewhere the agent can't edit or delete. A log the agent can change proves nothing.
• Keep it long enough to look back after a problem. A sensible starting point is 90 days; your developers can tell you what the services they use allow.

You won't read these logs every week. The owner checks them when something looks wrong, and once a month looks at a sample to confirm agents only did what they were asked.

Done looks like: the owner can show you, for any day last month, what each agent changed and which account it used.

7. The emergency brake#

You need one way to stop every agent at once, and you need to know it works before the day you use it.

The emergency brake is a written, tested procedure that stops all agents, removes their access, and keeps them stopped until a person decides otherwise. It usually has four steps:

1. Stop every running agent.
2. Switch off the agents' accounts and revoke their keys, so a stopped agent can't restart on its own.
3. Change any secret an agent might have seen.
4. Check the activity logs for what the agents did in the hours before.

Write down who can pull the brake. The owner and their backup, at least. You should be able to ask for it too, and get it, without a debate.

Then practice. Once a quarter, the owner runs the brake on a quiet afternoon and times it. If it takes more than about 15 minutes to stop everything, or if a step fails, fix it before the next drill.

Done looks like: a written procedure, a named person who can run it, and the date and time of the last drill.

8. Request and spend limits#

A stuck agent can make thousands of requests overnight, and you find out when the bill arrives.

AI providers and cloud services charge by use. An agent caught in a loop, retrying the same failing step, can run up a large bill or hit a service's limits for your whole product. Ask your developers to set caps:

• A monthly spending limit on each AI provider account, with an alert at half of it.
• A cap on how many requests or how long a single agent task can run before it stops and waits for a person.
• Spending alerts on the cloud accounts the agents use, sent to the owner and to you.

You set the number. Start with what you spend today plus a margin you could lose in a bad week without worry. Name the one person who can approve a raise, and adjust once you see a few months of real bills.

Done looks like: a written spending limit for each account, alerts that reach you, and a cap on how long one agent task can run unattended.

The questions to ask your agency#

Ask these in writing, so the answers become your record. You don't need to judge the technical details. Listen for specifics: names, settings, dates, and things they can show you. A worrying answer is vague, reassuring, or says it's handled without saying how.

If most answers sound like the right column, don't argue about each one. Ask the agency to come back in 2 weeks with the checklist below filled in, and treat that date as a delivery date.

The checklist#

Work through this with your developers or your agency. Each line needs a name and a date when it's done.

Agent permissions checklist

• 1. Owner: one named person answers for every agent, with a named backup.
• 2. Secrets: a written list of what each agent can reach; agents use their own accounts; no production passwords or real customer data.
• 3. Workspace: agents run in an isolated, disposable workspace with no path to production or to other clients' projects.
• 4. Network: agents can reach only the listed services; everything else is blocked.
• 5. Approval: nothing reaches production without a person's approval; agent accounts can't deploy.
• 6. Logs: a record of each agent's actions, kept 90 days where agents can't edit it.
• 7. Emergency brake: a written procedure to stop every agent, last tested on [date].
• 8. Limits: a spending cap and alert on every account; a time cap on unattended tasks.

Owner: [name]. Reviewed with founder on: [date]. Next review: [date].

Recheck it once a quarter, and every time your developers add a new agent, a new tool, or a new person. Run the emergency brake drill at the same review.

Start with the owner#

Name the person who answers for your agents this week, and send your developers the eight questions. The answers tell you where to start.

If nobody on your side can tell whether those answers are good enough, that's what I do as a part-time Fractional CTO.