When Hugging Face got hacked in July 2026, the breach didn’t just expose one system. The attackers gained access to AI agents that had inherited permissions from the accounts that deployed them. Those agents could read repositories, access API keys, and pull data across the entire platform. The incident put a spotlight on a problem most consulting firms haven’t thought about: your AI tools probably have more access than they need, and if someone compromises one agent, they can reach everything that agent can see.

Act Security came out of stealth with $60 million in funding the same week, building tools to map and limit what AI agents can touch. The timing wasn’t a coincidence. As firms wire AI into their operations, the permission model breaks down. You give a tool access to your SharePoint to pull past proposals. That same tool can now read every client file, every contract, every piece of IP you’ve ever produced. If the tool gets compromised or if an employee accidentally shares the wrong API key, the blast radius is enormous.

For consulting firms, this isn’t theoretical. You’re handling sensitive client data across dozens of engagements. You’re building agents to draft proposals, run research, and synthesize knowledge. Every one of those agents needs access to something. The question is whether you’ve limited that access to what the agent actually requires, or whether you’ve handed over the keys to the entire kingdom because it was faster than mapping out a permission structure.

Why Consulting Firms Are Especially Vulnerable

Consulting work is collaborative and document-heavy. You’re pulling from past decks, research reports, client meeting notes, and pricing models. You’re often working across multiple cloud storage systems, email accounts, and project management tools. When you deploy an AI agent to help with proposal generation, it needs to read some of that content. But most firms grant access at the folder or account level, not the file level. The agent can see everything in the system, even if it only needs three documents.

This pattern repeats across every use case. A research agent that should only access public databases and a handful of internal templates ends up with read access to your entire knowledge base. A knowledge agent that answers questions about past projects can pull from every engagement, including the ones that are under NDA or involve confidential financials. You didn’t intend to give the agent that much access. You just didn’t build the guardrails.

The risk compounds when you consider how many people in your firm are spinning up agents. A senior consultant builds a quick GPT to summarize meeting notes and connects it to the firm’s Google Drive. A partner uses an AI tool to draft a pitch deck and links it to Dropbox. Each of those connections inherits the permissions of the person who set it up. If that person has admin access, the agent has admin access. If the tool gets breached or if the API key leaks, the attacker inherits those permissions too.

Most firms don’t have a central inventory of which AI tools are in use, which systems they’re connected to, or what permissions they’ve been granted. You can’t audit what you can’t see. That’s the gap Act Security is trying to close, and it’s the same gap that consulting firms need to address before they scale AI adoption.

The Manual Work Behind Permission Management

Right now, most consulting firms handle permissions the way they’ve always handled them: someone requests access, IT grants it, and nobody revisits the decision until there’s a problem. That works fine when you’re managing ten people and three systems. It breaks down when you’re managing fifty people, a dozen cloud tools, and an unknown number of AI agents that employees have connected without telling anyone.

The manual work looks like this. A partner wants to deploy a proposal generation agent. They need the agent to pull from past proposals, case studies, and pricing sheets. IT has to figure out where those documents live, whether they’re in SharePoint, Google Drive, or a local file server. Then they have to decide whether to grant the agent access to the entire folder or create a new folder with only the relevant files. If they choose the latter, someone has to go through hundreds of documents and move the right ones into the new location. That’s hours of work for a single agent.

Then the partner wants the agent to pull client-specific data for a new pitch. Now IT has to grant access to the CRM, which means the agent can see every client record, not just the one the partner is pitching. Or they have to export the data manually and upload it to a separate location the agent can access. Either way, it’s more work, and the permission model is either too broad or too brittle.

Multiply that across every agent the firm wants to deploy, and you’ve got a full-time job just managing access. Most firms don’t have the bandwidth for that, so they default to granting broad permissions and hoping nothing goes wrong. That’s how you end up with agents that can read everything, even when they only need to read one thing.

The alternative is to build a permission structure from the ground up. You map out which systems the firm uses, which data lives where, and which roles need access to which resources. Then you create service accounts for each agent with the minimum permissions required to do the job. That’s the right approach, but it’s also a project that most firms will never prioritize until they’ve already had a breach.

What an AI Agent with Proper Permissions Looks Like

When we build agents at Enterprise DNA, we start with the assumption that the agent should see as little as possible. A proposal generation agent doesn’t need access to your entire document library. It needs access to a curated set of past proposals, a template library, and the specific client data for the opportunity you’re pursuing. We create a dedicated workspace for that agent, move the relevant files into it, and grant the agent read-only access to that workspace and nothing else.

If the agent needs to write output, we give it write access to a single output folder. It can’t overwrite the source documents. It can’t access other clients’ folders. It can’t read your financial records or HR files. The agent does one job, and it has exactly the permissions required to do that job.

The same principle applies to a research agent. Most consulting firms want an agent that can pull industry reports, company financials, and market data at the start of an engagement. That agent needs access to external databases and a folder of internal research templates. It doesn’t need access to past client engagements, proposals, or contracts. We connect the agent to the external APIs it requires, give it read access to the template folder, and give it write access to a research output folder. If someone compromises the agent, they can see industry reports and templates. They can’t see client data.

A knowledge agent is trickier because it’s designed to answer questions across the firm’s entire corpus. But even here, you can limit risk. We build knowledge agents that index documents in a vector database, not by granting the agent live access to your file storage. The agent reads the documents once during setup, creates embeddings, and stores those embeddings in a separate system. After that, the agent never touches the original files. If the agent gets breached, the attacker can query the embeddings, but they can’t access the raw documents or modify anything.

This approach requires more upfront work. You have to decide which documents the agent should index, move them into a staging area, run the indexing process, and then remove the agent’s access to the staging area. But the payoff is that you’ve contained the risk. The agent can do its job without having standing access to your most sensitive data.

The Cost of Getting This Wrong

The Hugging Face breach didn’t result in a disclosed dollar figure for damages, but the reputational cost was immediate. Developers who relied on the platform had to rotate API keys, audit their own systems, and explain to their customers why their data might have been exposed. For a consulting firm, the equivalent breach would mean notifying every client whose data the compromised agent could access. That’s not just a legal obligation. It’s a trust problem that can kill your pipeline.

We see consulting firms lose between $80,000 and $300,000 per year to inefficiencies around knowledge management, proposal generation, and research. Those are the costs of doing the work manually. The cost of a data breach is harder to quantify, but it’s not hard to imagine. One compromised agent that exposes client financials or strategic plans could cost you the client, the referral network that client represents, and the deals you would have closed in the next twelve months. For a firm doing $5 million in revenue, losing two major clients because of a breach could cut your top line by 20 percent or more.

The other cost is opportunity cost. If you’re not deploying AI agents because you’re worried about permissions, you’re leaving efficiency on the table. A proposal generation agent can cut proposal time from 30 hours to three hours. A research agent can deliver a structured brief in 90 minutes instead of two weeks. A knowledge agent can answer questions across ten years of engagements in seconds. If you’re not capturing that value because you haven’t solved the permission problem, you’re paying for the same work over and over.

The firms that get this right will deploy agents faster, capture more value, and sleep better at night. The firms that don’t will either avoid AI entirely or deploy it recklessly and hope they don’t get breached. Neither of those is a strategy.

How to Audit What Your Agents Can Access

The first step is to inventory what’s already running. Ask every consultant and partner in your firm which AI tools they’re using and which systems those tools are connected to. You’ll be surprised how many tools are in play. Someone is using ChatGPT with a plugin that reads Google Drive. Someone else is using a transcription service that uploads meeting recordings to a third-party server. Another person is using an AI research tool that scrapes LinkedIn and pulls data from your CRM.

Once you have the list, map out what each tool can access. Log into the admin console for your cloud storage, CRM, and project management tools. Look at which third-party apps have been granted access and what permissions they have. Revoke access for any tool that isn’t actively in use. For the tools that are in use, check whether they have read-only access or read-write access. If a tool only needs to read data, downgrade its permissions.

Next, create a permission policy for new agents. Decide which systems agents are allowed to connect to, what approval process is required, and what the default permission level should be. The policy should specify that agents get read-only access unless there’s a documented reason for write access. It should require that agents connect to dedicated workspaces, not to the root folder of your file storage. And it should mandate that permissions are reviewed every 90 days.

Then start building dedicated workspaces for each agent. If you’re deploying a proposal generation agent, create a folder called “Proposal Agent Workspace” and move the relevant templates, past proposals, and pricing models into it. Grant the agent access to that folder only. If you’re deploying a research agent, create a “Research Agent Workspace” with templates and external API credentials. The agent writes its output to a subfolder in that workspace, and a human reviews the output before it goes into the main knowledge base.

This is the work that takes time, but it’s also the work that prevents a breach from becoming a catastrophe. If you want help thinking through what this looks like for your firm, book a 60-min Omni Audit. We’ll map out which systems you’re using, which agents would deliver the most value, and what permission structure you need to deploy them safely. You’ll walk away with a prioritized roadmap, a risk assessment, and a clear picture of what the first 90 days look like. No deck, no sales pitch, just the three outputs you need to make a decision. See Omni for consulting firms to understand what the audit covers.

Building Agents That Earn Trust

The firms that succeed with AI won’t be the ones that deploy the most agents. They’ll be the ones that deploy agents their clients trust. That means being able to answer the question: what can this agent see, and how do we know it can’t see anything else?

When you pitch a new client and they ask how you’re using AI, you want to be able to say that your proposal generation agent only accesses anonymized past proposals and templates. You want to be able to say that your research agent pulls from public databases and writes to a secure workspace that’s reviewed before anything goes into the client file. You want to be able to say that your knowledge agent indexes documents in a vector database and never has live access to your file storage.

Those answers require work. They require someone in your firm to own the permission model and enforce it. But they’re also the answers that let you deploy AI without introducing risk. And they’re the answers that let you scale AI across the firm without worrying that the next breach will expose everything.

If you’re not sure where to start, we’ve built a worksheet that walks through the process. Download the Deploy Your First Business Agent guide and use it to map out which agent to build first, what permissions it needs, and how to test it before you roll it out. The worksheet includes a permission checklist, a risk assessment template, and a deployment timeline you can adapt to your firm.

The broader lesson from the Hugging Face breach is that AI agents are only as secure as the permissions they inherit. If you’re granting agents broad access because it’s easier than building a permission structure, you’re accepting a risk that could cost you clients, revenue, and reputation. The firms that take the time to audit their systems, limit agent permissions, and document what each agent can access will be the ones that capture the value of AI without the downside.

We’re working with consulting firms every week to build agents that handle proposal generation, research, and knowledge management. The firms that move fastest are the ones that treat permissions as a first-class problem, not an afterthought. They build workspaces, create service accounts, and review access every quarter. They deploy agents that do real work without exposing real risk. That’s the standard, and it’s the standard you should hold yourself to.

If you want to see what that looks like in practice, book my Omni Audit and we’ll walk through it together. You’ll get a clear picture of what’s possible, what’s risky, and what the next 90 days should look like. For more on how we approach AI strategy across different business functions, explore the Omni platform and see how firms are using voice, ops, and apps to automate the work that used to take weeks. You can also browse our insights library for more on how consulting firms are deploying AI without introducing unnecessary risk.

The permission problem isn’t going away. But it’s solvable, and solving it is what separates firms that use AI safely from firms that use it recklessly. The choice is yours.