AI Acceptable Use Policy for an AI Workspace

An AI acceptable use policy is the set of rules for how a company’s people may use AI at work: which providers may see company data, what may be connected and shared, which actions need a person, and what AI may spend. This template maps thirteen clauses to the Insulin settings that enforce them and marks the ones only people can keep. It is a starting point, not legal advice.

---

Most AI acceptable use policies are written from a template before the rollout, and every clause in them reads as equally firm. In an AI workspace they aren’t, and Insulin’s guide to finding and governing shadow AI puts the test in one line: a control you cannot enforce is not a control. So every clause below carries one of three statuses, each traced to Insulin’s documentation:

• Enforced: a setting makes the clause true, whatever people do.
• Partly: a setting holds part of the clause, and people hold the rest.
• On paper: no setting holds it, so the policy relies on people.

What should an AI acceptable use policy cover?

An AI acceptable use policy should cover which AI providers may see company data and on whose keys, who may connect systems and share agents, which actions need a person, what AI may spend, and what people can see and add for themselves. The template below puts that in thirteen clauses: three enforced, seven partly enforced and three on paper.

#	Clause	Status	Enforced by, and who owns it
1	Only approved AI providers may serve company prompts	Enforced, once the list has a row	The AI Model Policy allow-list; an org ADMIN. An empty list means no restriction
2	No AI runs on Fours’ shared keys	Enforced	The platform-key fallback toggle, switched off; an org ADMIN. It fails closed
3	AI runs only on keys the company contracts for	Partly	Organization agents use the organization’s keys; the built-in assistant and personal agents use each member’s own
4	Company data isn’t used to train AI models	On paper	No setting: what Fours and each provider may do with your data is in their terms
5	Only approved people connect company systems to AI	Partly	Organization integrations: an org ADMIN only. Personal connections: each member connects their own
6	Only admins give everyone an agent	Enforced	Only an org ADMIN creates an organization agent, the only kind that can be shared; no org-wide share grants ADMIN
7	No credentials or restricted data in an agent’s instructions	On paper	No setting: everyone the agent is shared with sees its full configuration
8	A person reviews AI-drafted email before it’s sent	Partly	Approvals ▸ Pending holds drafts, but each member can write an auto-send rule for their own mailbox
9	AI doesn’t change business records unattended	Partly	Inbox CRM actions wait for Run in chat; elsewhere, each connection’s credential
10	AI spending stays under a monthly cap	Partly	The monthly spending limit blocks rather than warns, on Insulin spend only. Settings → Billing isn’t restricted to admins, so a member may change it
11	People can see and correct what the AI remembers	Partly	Settings → Personal → Memory, by each member for their own; memories shared across the organization are locked
12	Outside skills are reviewed before agents use them	Partly	Marketplace’s Organization store: an org ADMIN only. The Personal store: each member, with no admin review
13	Unattended AI jobs are visible to someone besides their creator	On paper	No setting: a job is private to its creator, org admins included

An enforced clause holds only once its setting is set: an empty allow-list restricts nothing, and the platform-key fallback toggle is on by default. Set them in the order of the AI workspace admin checklist, because two of these settings fail closed. For every partly or on-paper clause, the policy should name who keeps it and how they’ll check, since no setting will. And have the wording reviewed against your own obligations: this template is a starting point, not legal advice.

Which AI providers and keys may serve company prompts?

Approved providers and no AI on Fours’ shared keys are enforced, both on Settings → Organization → AI Model Policy, which only an org ADMIN can change. Company-contracted keys are partly enforced and no training is on paper: the policy decides which providers serve your prompts, not whose key pays for them or what anyone’s terms allow.

1. Approved providers only (enforced, once the list has a row). The AI Model Policy’s Allowed AI integrations list is an allow-list: “AI features may use only the integrations listed here.” Left empty, it restricts nothing, and the tab says so: “No restriction — every connected provider is allowed.” Every Fours-hosted model resolves through a single entry, the hosted-model (DeepInfra) row, so a non-empty list without it drops the hosted models. Add that row only if the hosted models are approved. Insulin’s AI model allowlist covers what each row admits.

2. No AI on Fours’ shared keys (enforced). The platform-key fallback toggle on the same tab is on by default, and while it’s on, Fours’ shared keys can serve an allowed provider you haven’t connected a key for. Turned off, it makes the organization bring-your-own-key only: every AI call must use one of your own connected keys, and an allowed provider with no key “fails closed rather than quietly falling back to Fours.” The docs call the toggle “a guarantee, not a preference.”

3. Only keys the company contracts for (partly). Organization agents draw on the providers the organization connected. The built-in Insulin assistant and personal agents add the providers each member connected for themselves, and they “never reach the organization’s keys.” The allow-list still applies to them, but it names providers, not whose key a request runs on. If personal keys aren’t allowed, the policy has to say so.

4. No training on company data (on paper). No Insulin setting decides it: what Fours and each model provider may do with your prompts and documents is set by their terms, so read Fours’ terms and each provider’s before the policy approves them. The part Insulin controls is clause 1, because the allow-list decides which providers see your prompts at all. Whether company data is used to train models lists the questions to ask any vendor.

Who may connect systems and share agents?

Only an org ADMIN can connect the organization’s systems or create the agents everyone uses, and both rules hold. What members connect for themselves, and what goes into an agent’s instructions, are left to people.

5. Who connects company systems (partly). Organization integrations sit under Settings → Integrations: any member can see the list, but only an org ADMIN can connect or disconnect them. Personal connections, such as Gmail, Google Calendar, Google Drive and Gong, are per person: each member connects their own, the docs describe no admin step, and they serve only that member’s own agents and apps. If some personal connections are off-limits, name them in the policy.

6. Who gives everyone an agent (enforced). Only an org ADMIN can create an organization agent or install one from Marketplace’s Organization store; for everyone else, the Organization option is disabled. Only organization agents can be shared: a personal agent’s Share button is disabled. An org-wide share grants EDITOR or USER, never ADMIN. Share org-wide as USER unless everyone should be able to change the agent’s prompt, model and knowledge bases, which EDITOR allows.

7. No credentials or restricted data in an agent’s instructions (on paper). Everyone an agent is shared with can read its instructions. Below Editor, a shared agent’s settings are read-only, but you see the full configuration, and an org-wide share opens that view to the whole organization. The docs describe no check on what an agent’s instructions contain, so this is a rule people keep. Credentials belong in Settings → Integrations: when an agent reports on its own integrations, “Credentials are never returned.” Who can read your AI agent’s system prompt goes role by role.

When must a person approve what the AI does?

In Inbox, by default: AI-drafted email and CRM actions wait for a person. Both clauses are still only partly enforced, because a member can write an auto-send rule for their own mailbox, and outside Inbox, a connection’s credential decides what an agent can change.

8. A person reviews AI-drafted email (partly). “Insulin never sends email on its own”: every AI-drafted reply waits in Approvals ▸ Pending, and Send needs a second confirmation. The exception is an auto-send rule, which a member writes for their own mailbox on Inbox’s Rules page; the Inbox chat rail refuses to create one. The docs hold it to three limits: one exact filter decides whether it fires, no customer, knowledge-base or integration data goes into what it sends, and a pre-send check holds a flagged reply for review. They describe no organization-wide switch that turns auto-send off, so if the policy allows no auto-send rules, or only some, say which. When the Inbox app acts, and when it asks covers which rules deserve the exception.

9. No records changed unattended (partly). Inbox holds its CRM actions: “A CRM action is never executed silently.” Nothing happens until the member clicks Run in chat, and that run can use only the CRM connection the action came from. Outside Inbox, what an agent can change in a connected system is set by the credential behind that connection. Fours’ Workday integration page puts it in one line: “Every tool runs under the registered API client, so its security-domain grants set the ceiling on what the agent can reach.” Grant write access only where the policy lets an agent write; where read-only access for AI agents is set goes system by system.

Can the policy cap what AI spends?

Partly. The monthly spending limit blocks rather than warns, but it caps only what you spend on Insulin, and the page it’s set on isn’t restricted to administrators.

10. A monthly cap (partly). The limit is set on Settings → Billing. Reaching it pauses AI requests for the rest of the month and stops automatic top-up; adding credit doesn’t clear it, and no setting warns without blocking. On your own provider key, “the provider bills you directly for the tokens under your own contract,” while Fours charges a flat fee per unit, so that bill sits outside the limit. And Settings → Billing isn’t restricted to administrators, with no admin-only view, so a member may change the limit. Two lines belong in the policy: who may change it, and who watches the provider’s bill. When AI does stop, each of the four reasons Insulin pauses AI has its own fix.

What can people see, correct and add for themselves?

Their own AI memory, skills and jobs: any member manages their own, whatever their org role. That leaves memory and outside skills partly enforced, and the visibility of jobs a clause on paper.

11. See and correct what the AI remembers (partly). In Settings → Personal → Memory, a member can search what’s stored, edit a memory, delete one or Clear All, a VIEWER included, and telling the Insulin assistant a memory is wrong corrects it in place. The gap is memories shared across the organization: they’re listed there too, but their Edit and Delete buttons are disabled.

12. Outside skills reviewed first (partly). Marketplace’s Organization store is shown only to org admins, and installs, imports, edits and deletes there require admin access. The Personal store is open to everyone: a member can upload a skill or a .zip package, or import one from GitHub, and no one else reviews it. A .zip package and a GitHub repo, folder or blob URL import directly, with no review form at all. Each skill carries a provenance badge, such as Uploaded or From GitHub, which says where it came from but doesn’t stop it. If outside skills must pass an admin, the policy has to route them through the Organization store.

13. Unattended jobs stay visible (on paper). A job runs within its creator’s scope, with the same resources and integrations they have, and it’s private to them: “only its owner can see it, run it, edit it, or delete it,” org admins included. The exception is work Planner schedules in an organization channel, which belongs to the channel and every member of it sees. If someone besides the creator must know what runs unattended, the policy has to ask creators to tell them.

Frequently asked questions

What is an AI acceptable use policy?

An AI acceptable use policy is the set of rules for how a company’s people use AI at work: which providers may see company data, what may be connected and shared, which actions need a person, and what AI may spend.

Which acceptable use clauses can Insulin enforce?

Three of the thirteen in this template: approved AI providers only, no AI on Fours’ shared keys, and only admins giving everyone an agent. Seven are partly enforced, and three, on model training, agent instructions and unattended jobs, rely on people.

Can our AI policy ban automatically sent email?

It can, but in Insulin the ban is a rule people keep. Every AI-drafted reply waits in Approvals ▸ Pending, yet a member can write an auto-send rule for their own mailbox, and the documentation describes no organization-wide switch that turns auto-send off.

Does Insulin’s spending limit cover our own provider keys?

Not the provider’s bill. The monthly spending limit caps what your organization spends on Insulin, and it blocks rather than warns. On your own key, the provider bills you directly for the tokens under your own contract, so that bill sits outside the limit.

Takeaways

• Three of thirteen clauses are enforced by a setting: approved AI providers, no AI on Fours’ shared keys, and admin-only agents for everyone.
• Seven are partly enforced. Each has a setting on the organization’s side and a gap on the member’s or the provider’s, so the policy has to say who closes it.
• Three are on paper: training on company data, what goes into an agent’s instructions, and who can see unattended jobs. Give every partly and on-paper clause a named owner and a check.

A policy is only as firm as the setting behind each clause. To see where an Insulin agent gets its keys, its connections and its audience, start with AI agents for business workflows.