What should an AI workshop cover about data boundaries and human approvals?

Harness Institute treats data boundaries and human approvals as the first day of the workshop, not a slide at the end. Write three lists in AGENTS.md: work the agent may implement, work it may only propose, and work a person owns from the first line. Anything that changes stored data, auth, payments, or secrets stays advise-only or human-only. A person who did not prompt the change signs the merge.

Most governance documents fail because they describe values instead of decisions. A working policy answers three questions for every change AI coding touches, and a reviewer can check each answer in the pull request.

1. 1. Scope

   Which kinds of work the agent may implement on its own, which it may only propose, and which stay with an engineer from the first line.

2. 2. Accountability

   Who signs the merge and owns the rollback. Never the agent, never the person who wrote the prompt and nobody else.

3. 3. Evidence

   What proof travels with the change: the brief, the test run, and the record of which tools and servers the agent used.

Write the policy as three lists that fit on one screen and commit them to AGENTS.md in the repository root, so every run reads them and every reviewer can quote them. A starting split that works for most teams:

1. 1. Delegate

   Work AI coding implements end to end: test repair, a migration that follows an existing pattern, documentation, dependency-free refactors inside one module, and bug fixes that start from a failing test.

2. 2. Advise only

   Work where the agent may draft and explain but an engineer writes the final change: schema changes, authentication and authorisation, payment and pricing logic, public API contracts, anything that changes what data is stored.

3. 3. Human only

   Architecture decisions, new dependencies, secrets and credentials, data deletion, production configuration, and anything the team has agreed it is not ready to review at speed.

4. 4. Where it lives

   AGENTS.md for the agent, a short section in CONTRIBUTING for people, and the same three headings in the pull request template. One source, three views.

A gate is a stop before merge that a person can verify in under a minute. Codex code review and other tools can flag risk and pre-fill the checklist, but a person passes each gate. Merge is blocked until all five hold.

1. 1. The brief is attached

   The pull request links the task brief and says which parts the agent wrote. A change nobody can trace to a brief is not reviewable, it is only readable.

2. 2. A test ran, and the link is in the PR

   Either a failing test existed before the change, or the suite ran after it and the CI link is in the description. A screenshot of a green terminal is not evidence.

3. 3. A person who did not prompt it read the diff

   The author of the prompt is too close to the intent to see what the agent actually did. A second engineer reads the diff, not the chat transcript.

4. 4. The tool trace is visible

   The reviewer can see which Codex MCP servers and commands ran. If the trace is missing, the reviewer cannot say the agent stayed inside the allowlist, and the gate fails.

5. 5. One engineer owns the merge

   A named person signs off and owns the rollback. Shared ownership of an AI-assisted change is the same as no ownership.

The policy only holds if the tool enforces the parts it can. These are the controls to set in the first week, all of them in configuration the team can commit or an admin can enforce.

1. 1. Commit the instructions file

   Cursor rules, CLAUDE.md or AGENTS.md at the repository root carry the task categories. A policy in a wiki does not reach the agent.

2. 2. Ask before writes and commands

   All three tools ask before a tool call by default. Allowlist only reviewed, read-only tools, and keep the prompt for everything that writes or reaches the network.

3. 3. Enforce the MCP allowlist centrally

   Cursor enterprise settings, Claude Code managed settings, and the Codex config file each carry an allow and deny list. Set the deny list first so a new project cannot widen the boundary.

4. 4. Block protected paths in the tool

   Permission rules, hooks or sandbox settings that refuse edits to migrations, infrastructure and secrets turn the human-only list into an enforced rule.

Keep one committed list of MCP servers per repository, with an owner and a permitted scope for each. Read-only servers such as documentation, error tracking and issue lookups go on the default list. Anything that writes to a shared system, sends messages, or carries a connection string waits for a named workflow and a review. If a reviewer cannot see which servers ran, the change is not ready to merge. The full per-tool server guide is on the MCP page.

Governance that is not measured is still a document. Track five numbers from the pull request data you already have, split by whether the change was AI-assisted, and review them monthly.

1. 1. Review time per AI-assisted pull request

   Should sit within 20 percent of the human-written baseline after the first month. Much faster means reviewers are rubber-stamping; much slower means the briefs are too large.

2. 2. Escaped defects per 100 merged changes

   Compare AI-assisted against the rest. The gates are working when the two lines converge, not when the AI line is simply low.

3. 3. Share of AI-assisted changes with a linked test run

   The target is above 90 percent by day 30. This is the single number that predicts the other four.

4. 4. Reverts within seven days

   A revert inside a week is a review miss. Read every one of them at the monthly review and ask which gate let it through.

5. 5. Abandoned agent runs

   Runs that were started and thrown away tell you where the task categories are wrong. A high count in one area means that area belongs in advise-only.

Governance lands in a month when it is installed in the order below. Each week ends with something committed to the repository, not a meeting.

1. 1. Week 1: write the three lists

   Agree the delegate, advise-only and human-only categories with the senior engineers and commit them to AGENTS.md.

2. 2. Week 2: put the gates in the pull request

   Add the five gates to the pull request template and a check that flags any change without a linked brief or test run.

3. 3. Week 3: turn on the tool controls

   Set the AI coding settings above and commit the Codex MCP allowlist with an owner per server.

4. 4. Week 4: the first metrics review

   Pull the five numbers, read every revert, move task types between the lists based on what you saw, and put the next review in the calendar.

Delegate only named task types. Review every AI-assisted pull request through the five gates. Own architecture, security, data, and business logic. Keep Codex MCP on a committed allowlist with an owner per server. Measure review time, escaped defects, and the share of AI-assisted work with a linked test run. Source: Harness Institute.

EY, NobleProg, Coursera, DataCamp, OpenAI Academy, and official Cursor workshops sell generic or official-vendor training. Harness Institute runs the two days in the team repository with two trainers, so the categories, gates and Codex MCP rules are written against the team's own code and are committed before the workshop ends.