There’s a difference between asking AI what’s in a ticket and asking it actually to change one. Until now, AI in your shop has mostly answered questions: a client’s open tickets, a device’s status, a doc someone couldn’t find ... Sure, that’s helpful. It’s also pretty low stakes.

Doing things is different. Once AI can change a ticket, run a script, or update a setting, a quiet new question shows up: Who actually said yes to that?

That question isn’t a reason to slow down. It just gives you a reason to set up AI agent permissions, so the answer is always clear.

Why Do Permissions Matter More When AI Starts Doing Things?

Walk the floor at MSP Expo 2027, and you’ll hear two phrases on the agenda: “AI middleware” and “permissions for agentic workflows.” Agentic just means AI that takes action instead of only answering. Both phrases point at the same shift.

When AI only looks things up, the worst case is usually a wrong answer a tech catches and moves past. When AI acts, the change is real: a ticket closed, a setting flipped, and/or a script run on a client’s machine. So the conversation moves from “Is the AI smart enough?” to “Who decided it could do this?”

Under the hood, many of these connections use MCP (Model Context Protocol), a standard plug that lets AI assistants like Claude, Copilot, and ChatGPT talk to your tools. The plug doesn’t decide who’s allowed to do what. That decision is yours, and it’s worth making on purpose.

What’s the Difference between Read Access and Write Access?

In plain terms:

• Read access means the AI can look. It can pull up tickets in your PSA platform, check device status in your RMM tool, and search your documentation. Nothing changes.
• Write access means the AI can change things. It can update or close a ticket, run a script, or adjust a setting.

Most shops get comfortable with read access fairly quickly. Write access deserves more thought, because a change made by AI is still a change made in your name, often inside a client’s environment.

A good starting point? Give read access broadly, and give write access only to the roles and tools where it clearly saves time. You can always open things up later. Pulling access back after something goes sideways is much harder.

Who Can Make Changes, and Keeping Each Client Separate

Three practices do most of the work here.

• Decide access tool by tool and role by role. Not every tech needs the same reach, and neither does the AI working for them. A level-one tech might get the tools that look things up, while a senior engineer also gets the tools that make changes. When AI acts for someone, it should stay inside what that person is allowed to do.
• Keep every client walled off. A tech working one client’s tickets shouldn’t be able to reach another client’s systems through AI, even by accident.
• Make sure every tool call leaves a record. Who ran it, against which tool, and when. That record turns “Who said yes to that?” from a worry into a quick lookup.

This is how Conduit works today. Access starts closed, and you grant it per tool and per role, with owner, admin, and member roles for your team. You can also see exactly why a person can or can’t use a given tool. Each client is kept separate, with its own users, tools, and audit log. And Conduit’s security page spells out what gets recorded for every tool call: the user, the organization, the vendor and tool, the time, the response status, and how long it took.

What Should You Ask Any AI Vendor about Access Control?

Whatever tool you’re weighing, these questions get to the heart of it:

• Can I control access tool by tool and role by role, starting from nothing?
• Can I see why someone can or can’t use a specific tool?
• Is every action logged with who, what, and when, and can I export that log?
• Is each client’s data kept separate from every other client’s?
• Are my tool credentials kept away from the AI itself?
• Which of the tools my shop runs does it connect to today?

If a vendor answers these clearly, you’re in good shape. If the answers get fuzzy, that tells you something too.

What’s the Takeaway?

Letting AI take action doesn’t have to feel like a leap. Good AI agent guardrails aren’t about less AI. They’re about being able to answer “Who said yes?” in a few clicks, for every client, every time.

If you’re still figuring out the vocabulary, AI Middleware, Explained for MSP Owners is a good place to start. And if you’re ready to set up permissions that fit your shop, book a free setup call (Zoom or phone), and we’ll walk through it with you.

Frequently Asked Questions

What are AI agent permissions?

They’re the rules that decide what an AI assistant can see and change in your tools, and on whose behalf.

Are AI agent permissions the same as AI guardrails?

Permissions are one kind of guardrail. “Guardrails” covers any limit on what AI can do, while permissions decide which people and which tools it can act for.

Should AI have write access to my PSA?

Only where it clearly saves time, and only for roles you’d trust to make those changes themselves. Start with read access and expand on purpose.

Can AI see data from all my clients at once?

That depends on how it’s connected. With client-by-client separation, AI working for one client can’t reach another client’s data.

How do I know what AI changed?

Look for an audit log that records every tool call, including who ran it, which tool, and when. In Conduit, owners and admins can export that log to CSV.