AI tools are easy to connect and surprisingly hard to take back. A chatbot that can read your shared drive, an agent that can send email, an assistant that can update your CRM: each is useful until it does something nobody expected. The practical fix is not a longer policy document. It is a short, explicit operating boundary, agreed before the tool goes live.
This is my summary of the iAastha team's guide, AI Access Control: How to Set AI Governance Boundaries Before You Connect a Tool.
Why tools need a boundary
Most AI problems inside companies are not dramatic hacks. They are ordinary permission problems. A tool was given broad access because that was faster, nobody wrote down what it was meant to do, and nobody was named as the person who could say no. When something goes wrong, the team cannot answer the basic question: was this tool allowed to do that?
AI-enabled tools raise this risk in two ways. They act on plain-language instructions, so behavior is less predictable than a fixed script. And agentic tools can chain several actions together, so one loose permission can reach much further than expected.
What is AI access control?
It is the practice of deciding, in advance and in writing, what an AI system can see, what it can do, and when a human must step in. It borrows from least privilege: give a system only the access it needs to do its job, and nothing more. It sits inside the wider field of AI governance, the policies, roles and checks that keep AI use safe, lawful and accountable.
The three parts of a boundary
- Allowed actions. List every action the tool may take on its own, and be literal. "Helps with support" is not an action; "drafts replies in the helpdesk and saves them as unsent" is. Sort each into view only, draft, edit or execute. Most tools should start at draft and earn more trust over time.
- Data access. Start with the workflow, not the system. If the tool summarizes support tickets, it needs tickets, not payroll. Name the systems, folders and fields it can read, and the ones it cannot. Take particular care with personal data, contracts and credentials.
- Approval rules. Decide which actions must pause for a human: anything irreversible, anything external, anything that spends money, and anything that changes permissions. Name who approves and how quickly, or people will route around the rule.
Review it with the workflow owner
The card is only as good as the conversation behind it. In a 30-minute review, name the workflow owner, walk one real task end to end, mark each action as view, draft, edit or execute, set approval rules, decide how you will know (logs, a weekly sample, or a named reviewer), and set a review date at least every quarter.
If you are planning to connect AI agents or RAG systems to company data, start with this one-page card. For the full guide and an interactive permission card builder, read the original article on iAastha. iAastha is an AI and software engineering partner for startups and enterprises.
Top comments (0)