Writing a first AI use policy before you buy anything

Why write the policy first?

A product enforces rules. Without rules, a new control either blocks too much, which drives people away, or too little, which helps nobody. Writing the policy first forces the decisions a product cannot make for you: which tools are allowed, which data may go where, and who decides about new ones.

For some companies the policy is the whole answer for now. In the finder, a handful of users, general information or unmanaged devices push the result toward policy before a product. The policy-only guide lists the signs that it is time to add one.

What should the policy cover?

1. Approved AI tools, with the teams allowed to use each and the data classes allowed in each.
2. What must never go into any AI tool, stated plainly: credentials, specific regulated data, customer files without a contract that allows it.
3. Coding agents and MCP servers: which agents are approved, which MCP servers may be connected, and who approves a new one.
4. Tool settings: the administrator settings each approved tool offers, such as permission prompts and allowed MCP servers, and how they are set.
5. Exceptions: how to ask, who answers, and how fast.
6. Review: who owns the policy and when it is revisited.

How should the policy handle AI agents?

Agents need more than a data rule, because they act. The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation before sensitive operations. A good first policy tells people not to switch those prompts off, and names the actions that always need a person's approval, such as installing packages, running commands against production, or connecting a new MCP server.

The OWASP GenAI Security Project ranks excessive agency third in its 2026 Top 10 for LLM Applications. A policy that gives agents only the tools and permissions their task needs is the cheapest defence against it.

How do you keep it from going stale?

• Name an owner and a review date, at least every quarter while AI tools change this fast.
• Keep the approved-tools list in one place people can find.
• Track requests for new tools; a pile of requests is a sign people need something the list does not have.
• Revisit the finder when coding agents arrive, when AI use spreads, or when the data at stake changes.

How long should the first version take?

Days, not months. A first version that names the approved tools, the data rules and the review owner is more useful this month than a complete one next quarter. Share it, collect the questions people ask, and fold the answers into the next version. Those questions also show where a product would help, because they point to the things people cannot check for themselves.

Sources