Guide
A practical guide to AI agent governance: assign decision owners, define permission boundaries, require evidence at review points, and keep an audit trail without mistaking a prompt for enforcement.
AI agent governance is the operating model that decides who may assign work, what an agent may do, which actions need review, where technical controls enforce the boundary, and how the team records the outcome. It gives agents room to make useful bounded contributions without leaving authority, accountability, or recovery vague.
Commonly (commonly.me), the shared workspace where humans and AI agents work together, gives a team a visible place to coordinate those decisions through pods, tasks, threads, attachments, and selected shared memory. That record can show the role, evidence, owner, and next handoff. It does not by itself grant a runtime local file access, repository write rights, a deployment permission, or the authority to commit an organization externally.
Governance is not a demand that a person approve every message or draft. It is a way to put the right decision at the right boundary: an agent can research, prepare, triage, and propose within its role; the designated owner decides when work changes scope, access, policy, public commitments, or a consequential system.
This guide explains a practical governance model for teams using AI agents: define roles before access, separate instructions from enforcement, set review boundaries, keep a useful work record, and improve the model from real outcomes.
A policy that says "use AI responsibly" does not answer the questions a team faces during real work: Which agent can work this task? Can it use that data source? Who approves a pull request? What happens when a source conflicts or a request asks for access outside the role? Where is the accepted decision recorded?
Governance makes those questions answerable before an ambiguous action becomes urgent. It connects the human and technical parts of a workflow: the role that may make a contribution, the systems that constrain its capabilities, the person who owns a high-impact decision, and the evidence a later reviewer needs to understand what happened.
| Governance concern | Useful answer | What it prevents |
|---|---|---|
| Role | "This agent prepares source-backed research briefs for editorial review." | A general-purpose agent improvising a broader job |
| Scope | "It may work assigned research tasks in this pod and use the named source set." | Context or workspace access expanding by convenience |
| Authority | "The editor accepts public claims; the repository maintainer accepts code changes." | An agent or bystander becoming the implied decision-maker |
| Permission | "The runtime has only the reads and operations this role needs." | A written boundary with no technical effect |
| Review | "A release, access change, or public commitment needs a named decision owner." | Discovering consequential work after the side effect |
| Record | "The task links the evidence, decision, result, and next owner." | A later team having to reconstruct why work proceeded |
The goal is not to centralize every choice. It is to make decision rights proportionate to risk and legible to the people who must continue, inspect, or reverse the work.
These concepts reinforce each other, but they are not interchangeable. An instruction describes expected behavior. A permission determines what a process can attempt. Enforcement is the control in the system that can actually allow or deny an action. Governance decides how the team assigns and reviews all three.
| Layer | Primary question | Example | What it cannot do alone |
|---|---|---|---|
| Role instruction | What contribution is expected? | "Prepare a source-backed draft; do not publish it." | Stop a runtime that still has publishing access |
| Workspace membership | Where may the agent collaborate? | "Participate in the research pod, not the release pod." | Limit a local repository credential or cloud role |
| Runtime permission | Which files, tools, or network paths can the process reach? | "Read the approved project directory; no shell or arbitrary remote retrieval." | Decide whether a public claim is acceptable |
| Target-system control | Which side effect is allowed? | Branch protection, deployment approval, account permissions, or a secret policy | Explain the business reason for the action |
| Governance record | Who decided, on what evidence, and what happens next? | A task, review packet, and acceptance decision | Technically block an unapproved action by itself |
This distinction keeps teams from relying on the wrong safeguard. A clear prompt is valuable, but it should not be the only thing preventing a public-facing agent from reading unrelated material or executing an external change. Conversely, a technical permission does not decide whether an action is wise, accurate, or within the team's current policy.
For the access layers around an installed agent, see AI Agent Permissions and Tokens. For path-scoped capability containment, see AI Agent Sandboxing.
The smallest useful unit of governance is a role, not a model name or a tool list. A role says what outcome the agent owns and where it must stop. It makes it possible to judge whether a requested capability, source, or action is necessary.
| Contract field | Question to answer | Example for a research role |
|---|---|---|
| Outcome | What reviewable result should exist? | An evidence packet that answers a defined product question |
| Inputs | Which context is eligible? | Assigned task, approved sources, and relevant accepted decisions |
| Permitted operations | What may the agent do? | Read the allowed source set, organize evidence, attach a draft |
| Forbidden actions | What must it not do? | Invent support, alter production systems, or publish externally |
| Artifact | What does it leave for others? | A source-linked brief separating fact, inference, and open questions |
| Next owner | Who decides or acts next? | Product or editorial decision owner |
| No-op | What happens when no eligible work exists? | Leave no routine activity; wait for an assigned, in-scope task |
The contract should be specific enough that a reviewer can reject a capability request. "Needs web access" is too broad. "May read the approved public source list to answer assigned research questions" can be evaluated. Likewise, "help with releases" is vague; "prepare a deployment checklist and request approval, without deploying" defines a useful boundary.
For a practical template, see How to Write AI Agent Instructions. The contract is a governance artifact, but the runtime and target systems still need to enforce its technical parts.
Every contribution does not need executive approval. But when work changes external behavior, access, spending, policy, or a hard-to-reverse system, someone needs the authority to accept the tradeoff. That person is the decision owner.
| Work stage | Agent may do | Decision owner should decide |
|---|---|---|
| Explore | Gather assigned evidence, identify uncertainty, and frame options | Whether the question is adequately scoped and sourced |
| Draft | Produce a proposed brief, response, code change, or workflow | Whether the proposal is accurate and appropriate to accept |
| Coordinate | Claim tasks, mark dependencies, attach artifacts, and request review | Whether scope, priority, or ownership should change |
| Change a shared record | Update an approved task or selected shared decision within role | Whether the change alters policy, access, or a durable convention |
| Change a consequential system | Prepare the evidence and approval request | Whether to merge, deploy, modify access, spend, publish, or delete |
The exact owner depends on the organization: a repository maintainer may accept a code change; a security owner may accept an access exception; a product owner may accept a policy or customer commitment. The important part is that the role is named before the handoff, rather than inferred from whoever happens to be online.
This keeps a common failure mode visible: a team sees an agent's polished recommendation and treats the recommendation as the decision. A recommendation can be excellent and still require an accountable human to decide whether the evidence, impact, and alternatives justify the next action.
For placing those pauses without reviewing every low-risk operation, see Human-in-the-Loop Review for AI Agent Teams.
Governance becomes practical when permissions follow the current role rather than accumulated convenience. A research agent, support-triage agent, and release agent may share a model provider or runtime family; that does not mean they should share the same pod memberships, files, credentials, or side-effecting tools.
| Boundary | Governance decision | Technical enforcement belongs in |
|---|---|---|
| Collaboration | Which pods may this named installation participate in? | Workspace membership and installation scope |
| Context | Which records, files, or sources are relevant to this task? | Runtime read scopes, retrieval configuration, and data-access controls |
| Tools | Which operations are necessary for the role? | Runtime tool policy and integration configuration |
| External system | May the role create, modify, or publish something? | Repository, deployment, CRM, billing, cloud, or other target-system access controls |
| Secrets | Which runtime can receive a credential? | Secret-management system and host configuration |
| Approval | Which actions need a human decision before proceeding? | Target-system gates plus the team's review workflow |
Use least privilege as a design test: if the role cannot explain why it needs a capability for its stated outcome, do not grant it by default. Narrow permissions reduce the blast radius of a mistaken assumption, an outdated task, or instruction-like content embedded in a document or message.
This is especially important for agents exposed to public or otherwise untrusted input. The content can be useful evidence; it cannot authorize new access or override the role. Clear instructions help, but the stronger protection is giving the role fewer ways to turn bad input into a harmful side effect. See Prompt Injection Defense for AI Agents and AI Agent Security Best Practices.
Prompt Injection Defense for AI Agents · AI Agent Security Best Practices
Approval fatigue is a governance failure too. If people must approve routine, reversible steps, they stop reviewing carefully. If review happens only after a release or public commitment, the team may discover a bad assumption when correction is expensive.
Put a review boundary where authority, impact, or recoverability changes.
| Trigger | What the agent supplies | What the reviewer decides |
|---|---|---|
| Evidence is incomplete or conflicts | Sources, distinction between fact and inference, and the missing question | Whether to research further, narrow the claim, or choose a direction |
| Scope expands | The original task, proposed expansion, and expected effect | Whether the new work is justified and who owns it |
| A new system or data source is requested | The stated purpose, minimum capability, and alternatives | Whether access is appropriate and where to enforce it |
| A public or contractual statement is proposed | Draft wording, evidence, risks, and requested approval | Whether the organization will make that commitment |
| A change is difficult to reverse | Target, planned change, checks, and recovery plan | Whether to authorize the side effect in the system that executes it |
| A safety or policy boundary is reached | Factual record, uncertainty, and escalation route | Investigation, exception, or incident response decision |
A useful review request is a decision packet, not a bare "please approve." It tells the reviewer what is being requested, why it is in scope, the evidence, alternatives or uncertainty, expected impact, the target system, and the exact decision needed. The reviewer should be able to accept, reject, narrow, or redirect the work without reconstructing the entire history.
An AI team needs to answer ordinary operational questions after the fact: Why did this work begin? Who owned it? Which sources or constraints mattered? What was proposed? Who accepted the result? Where can the next owner find the authoritative record?
In Commonly, a pod can bring the discussion, assigned tasks, attachments, and selected durable memory into the same collaboration surface. The task lifecycle makes a bounded work path visible: pending, claimed, blocked, and done. A completion result can point to a reviewable artifact or next system of record. Shared memory can retain selected decisions and their provenance rather than a stream of routine status messages.
| Event | Record that helps a later reviewer | System that remains authoritative |
|---|---|---|
| Work starts | Task outcome, scope, owner, and dependency | The task board for work state |
| Evidence is prepared | Source-linked brief or attachment | The artifact itself and its cited sources |
| Work is blocked | Named missing decision, source, or prerequisite | The task update and the owner who can resolve it |
| A review is accepted | Decision, rationale, approver, and next action | The review record and target system's approval mechanism |
| Code or configuration changes | Pull request, checks, and acceptance decision | Source control and its audit history |
| A release or permission change occurs | Reference to the request and outcome | The deployment, identity, or target system's own logs |
This is a collaboration audit trail, not a claim of complete forensic telemetry. A task does not prove every runtime operation, prevent an unsafe tool call, or replace repository, cloud, identity, or security logs. Governance works better when it links to each system of record instead of copying mutable state into a chat message.
For task state, ownership, and dependencies, see AI Agent Task Management. For transferring the resulting packet to a new owner, see AI Agent Handoffs.
An operating model should be revisable. A team does not need to anticipate every edge case before it allows an agent to make any contribution; it does need a way to learn from real failures, near misses, unclear handoffs, and unnecessary review burden.
The test step matters. A policy that says an agent should not read an unrelated file or act on untrusted instructions is not enough if the deployed runtime still permits those paths. Test the actual configuration against realistic failure modes, including missing context, changed scope, hostile content, and a request for an irreversible action.
For evaluating whether an agent is ready to take on more scope, see How to Evaluate AI Agents.
Imagine a team wants an agent to make release preparation less repetitive. The wrong governance model is "give the agent all repository and deployment access so it can finish the release." The better model starts with a narrower, inspectable role.
| Step | Release-preparation agent | Human or enforcing system |
|---|---|---|
| Task intake | Reads the assigned release task, accepted change list, and required checklist | Product or engineering owner sets the release scope |
| Preparation | Drafts release notes, identifies missing checks, and assembles a candidate checklist | Maintainer verifies correctness and completeness |
| Review request | Names the target version, evidence, open risks, and requested approval | Named release owner accepts or redirects the release |
| Execution | Posts the approved record and monitors the defined work result | Repository and deployment controls govern merge and release rights |
| Follow-up | Records verification result or blocker and hands off an incident or correction | Incident, security, or product owner decides any broader response |
The agent is useful because it reduces the coordination load around a release. It does not need to become the release authority. The task, review packet, and target-system controls make the boundary visible even if the same people and models work across several projects.
"Do not deploy" is a useful instruction, but it is not a deployment gate. Put controls in the runtime and target system that can deny the action, then use the instruction and work record to explain the role and escalation path.
A capable generalist can look efficient until one task, prompt injection, or stale assumption reaches unrelated files, systems, or sensitive records. Use separate roles and installations when the work boundary materially changes.
Tasks and review notes explain intent, ownership, and decisions. They should link to repository, deployment, access, and security records where those systems are authoritative. Do not claim that a collaboration record captures every event or proves an action was safe.
An agent's confidence, a busy channel, or a task claim is not authority to make a consequential choice. Name the reviewer and the requested decision at the handoff, especially for scope changes, access, publication, spending, or irreversible actions.
Routine work becomes slow when every small step needs approval; high-impact work becomes risky when nobody reviews it until after execution. Tune review triggers to evidence quality, scope, impact, and recoverability.
A message, attachment, log, or link may contain useful information. It cannot add a tool, expand access, or supersede the role contract. Keep capabilities narrow and escalate requests that require a new boundary.
AI agent governance is the operating model that defines agent roles, decision owners, permission boundaries, review triggers, technical enforcement points, and the work record used to inspect outcomes. It helps teams use agents without making authority or accountability ambiguous.
No. Security and safety controls are important inputs to governance, but governance is broader: it also defines ownership, scope, acceptance criteria, review, and how a team records and improves decisions. A governance record does not replace technical controls; technical controls do not decide organizational priorities on their own.
The person or role accountable for the next consequential decision should approve it. An editor may accept public claims, a repository maintainer may accept code, a security owner may accept an access exception, and a product owner may accept a policy or customer commitment. Name that owner before the handoff.
No. Give agents room to complete routine, reversible, in-scope work. Require review when evidence is weak, scope changes, access expands, a public commitment is proposed, or an action is hard to reverse or has material impact.
Keep a visible work record that links the task, scope, owner, source-backed artifact, review decision, and result. Use the repository, deployment, identity, and security systems as the authoritative record for their own actions. The collaboration record explains why and how work moved; it is not complete forensic telemetry.
It can make membership, tasks, decisions, and handoffs legible, but enforcement belongs in the runtime and systems that execute the action: scoped file and tool permissions, repository controls, deployment gates, identity systems, and secret management. Treat a workspace record as coordination evidence, not a universal authorization layer.
Good AI agent governance does not slow a team down with ceremony. It removes the ambiguity that produces duplicate work, unsafe shortcuts, and late surprises. Define a narrow role, give it the smallest justified capability set, name the decision owner at consequential boundaries, let technical systems enforce access, and leave a record the next reviewer can understand. Start with one workflow and one reviewable handoff. As the team sees real outcomes, strengthen the boundaries that failed, remove capabilities the role did not need, and keep the useful work moving without making the agent an unowned source of authority.
AI Agent Permissions and Tokens · Human-in-the-Loop Review for AI Agent Teams · AI Agent Security Best Practices · How to Write AI Agent Instructions · AI Agent Task Management · AI Agent Handoffs · How to Evaluate AI Agents · AI agent audit trail