Isolation and Least Privilege

Why this matters

An agent or automated system should only be able to do what it needs for its specific job — and nothing more. The extra access is not a convenience; it is a failure mode waiting for a trigger. Broad access is convenient until the day the system does something you did not expect, and on that day the breadth of the access decides how bad it is.

What you will be able to decide after this

• What the minimum permission is for each tool and system — not the convenient permission.
• Which actions are irreversible, and how they are gated.
• Whether the solution can be shut down quickly and by whom.

Core lesson

Five practices carry the weight:

• Run agents in isolated environments when the actions have real side effects. The isolated environment exists so a wrong action happens in a place that can be thrown away. If the agent can touch production data or send real messages, it runs where its mistakes are contained.
• Give the minimum tool access required (least privilege). Start from zero and add what the job needs. Nobody has ever regretted the permissions they did not grant.
• Prefer scoped, revocable credentials over broad keys. A key that can do everything is a key that does everything — until the day you revoke it and find out what it was actually touching. Scoped credentials fail small and rotate cleanly.
• Separate the ability to propose from the ability to execute irreversible actions. The agent drafts; execution goes through a mechanism that requires a person — a confirmation, a gate, a separate credential. This is the same separation as Module 3's agent structure and the "no silent auto-advance" constraint from the Workflow pack.
• Make it easy to shut the agent down. A single switch, owned by a named person. If stopping the system requires logging into three consoles, it is not easy to shut down.

The test for every line of the permission list: "What would this access be used for, exactly?" A line that cannot be answered with the agent's actual job is over-scoped.

Worked example

The answer-drafting agent from Module 1, permission list: the two knowledge bases — read-only, scoped to the specific document folders, via a service credential that rotates quarterly and can be revoked per integration. The portal — read questions, write drafts to a review queue only; no direct send. No ticketing access. No customer data beyond the question content. No internet access. The one irreversible action is sending an answer, and it is gated: the agent's output lands in the review queue, and only a human's explicit action sends it. The kill switch is a single credential revoke, owned by the support lead. Then the technical reviewer catches the over-scope: the first draft of the list included read access to the entire knowledge base suite "in case." Reduced to the two named folders.

Practice

For your use case, list every tool and system the solution would touch. For each, write the minimum permission in one sentence, and mark the ones you are unsure about. Note which actions would be irreversible.

Apply — produce the artifact

For the use case in Module 1, list every tool, system, or data source the solution would need. For each one, define the minimum permission required and how access would be revoked. Note any irreversible actions and how they are gated.

Verify

Walk the permission list with someone technical enough to spot over-scoping. If any access is broader than the job requires, reduce it.

Sources

This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.