When Your GenAI Policy Meets Reality: A Governance Framework for AI Tool Integrations
Like most consulting firms, we started getting the question from clients. What are you doing about GenAI? It seemed simple to answer. We use AI tools, we have controls in place, and we are thoughtful about it. Done.
Most GenAI policies follow a predictable path.
First, a general stance: is the use of AI tools permitted or not? For most organizations, the answer is yes, because the pressure from employees and leadership to use these tools is increasingly difficult to resist. That stance gets written into a policy document. Second, an approved tool list: ChatGPT, yes, random consumer apps no, here are the sanctioned options. Users are satisfied, the compliance team has a document, and the organization moves on.
Then agentic AI arrives — tools that not only answer questions but also take action, connect to systems, and execute multi-step tasks. And the organization, having already written its GenAI policy, assumes it is covered. The tool list exists. The stance is documented. Job done. But it is often not done. The policy was written for a different generation of AI capability, and the assumptions baked into it do not hold for tools that can act on your behalf inside your systems.
I found this out firsthand when I sat down to write our own policy, partly to formalize our internal stance, partly to have a credible, documented answer for clients asking exactly that question. The more I dug into the details, the more complex it became.
The specific trigger in my case was this: I wanted to connect my AI assistant to a knowledge management platform I use daily. My policy prohibited agentic AI. The connection I wanted was, by any reasonable definition, read-only. But the policy text caught it anyway, because it prohibited MCP integrations by name — regardless of how they were configured.
That collision forced a more useful question: is the prohibition about the tool, or about what the tool can do?
The Real Problem: Policy Intent vs. Technical Reality
In my experience, the initial driver for a GenAI policy is rarely a principled concern about AI oversight. It is a reactive control. Users are already using whatever they can find — consumer tools, browser extensions, whatever is fastest and most capable. The organization needs to get ahead of it: define an approved list, draw a usage boundary, vet the safer options, and get people onto sanctioned tooling. That is the real motivation, and it is a legitimate one.
The problem is that this framing produces a policy optimized for the wrong threat. It answers the question of which tools are allowed? and stops there. It does not answer what those tools are allowed to do.
That gap does not matter much for a straightforward AI assistant. But it matters significantly once AI tools can connect to external systems and take actions based on what they find. Agentic AI — tools operating via protocols like MCP that allow them to read from and write to your systems — is a different capability class from a chat interface. The approved tool list does not automatically cover it. The usage boundary was not drawn with it in mind.
Consider the difference between these two policy statements:
"MCP integrations are prohibited."
"AI integrations that can write to, modify, or delete data in connected systems without human authorization at each step are prohibited."
The first is easier to write and audit. The second is actually what you mean.
The gap between them matters because modern AI connectors are not binary. They expose individual capabilities — read, write, insert, update, delete — that can be configured independently. A connection that is technically an "MCP integration" can be scoped to read-only at the connector level, making it meaningfully different from one with full write access. Your policy should reflect that distinction.
Four Questions to Ask Before Permitting Any AI Integration
Before any AI tool integration is approved, these four questions should have documented answers.
1. What can this integration technically do?
Not what you intend to use it for. What is it capable of doing? List the available operations: read, search, create, update, delete, move, and comment. This is your actual risk surface, not your intended use case.
2. Which capabilities are disabled at the configuration layer?
The enforcement mechanism matters. A policy statement saying "we will only use this for reading" is a behavioral control. Disabling write capabilities at the API or connector configuration level is a technical control. Technical controls are stronger. They are verifiable and auditable, and do not depend on individual discipline to be upheld.
3. What is the scope of access?
A read-only integration with access to your entire workspace is a different risk profile from one scoped to specific resources. The principle of least privilege applies here as much as it does to human user accounts. Define the minimum access required and enforce it.
4. Is there a human in the loop for every action?
For solo operators and small teams, this often means: Is every interaction explicitly initiated by you in real time during a live session? Scheduled access, background sync, and automated triggers are a different risk category entirely, regardless of whether the underlying operations are read-only.
The Governance Architecture for Small Teams
Large organizations have the luxury of dedicated governance structures: review boards, separate approval chains, and technical auditors. Most SMBs do not. This creates a specific problem: in a solo or small operation, the person writing the policy, implementing the controls, and auditing compliance is often the same person. Self-governance is structurally weak.
This does not mean governance is impossible. It means the controls need to be designed to compensate for the absence of independent oversight. Specifically:
Prefer technical controls over behavioral ones. If the only thing stopping write access is your stated intention not to use it, the control fails the moment you make a mistake or face pressure. If write access is disabled at the connector level, the control holds regardless.
Document configurations as evidence, not just intent. A screenshot of your connector settings, dated and stored with the policy, is auditable evidence of the control. A policy statement saying "we configure integrations read-only" is not.
Keep the exception surface small. The temptation when carving out exceptions to a prohibition is to write a comprehensive exception framework. Resist it. Every condition in an exception is a condition someone has to verify. For a small team, complexity is itself a risk. A narrow, specific exception with a clear technical control is more governable than a sophisticated framework with multiple conditions.
Build in review triggers, not just review schedules. Annual policy reviews are necessary but not sufficient. Define specific events that trigger a re-evaluation: adding a new connector, changing the scope of an existing one, or onboarding a new team member with access.
What This Looks Like in Practice
The policy amendment I ultimately wrote is short. It permits read-only AI connector integrations where:
Write capabilities are disabled at the connector configuration level
The configuration is documented before use
Every interaction is explicitly initiated by an authorized user in real time
The configuration remains subject to the broader agentic AI review
That is four conditions. Each is verifiable. The primary enforcement mechanism is a technical control, not a promise. The documentation requirement creates an audit trail. The human initiation requirement draws a clear line between acceptable and prohibited use patterns.
This does not require a lengthy exception framework. It required asking the right question: what is the actual risk we are trying to control, and what is the minimum viable control that addresses it?
The Broader Lesson
AI governance frameworks are proliferating rapidly, and most are written at the tool-category level because it is the most visible dimension. Tool X is approved. Tool Y is not. MCP integrations are prohibited.
That framing will become increasingly inadequate as AI tools become more configurable, more composable, and more deeply integrated into operational workflows. The question is not whether a tool is permitted. The question is what the tool can do in a given configuration, context, and set of permissions.
But there is a deeper problem than the abstraction level, and it is worth naming directly.
A policy is a preventative control. It states what is and is not permitted. Done well, it is necessary. But it is not sufficient, because prevention is only one layer of a control framework. The other two layers, detection and enforcement, are where most organizations have almost nothing.
Detection means knowing when the policy is being violated or stretched: which AI tools are actually in use, what they connect to, and what actions they take. Most organizations lack the visibility to answer any of those questions reliably. The use of Shadow AI is widespread precisely because it is invisible.
Enforcement means having the technical capability to prevent prohibited actions, not just prohibiting them in a document. As this article has argued, this requires controls at the configuration layer, not the policy layer. Most organizations are not yet building at that layer.
The result is a common pattern: a policy that is carefully written, genuinely well-intentioned, and largely unenforceable in practice. The document exists. The controls do not.
For CTOs and tech leads building these frameworks now: treat the policy as the starting point, not the deliverable. Ask what you can actually see, and what you can actually stop. If the honest answer to both is "not much," that is the gap to close — not the wording of the policy.
The policy is not the control. The configuration is. And without detection, you will not know when either has failed.
Paolo Carner is Managing Director of BARE Consulting B.V., a boutique vCISO and compliance advisory firm based in the Netherlands. He works with European tech SMBs on information security strategy, risk management, and regulatory compliance.
