AI tool approval process: apps, connections and agent actions
Set up an AI tool approval process that is quick for low-risk tools and careful about the company systems an agent can reach and the actions it can take.
The decision in brief
An AI tool approval process decides which AI tools people may use, with which data and under what conditions. For tools that connect to company systems, it also decides which systems they may reach and which actions need a person’s review. Make requesting easy, match the review to the risk, approve a specific scope with an owner and a review date, enforce the decision through configuration rather than a spreadsheet, and re-review when the tool changes.
What an AI tool approval process decides
An AI tool approval process is how an organization decides which AI tools people may use for work, with which data and under what conditions. Most processes start with the app itself: a chat assistant, a meeting note-taker or a coding assistant.
Agents add two more decisions. Many AI tools now connect to company systems, through built-in connectors or the Model Context Protocol (MCP), and some can act in those systems: send a message, update a record or merge a change. Approving the app does not settle which systems it may reach or which actions need a person’s review.
A useful process therefore approves three things, each at the right level of detail.
| Decision | Question | Who usually reviews |
|---|---|---|
| The tool | Can people use this product with company data? | IT, security, privacy and procurement |
| Its connections | Which company systems and data may it reach, and with whose credentials? | System owners and security |
| Its actions | Which changes can it make, and which need a person’s review first? | The business owner and security |
Make requesting easy
People use the tools that are easy to get. If the approved path is slow or unclear, they find their own, which is how shadow AI starts. A short request form, a published list of approved tools and a clear expected turnaround do more than a strict policy nobody reads.
Ask for the information reviewers need up front, so requests do not bounce back and forth:
- The business purpose and the team that will use the tool.
- The data involved, using your existing classification levels.
- Any company systems it should connect to, and whether it needs to change anything in them.
- Who will own the tool once it is approved.
- The vendor, the plan and links to its security and data-use terms.
Match the review to the risk
Not every request needs the same review. Tiers let low-risk tools through quickly and reserve deeper review for tools that touch sensitive data or take actions.
Tier the use case rather than the product. The same assistant is low risk as a writing aid and high risk once it can send email on someone’s behalf. The tiers below are illustrative; adapt them to your data classification and obligations.
| Tier | Example | Review |
|---|---|---|
| Low | Drafting help with non-sensitive content and no connections | IT checks the vendor terms and sign-in, then approves from a standard list |
| Medium | Reads internal documents or tickets through a connector | Security and the data owner review access, scopes and data handling |
| High | Reads customer or financial data, or can change records and contact people | Full security and privacy review, a named owner, limits on actions and a pilot |
Review what matters for AI tools
Standard vendor review still applies: security practices, sign-in through your identity provider, audit logs and contract terms. AI tools add questions about data. Check whether the vendor uses your data to train models, how long prompts and outputs are kept, and whether those terms differ between free and business plans.
For tools that connect to company systems, review each connection as its own decision: which system, whose credentials, which scopes and which data. A connection authorized with a broad scope can reach everything that scope allows, whatever the tool was approved for.
For tools that take actions, decide which actions they may take on their own. OWASP describes giving an AI system more functions, permissions or autonomy than it needs as excessive agency, and lists requiring a person’s approval for high-impact actions among the mitigations.
If you want a broader structure for this work, NIST’s AI Risk Management Framework, currently being revised, organizes it around governing, mapping, measuring and managing risk.
Approve a specific scope, with an end date
An approval is most useful when it says exactly what was approved: this tool, for this team and use case, with this class of data, connected to these systems, with these actions allowed. Anything outside that scope is a new request.
Attach conditions where they reduce risk, such as business plans only, single sign-on required, no customer data, or review of certain actions during a pilot. Give each approval an owner and a review date, so tools that are no longer needed, or have changed, come back for a decision.
Turn the decision into configuration
A decision that exists only in a spreadsheet does not stop anyone. Enforce what you can: enable the tool through single sign-on for the approved group, configure only the approved connections and scopes, and publish the approved list where people look for it.
For agents that connect to company systems over MCP, a gateway can turn the decision into rules that apply to every request: who may use a connection, which tools and data are available and which changes need review. Requests that bypass the gateway still need other controls, such as endpoint management and careful handling of credentials.
Handle tools already in use
The process often starts after tools are already in use. An amnesty period, in which people can register tools without penalty, gives you an honest inventory. Discovery helps too: sign-in logs, expense reports, browser extension inventories and, for agents, MCP configurations on managed devices.
Then sort what you find: approve it with conditions, offer an approved alternative or ask people to stop. Explaining why a tool was declined, and what to use instead, keeps the process credible.
Approving a tool is not approving every action
Approving a tool for use and reviewing what it does are different controls. The first happens once, before rollout. The second happens when an agent proposes a specific action, such as issuing a refund or emailing a customer list.
The MCP specification recommends that a person can always deny a tool call and that clients ask for confirmation before operations. For consequential actions, you can go further and have a second person review the exact request before it runs. Choose which actions need that review based on how much harm a mistake could cause.
Review approvals over time
AI tools change quickly. Vendors add features, change data terms and introduce new connectors, so an approval from six months ago may describe a different product. Review approvals on a schedule and when something material changes: a new use of data, new connections, new actions or a change of plan.
Keep the records: who requested the tool, who approved it, under which conditions and when it was last reviewed. They make audits easier and show which decisions to revisit first.
Where Durin fits
Durin handles the connection and action decisions for agents that use MCP. Members request a connection in Connections, choosing a catalog provider or proposing a custom server with its purpose, and an administrator approves or declines the request in Approvals. Approval does not activate anything by itself: provider setup, tool review and a read-only test still follow.
Once a connection is active, Durin checks each request against current access and the team’s rules. Reviewed requests can proceed by default after those checks. Administrators can require another administrator to review proposed changes; the requester then sends the same request again before the permission expires. Shadow MCP discovery reports MCP servers configured on enrolled devices, which helps find tools that skipped the process.
Durin does not assess AI vendors, apps or their data terms, and it governs only requests routed through its gateway. Your wider approval process still owns those decisions.