# AI Agent Approvals and Permission Boundaries

Canonical page: https://2bcome.ai/docs/approvals-and-permissions/
Content updated: 2026-09-15

PRODUCT DESIGN NOTES 5 min read

# Approvals and permissions.

The proposed rules for what an agent may read, prepare, change, and publish, with defaults that keep sensitive actions out of scope.

By [2bcome](https://2bcome.ai/about/) Written September 15, 2026 Updated September 15, 2026

Product design notes. The agent platform is in development; these are not instructions for a live service.

## Start with read and prepare

The proposed initial workflow allows an agent to read approved sources and prepare a change. Publication is a separate action that requires explicit permission.

This page describes the intended model. It does not claim that the controls are already implemented in a running agent platform.

## Four practical levels

Level
Intended capability
Typical output

Observe
Read approved site and performance sources
Evidence summary

Prepare
Draft a change within an allowed workspace
Brief, draft, or branch

Review
Evaluate a specific proposed revision
Approval or requested changes

Publish
Release an approved revision
Deployment record

Permissions should be assigned to the task and enforced by the software around the model. A text instruction on its own is not the control system.

## Define allowed paths and prohibited actions

A content task can allow one directory while leaving the rest of the repository unavailable for edits.

The default exclusions should cover secrets, authentication, billing, pricing, legal pages, DNS, and unrelated infrastructure. Changes to dependencies and shared components should also need explicit authorization when they exceed the brief.

The agent should stop when it cannot complete the task inside the boundary, rather than finding a way around it.

## Approval belongs to a revision

An approval should identify the actual diff or revision that was reviewed. A changed draft needs another review when the change is material.

The workflow should preserve the evidence, validation output, reviewer decision, and eventual deployment reference together. That makes it possible to reconstruct what was authorized.

## Budget and failure controls

The proposed task configuration should include a maximum number of tool calls, model spending limits, a time limit, and a bounded retry policy.

Repeated build failures, missing sources, ambiguous instructions, or exhausted budgets should pause the workflow and produce a useful explanation for a person.

## Broader autonomy is optional

Some low-risk changes may eventually qualify for automatic publication after the surrounding controls are proven. That is a separate design decision, not a prerequisite for using an agent.

An agent that reliably prepares good changes for review can already be useful. Removing the approval step is not the only measure of progress.

[Try the sample approval step](https://2bcome.ai/how-it-works/#demo) or read [audit history and rollback](https://2bcome.ai/docs/audit-and-rollback/).

CONNECTED WORK

## The next useful connection.

FIELD NOTE

### [AI Agent Permissions before Autonomy](https://2bcome.ai/blog/permissions-before-autonomy/)

The control model we want before allowing an agent to edit a live website: defined scope, reviewable diffs, and explicit publication rights.

[Explore](https://2bcome.ai/blog/permissions-before-autonomy/)

GUIDE

### [AI Agent Audit Trails and Website Rollback](https://2bcome.ai/docs/audit-and-rollback/)

The proposed audit record connecting a goal, evidence, draft, approval, tests, and deployed revision.

[Explore](https://2bcome.ai/docs/audit-and-rollback/)

SPECIALIST

### [AI Website Agent for Reviewable Site Changes](https://2bcome.ai/agents/web-agent/)

Explore a Git-first AI Website Agent designed to make scoped website changes, run checks, and prepare reviewable diffs before an approved deployment.

[Explore](https://2bcome.ai/agents/web-agent/)