AI access is becoming a client confidentiality issue

Consulting firms are putting AI agents to work in proposal development, research, knowledge management, and client delivery. That makes sense. A good agent can take a 25-hour proposal cycle down to a few focused review hours. It can assemble a research brief in a morning instead of asking an analyst to spend the first week of an engagement searching, reading, and formatting.

The problem is not the agent itself. The problem is how it gets access.

A recent report on AI agent access controls highlighted a concern that consulting leaders should take seriously. Sixty-nine percent of enterprises reportedly admit to sharing credentials across AI agents. That may look like a harmless shortcut when a team is moving quickly. One Microsoft 365 account, one shared research tool login, one cloud storage token, and multiple automations can get a prototype running fast.

For a consulting firm, that shortcut can put data from one client in reach of work being done for another.

Your Proposal Generation Agent might need access to past case studies and pricing materials. Your Research Agent might need web research tools, approved databases, and selected project files. Your Knowledge Agent might search meeting transcripts, delivery decks, and discovery notes from hundreds of engagements.

Those agents should not all inherit the same broad access. They definitely should not operate under a single shared human credential with no clear record of who or what accessed client material.

This is why AI security is no longer just an IT discussion for firms in the $1 million to $25 million range. It is an operating issue. It affects confidentiality clauses, client trust, your ability to reuse intellectual property safely, and the real savings you expect from automation.

For consulting firms, annual leakage from repeated work, poor knowledge reuse, and unmanaged delivery processes often falls in the $80,000 to $300,000 range. Weak AI access controls can make that leakage worse if partners decide they cannot trust agents with meaningful work. The result is predictable. People go back to manually searching folders, rebuilding decks, and writing research summaries from scratch.

Why shared credentials are especially risky in consulting

A software company may have a product environment with clearly defined data boundaries. A consulting firm has something messier. Your most valuable information is usually spread across client workspaces, email, slides, call transcripts, spreadsheets, proposals, and personal notes.

A partner may have access to every client folder. A senior manager may be assigned to three active projects. An analyst may be working on a proposal in one industry while supporting a client engagement in another. When an AI agent is connected through broad or shared credentials, it can cross those boundaries without anyone intending it to.

That creates four practical risks.

1. Client information can appear in the wrong context

Imagine a proposal agent is asked to draft a response for a logistics prospect. It searches your proposal library and client delivery folders to find relevant proof points. If its permissions are too broad, it may pull language, operating metrics, or recommendations from an active logistics client.

Even if the agent does not copy a confidential document word for word, it can reveal a pattern that should have remained private. A client-specific pricing approach, an internal capability gap, or a transformation roadmap can all leak through a well-intended draft.

The risk is not limited to prompts. It can happen through retrieval systems, shared drives, connected CRM records, meeting transcript libraries, and spreadsheets that were never meant to become AI-readable.

2. Nobody can explain what the agent accessed

When three automations run through a shared service account, the audit trail becomes weak fast. You might see that the account accessed a document at 10:14 a.m. You may not know whether it was the research workflow, the proposal workflow, or a staff member using an unrelated tool.

That becomes uncomfortable when a client asks a direct question.

Which system accessed our files? Which data sources did it search? Was the content retained? Could another client-facing workflow retrieve it?

A vague answer is not good enough, particularly for regulated clients, private equity-backed businesses, health organisations, financial services firms, or public sector work.

3. Departed staff and changing roles leave hidden access behind

Most firms have a version of this problem already. An employee leaves, a contractor finishes, or a partner changes practice areas. Their permissions are removed from the visible systems, but an API token, connected workflow, or automation credential remains active.

Now add AI agents to that environment. A credential that was created for a pilot may still be powering a workflow six months later. Nobody owns it. Nobody remembers which folders it can access. The agent is still working, but its authority no longer reflects your team structure or client commitments.

4. Overly cautious leaders stop adoption altogether

This is the cost that rarely gets measured. A partner hears that AI tools may expose client data, so they ban access to meaningful information. Teams are left using generic public AI tools with no connection to their approved knowledge base.

That avoids one category of risk, but it also removes much of the value. The agent cannot retrieve approved case studies. It cannot see prior research. It cannot help the firm turn delivery learning into reusable IP.

The answer is not unrestricted access or no access. The answer is designed access.

Start with an access audit, not another AI pilot

Many firms begin with a tool. They buy a platform, connect SharePoint, add a chatbot, then try to work out permissions after people start using it.

Turn that around.

Before you deploy an agent, map the work it needs to perform and the minimum data required to complete that work. This is a much more useful exercise than making a list of every AI tool people have tried.

A practical access audit should answer these questions:

• Which AI agents exist today, including informal automations built by individuals?
• Which identity does each agent use to authenticate?
• Is that identity unique to the agent, a shared service account, or a named employee account?
• What folders, systems, mailboxes, databases, and applications can it access?
• Which clients and projects sit inside those systems?
• Can the agent write, delete, send, or only read?
• Is activity logged at the individual agent level?
• Who reviews permissions when a client project closes or a team member leaves?
• What happens if an agent receives an instruction to search outside its intended project boundary?

Your answers will usually uncover more than one issue. The common pattern is a capable agent connected to a broad file repository, operated by a credential that several workflows share, with no project-level restrictions.

That is fixable. It just needs to be treated as operating design, not a technical detail that gets delegated without partner oversight.

If you want an outside view of the gaps and the work worth automating safely, see Omni for consulting firms. The point is not to produce a 40-page technology plan. It is to identify where your firm is losing time, where data boundaries are unclear, and what a controlled first agent should look like.

What controlled agent access looks like end to end

A secure agent does not need access to everything. It needs enough access to complete a defined outcome.

Take a Research Agent used at the start of a client engagement.

The engagement partner opens a new project and identifies the client, industry, project code, assigned team, and approved research sources. That information creates the agent’s operating boundary.

The Research Agent then receives a project-specific identity or token. Its permissions might allow it to:

• Read the project’s designated discovery folder
• Search approved external sources and licensed research databases
• Access internal public-facing thought leadership and approved anonymised case studies
• Write a source log and one-page brief into the new project workspace
• Notify the assigned manager when the brief is ready

It should not be able to search every historic client folder. It should not access a partner’s mailbox. It should not retrieve active materials from unrelated projects. It should not send an email, update a CRM record, or upload material to an external tool unless those actions are explicitly part of the workflow.

Every action should be tied to that agent identity, project identifier, source set, and time period. When the project ends, access should expire or be reviewed. If the engagement is extended, permissions can be renewed deliberately.

That design is more disciplined than connecting a generic AI assistant to your whole Microsoft tenant. It is also more useful. The team knows what the agent can do, what it cannot do, and where to check its work.

The same thinking applies to the Omni ops agents we build for client-facing firms. The workflow comes first. The access model is built around the workflow. You do not give an agent broad authority just because it might be useful one day.

Apply the same controls to proposals and knowledge

The Proposal Generation Agent is often the first place consulting firms see a clear return. Senior people can lose 20 to 40 hours on a major proposal, especially when they have to locate relevant examples, reshape credentials, find pricing logic, and turn scattered notes into a coherent point of view.

A well-built proposal agent can pull approved past proposals, relevant case studies, capability statements, and pricing guidance into a tailored draft. But it needs tight boundaries.

It should draw from a curated proposal library, not every document ever created. It should use approved case studies with client names, commercial terms, and sensitive delivery content removed where required. It should produce a draft for a partner to review, not submit a proposal on its own.

A sensible approval chain looks like this:

1. The opportunity owner creates the proposal workspace and selects the permitted source collections.
2. The Proposal Generation Agent retrieves only from those collections.
3. It creates a draft, source list, and an exceptions note showing where it had insufficient evidence.
4. A partner reviews commercial assumptions, client references, and recommendations.
5. The final proposal is stored in the approved repository with the correct opportunity and client tags.
6. Access to the draft workspace expires when the bid closes.

This does more than protect confidentiality. It reduces the time spent hunting for material and gives you a repeatable source library. That is how proposal work becomes an asset rather than a recurring drain on senior capacity.

The Knowledge Agent needs the strongest governance because its potential scope is wide. It can read decks, documents, and meeting transcripts across the firm, then answer questions from that corpus. Done well, it stops firms paying for the same insight twice.

Done poorly, it becomes a search engine for confidential client history.

Start with a tiered knowledge model. Some content can be firm-wide, such as methodologies, internal templates, anonymised lessons, public case studies, and approved playbooks. Some content should be practice-specific. Some should remain visible only to a client team. Some should never be ingested at all.

The Knowledge Agent should respect those tiers in every answer. A manager working on a retail engagement can access the retail playbook and approved cross-industry insights. They should not be able to ask for everything the firm learned during a private turnaround program for another client.

If you are building this capability, Omni advisory can help establish the operating rules before the technology creates a problem you have to unwind later.

Microsoft Defender helps, but it is not the whole answer

The Portnox and Microsoft Defender integration news points to a useful trend. Identity, endpoint, and access signals are coming closer together. Firms will have better ways to see whether an AI agent is operating from a managed device, using an approved identity, or attempting access outside policy.

That matters. Detection is part of the control environment.

But a security platform cannot decide your consulting firm’s data boundaries for you. It cannot tell you which case studies are safe for a Proposal Generation Agent. It cannot determine whether an analyst should access a closed project’s transcripts. It cannot decide how long a research workflow should retain files.

Those are management decisions.

Your technology stack should enforce the decisions. Your partners need to make them.

For firms using Microsoft 365, a sensible sequence is to identify service accounts and application identities, remove shared human credentials from automated workflows, apply least-privilege permissions, separate active client projects from firm-wide knowledge, and review logs regularly. You should also test agents with scenarios that try to push them outside their intended boundary.

Ask the agent for material from another client. Ask it to find confidential pricing. Ask it to email a file. Ask it to search a closed project folder. You want the system to refuse clearly, log the attempt, and give the user a safe alternative.

The commercial case is bigger than risk avoidance

Security work can feel like overhead until you compare it with the cost of not having usable agents.

A consulting firm with 15 to 40 billable staff may run dozens of proposals, discovery phases, and active delivery workstreams each year. If senior people spend even 10 extra hours per proposal rebuilding material, the lost capacity adds up quickly. Repeated research creates the same drag. Knowledge that sits in finished project folders keeps future teams from starting ahead.

The $80,000 to $300,000 leakage band is not usually one dramatic failure. It is the accumulation of small manual jobs that capable people repeat because the firm has not built a safe way to reuse what it already knows.

Controlled agents help you recover that value. They reduce the work required to find approved information, create a first draft, structure research, and make IP searchable. Clear access controls are what make partners comfortable giving those agents enough information to matter.

This is why the security conversation should sit alongside the operating conversation. You are not buying controls for their own sake. You are creating the conditions for trusted reuse.

If you need a practical starting point before a broader audit, download Deploy Your First Business Agent. It is a useful worksheet for defining one process, its owner, inputs, decisions, access needs, and review points before anyone connects another tool to your client data. You can also access the direct version here: Deploy Your First Business Agent checklist.

What to do in the next 30 days

Do not try to secure every possible AI use case at once. Pick the workflows that combine high repetition with manageable data boundaries.

For most consulting firms, that means starting with one of these:

• A Proposal Generation Agent using a curated, approved proposal library
• A Research Agent working within a new engagement workspace and approved external sources
• A Knowledge Agent limited first to firm-wide methodologies and anonymised delivery insights

Then assign an accountable owner. Not a committee. One person who can answer what the agent does, what it can access, where it logs activity, and when permissions are reviewed.

Run a credential inventory alongside the workflow design. Look for shared user accounts, old API keys, generic cloud tokens, and automations connected to broad file repositories. Those are the places where a useful agent can quietly become an exposure.

Finally, measure the outcome. Track hours spent per proposal, time to first research brief, reuse of approved IP, number of access exceptions, and the percentage of agent outputs reviewed before external use. The numbers will tell you where to expand.

For a structured review of the work, access model, and likely value, Book a 60-min Omni Audit. You will leave with three outputs: the priority workflow to automate, the operating and access controls it needs, and a practical view of the value at stake. No deck, no drawn-out sales process.

Build agents your partners can trust

The firms that get value from AI will not be the ones that connect the most tools. They will be the ones that know exactly which work an agent owns, which client and firm information it can use, and who is accountable when something changes.

Shared credentials are a warning sign. They indicate that the workflow may be moving faster than the controls around it.

Fix that before you scale. Start with one defined agent, one restricted data boundary, one clear owner, and one measurable result. Then build from there.

To see where this applies across your proposal, research, and knowledge workflows, review the AI audit for consulting firms or Book my Omni Audit.