An AI agent governance checklist is a record of who can use an agent, what it can access, when a person must approve an action and how the team verifies the result. Write those decisions for one real workflow before adding the agent to a shared Slack channel. Review the policy after the first few runs, when you can see where the work needed more access or more human judgment.
This guide is for an operations owner and the IT or security colleague helping them run a pilot. It provides a sample policy you can adapt, plus the questions that should be answered before the pilot starts. It does not certify a deployment or replace your organization's legal and security review.
What should the first policy cover?
Start with an outcome people can check. For example, a sales team wants a weekly list of open deals that need a reply. The agent may need to read CRM records and meeting notes, then prepare follow-up drafts. Sending those emails is a separate decision, even if the agent drafted them in the same conversation.
The NIST AI Risk Management Framework calls for "organizational roles and responsibilities clearly defined" and periodic review of the risk process. For a small pilot, that means naming the workflow owner, the person who manages access and the person who can approve consequential actions. Give each person a concrete decision to make.
Record five things before the first run:
- Purpose and owner. What result is expected, who checks it and what would make the pilot unsuccessful?
- People and channel. Who may request work here, who may change the settings and who sees the thread?
- Sources and accounts. Which files and connected apps are available, under whose identity, and for what purpose?
- Actions and review. Which work may proceed, which changes need an approval decision and who makes it?
- Evidence and retention. Where do the request, sources, approval and verified result live, and how long are they kept?
Who should be allowed to ask and to approve?
Separate permission to use the agent from permission to authorize a change. A sales manager may request a deal review, while the deal owner approves a message to a customer. An IT administrator may configure the channel without being the right person to approve sales content.
In ChannelGate, approved users and explicit channel guests can be admitted to a channel. Read-only, Worker and Admin modes set base tool access, while approval behavior is configured separately. A person who can mention the agent still needs the relevant channel tools and accounts for the requested work. The governance page explains these product controls in more detail.
For the pilot, list names or job roles for three decisions: who may request work, who may change the agent's access and who may approve each category of external action. Include an alternate approver for absences. If nobody owns a decision, leave that action out of scope until someone does.
Which sources and connected accounts may the agent use?
Write down the minimum records needed for the workflow and the account that supplies each one. "CRM access" is too vague. Specify the connected workspace, relevant objects and whether the agent needs to read, draft or modify them. Revisit the list when the agent reports that a source is missing.
ChannelGate separates the requester's personal connection from a shared agent connection. That distinction matters in a shared thread: a colleague's message does not become permission to use another person's personal account. The connections page explains how the two identities are configured. For a company mailbox or CRM service account, name its owner and approved use in the policy.
Also record where the information can go. The documented data flow says the selected model provider may receive prompt and context, while enabled connectors send selected tool requests to their external services. The deployment owner remains responsible for provider selection, retention, deletion and the data appropriate to the workflow. A deployment on your own Linux host does not make every interaction local.
Which actions need a person to approve them?
Set the review point by what the action changes. The table below is a sample policy for a deal-review pilot, not a statement about ChannelGate's default settings. Configure tool permissions and approval behavior to match your own policy, and check where a human must review the output even when the tool itself does not pause.
| Proposed work | Pilot policy | Owner's check |
|---|---|---|
| Read permitted deal and meeting records | Allow for named pilot members | Are the expected sources present? |
| Summarize a deal and draft a reply | Return a draft for review | Are the facts and recipient correct? |
| Change a CRM owner or deal stage | Require the deal owner's approval | Did the intended record change? |
| Send an external email | Require the sender's approval through the intended account | Was the right message delivered once? |
| Invite another user or add a new connector | Require the access owner's decision | Does the new grant match the pilot scope? |
This distinction is operational, not ceremonial. A draft can be useful while still containing a wrong date or stale CRM status. An approved action can also fail in the destination system. Check the destination record after the action and record any correction needed. The Slack operations guide shows how review points fit into several workflows; this checklist captures the decisions for one pilot.
What evidence should the team keep?
Keep the original request, the sources used, the proposed action, the approval decision and the observed result together when possible. For external changes, include a link or identifier for the destination record. That lets the owner distinguish a convincing response from a completed action.
ChannelGate documents conversation history, usage records and administrative events. Those records help operators review activity, but they do not replace inspection of the CRM record, email or file that the workflow changed. Define how long your organization retains those records, generated files and backups; deleting a Slack message does not automatically erase copies held by a model provider or connector, as the privacy documentation explains.
After each pilot run, note three things: whether the requested outcome was correct, how much human review it took and whether the configured access was too wide or too narrow. A recurring error is a reason to revise the procedure or source list before expanding access.
What could a one-page pilot policy say?
Use this as a starting record. Replace every bracketed field with a named person, account or source before an agent begins work.
Workflow: Each Monday, prepare a list of open deals needing a reply, with source links and follow-up drafts.
Owner and reviewers: [Sales operations owner] checks the list. [Deal owner] reviews each customer-facing draft. [IT owner] manages channel access and connectors.
Channel and people: [Slack channel] is available to [named pilot group]. [IT owner] approves changes to membership and tool grants.
Permitted inputs: [Named CRM view], [approved meeting notes] and [approved mailbox or shared account]. The agent reports missing sources rather than inferring them.
Permitted output: A sourced list and drafts in the Slack thread. The agent may not send a customer message or change a CRM record without the relevant owner's approval and the intended connected account.
Verification: The deal owner checks each proposed update and verifies any approved change in the destination system. [Pilot owner] records corrections and review time.
Review date: [Date after the first few runs]. Expand the pilot only after the owner has inspected the results, access and review burden.
The policy is short enough to be used during work. If the team cannot fill in an account owner or an approval point, that is a useful discovery before granting access.
Frequently asked questions
Does every agent action need approval?
No single approval rule fits every action. Decide where a person must inspect a draft, where a tool action requires authorization and where the result needs verification. ChannelGate's approval behavior depends on its configured mode and tool permissions; this checklist is a proposed pilot policy, not the product's default.
Is access to the Slack channel enough to use a connected app?
No. The workflow also needs the relevant tool grant and a connected account. Personal connections belong to the authenticated requester, while shared connections are separately configured for channel work. See the documented connection model.
Can a self-hosted deployment keep every request inside the company?
The deployment's workspace and runtime are under the operator's control, but the selected model provider may receive prompt and context. Connected apps receive selected tool requests when used. Review the privacy and data-flow documentation before approving sensitive inputs.