Permissioning for AI Tools: The Access Control Question You Need to Ask
- Chris Rochford
- 1 day ago
- 5 min read
Your firm spent years building access controls that decide who can touch what data, including role-based permissions, segregation of duties and audit trails on sensitive systems. Those controls exist for a reason, and the need for access controls doesn’t disappear because the "who" is now an AI tool instead of a team member.
Here’s how to think about permissioning for AI, starting with the tools your team members are already using.
Off-the-shelf tools need their own access policy
In many cases, the tools team members reach for most often are off-the-shelf platforms like Claude, Gemini and ChatGPT. Before any of those tools touch firm data, someone has to make an explicit decision about what that tool can see and do.
I recommend creating an AI-specific user account rather than letting a general-purpose AI tool inherit an individual's existing permissions. A dedicated account gives you a clean boundary. You know exactly what that account can reach, and you can adjust that boundary without touching anyone's individual access. This also gives you an isolated activity log for that tool, which is helpful when you need to reconstruct what a tool did and when.
Least privilege applies to AI the same way it applies to people
Firms have used the principle of least privilege for identity and access management for a long time. Grant a team member the access their role requires and nothing beyond it. That principle carries over directly to AI tools, and it shouldn't get a pass just because software makes the requests instead of a person.
National Institute of Standards and Technology access control guidance (NIST SP 800-53) calls for least privilege as a baseline control, and NIST's AI Risk Management Framework extends that expectation to AI systems specifically, directing organizations to manage risk across the full AI lifecycle, including the identities under which those systems operate. A companion profile for agentic AI, built on that NIST framework, goes a step further and recommends that firms treat AI agents as non-human identities, subject to the same lifecycle management, privilege minimization and monitoring obligations firms already apply to service accounts.
That framing is useful because it tells you exactly where an AI tool fits in your existing governance structure: inside the same category you already scrutinize for service accounts.
Agentic AI changes the framing, not the fundamentals
Most of the conversation right now centers on people using AI tools directly, but agentic AI moves the risk elsewhere. An agent doesn't wait for someone to paste in a document. It goes out, retrieves data and takes action on its own, inside the boundaries you set for it.
Conceptually, that's the same problem you already manage when a team member accesses a system. The agent needs a defined scope, a record of what it did, and a way for you to trace that activity after the fact. The Open Worldwide Application Security Project (OWASP) guidance for LLM applications describes the risk of getting this wrong as excessive agency.
It breaks the failure into three patterns:
1. Excessive functionality. Agents can reach tools beyond their task scope
2. Excessive permissions. Tools operate with broader privileges than the task requires
3. Excessive autonomy. High-impact actions proceed without a person reviewing them first
Research from the Non-Human Identity Monitoring Group found that 80% of organizations surveyed said their AI agents had already acted beyond their intended scope, including cases of unauthorized access and sensitive data exposure.
The technology is new, but the exposure it creates when unmanaged is familiar to any CIO. It's the same exposure you'd have from an over-permissioned employee account, but it moves faster.
Build the audit trail for your AI agents the way you'd build one for any system with access to client data. You need to know what it accessed, what action it took and when.
Trusting the vendor isn't the same as trusting every permission
When you use an AI tool embedded inside a platform you already trust, it's tempting to extend that trust to whatever the AI inside that platform does. I'd push back on that instinct. Vendor trust covers the vendor's security practices. It doesn't automatically answer the permissioning question.
Ask specifically what the AI can do within that platform. Can it delete records? If it can, can you recover what it deletes? How quickly? Answer these questions before deploying the tool. It shouldn’t have mass deletion permissions you wouldn't grant a team member performing the same function.
Netwrix's 2026 Data and Identity Security Report found firms where AI significantly expanded the number of identities accessing data reported a 43% breach rate over the prior year, compared with 11% at firms where AI hadn't changed access patterns. Every new AI-driven access point is a new identity in your environment, and it deserves the same scrutiny you'd apply to a new employee or a new integration.
Permissioning is a governance conversation, not just a technical one
Permissioning isn’t a one-off IT decision. Every process that touches firm or client data needs to map back to the same governance framework that already covers your traditional systems. If your policy doesn't yet have a defined answer for what an AI tool or agent is allowed to do, that's an unhandled exception waiting to come up during an audit or, worse, after an incident.
Bring this to your executive team as a governance and compliance conversation. Ask them what each system should be allowed to access, and who is accountable when it does something you didn't expect. Firms that build AI governance into existing compliance structures are better positioned to adopt new tools quickly because they make access decisions before the tool reaches production.
The modalities keep changing, but the discipline stays the same
The way AI tools access and modify data keeps expanding. You’ll encounter new integrations, agentic capabilities and vendors building AI directly into the platforms you already run.
You stay ahead by applying the same governance discipline you already trust. Define the access, document the reasoning and keep the audit trail current. That's always been part of the CIO role, even if the tools asking for permission look different now.
Do you want to hone your leadership skills beyond technology?
The Boomer CIO Circle is a peer group for Chief Information Officers in the accounting profession. Together, they work on growing their skills in innovation, budgeting, finance, communication, project management, marketing, sales and human resources to grow into confident leaders in their firms. Apply now to start building valuable long-term relationships with other forward-thinking CIOs.
Chris Rochford is a consultant, facilitator and speaker who connects business strategy to tech execution. At Boomer Consulting, he leads peer communities in transforming firm operations through benchmarking, systems evaluation and data-driven insights. Known for his deep technical knowledge and business fluency, Chris helps CPA firm leaders turn data into action. He’s also a hobbyist photographer, heavy reader and tech tinkerer, always exploring what’s next.
Comments