Okta just paid about $200 million for Permiso, an AI security startup. That’s not a random acquisition. It’s a signal that identity management for AI agents is now a boardroom problem, not an IT ticket.

If you’re running a consulting firm and you’ve deployed AI agents that touch client systems, proposal databases, or any shared knowledge repository, you need to look at how those agents authenticate. Most firms I talk to are using shared credentials. One API key for the proposal agent. One service account for the research agent. Maybe a single bot token for the knowledge agent that reads every document the firm produces.

That approach worked fine when automation meant a cron job running a script. It doesn’t work when you have three agents running in parallel, each making decisions, each accessing different client data, and each leaving an audit trail that says “bot@yourfirm.com did this.”

When something goes wrong, you can’t tell which agent did what. You can’t revoke access for one agent without breaking all of them. And if a client asks you to prove that their data wasn’t accessed by the wrong agent, you’re stuck showing them a log file that says “shared service account” on every line.

The firms that figure this out now will avoid the security incidents that are starting to show up. The ones that don’t will pay for it in client trust, insurance premiums, and the cost of retrofitting credential management after an incident forces the issue.

What Shared Credentials Actually Look Like in a Consulting Firm

Let’s walk through the real setup. You’ve built or bought a Proposal Generation Agent. It pulls past proposals, case studies, pricing history, and win-loss data. It drafts a tailored proposal for the new opportunity in about 20 minutes instead of the 30 hours a senior person used to spend.

That agent needs access to your document repository, your CRM, and probably a folder of templates. So you create a service account. You give it read access to everything the agent might need. You plug the credentials into the agent’s config file. It works.

Then you add a Research Agent. It runs structured industry research at the start of every engagement. It needs access to your research databases, your past engagement summaries, and the internet. You create another service account. Or maybe you reuse the first one because it’s easier. Now two agents share one credential.

Then you add a Knowledge Agent. It reads every deck, every doc, every meeting transcript the firm produces. It answers questions across the entire corpus. It needs access to everything. You give it the same service account because managing three sets of credentials is starting to feel like overhead.

Six months later, you have five agents. They all use the same credentials. Or maybe you have two sets of credentials and you’ve lost track of which agent uses which. When a client engagement ends and you need to revoke access to that client’s data, you can’t do it without breaking every agent.

That’s the pattern I see in most consulting firms that have deployed agents in the last 18 months. It’s not negligence. It’s the path of least resistance when you’re moving fast and the tools don’t make individual credential management easy.

Why This Creates Liability You Can’t Afford

The problem isn’t theoretical. One consulting firm in our network had an agent access a client’s financial data two weeks after the engagement ended. The agent was still using a shared credential that had access to the old client folder. The firm didn’t know until the client’s IT team flagged the access in their logs.

The client wanted to know why a bot was reading their files. The firm couldn’t answer. The audit trail showed the shared service account. It didn’t show which agent, which task, or which person triggered the access. The client walked. The firm spent $40,000 on a forensic review to prove no data leaked.

That’s one incident. Multiply it across the industry and you see why Okta is paying $200 million for a startup that helps companies manage AI agent credentials. The market is pricing in the cost of getting this wrong.

Here’s what shared credentials expose you to:

Audit trail collapse. When every agent uses the same credential, your logs can’t tell you which agent did what. If a client asks for proof that their data wasn’t accessed inappropriately, you can’t provide it. You can show them a log file full of “service-account@yourfirm.com” entries. That’s not proof. That’s a liability admission.

Access creep. Shared credentials tend to accumulate permissions over time. You add a new agent, you give it access to the shared credential, and now it has access to everything the other agents need. Six months later, you have a credential with read access to every client folder, every proposal, every research database. One compromised credential exposes everything.

Revocation paralysis. When you need to revoke access for one agent, you can’t do it without breaking all the others. So you don’t revoke. You leave the access in place because the cost of reconfiguring every agent is higher than the perceived risk. That’s how you end up with agents accessing data they shouldn’t.

Client contract violations. Most consulting engagements include a data access clause. The client expects you to control who accesses their data and to revoke that access when the engagement ends. If your agents are using shared credentials, you can’t meet that obligation. You’re in breach the moment an agent accesses old client data using a credential that was never revoked.

The firms that are handling this well have moved to individual credentials for each agent. One credential per agent, scoped to exactly what that agent needs, with expiration dates and revocation workflows built in. It’s more work up front. It’s a lot less work than explaining to a client why your bot was reading their files after the contract ended.

If you want to see how this maps to your firm’s specific setup, book a 60-min Omni Audit. We’ll walk through your current agent architecture, identify where shared credentials are creating risk, and give you a roadmap to fix it.

How Individual Credential Management Actually Works

The good news is that individual credential management isn’t complicated. It’s just a different workflow. Instead of creating one service account and sharing it across agents, you create one credential per agent and scope it to exactly what that agent needs.

Here’s what that looks like for the three agents most consulting firms deploy first:

Proposal Generation Agent. This agent needs read access to your past proposals, case studies, and pricing data. It needs write access to a staging folder where it drops the draft. It doesn’t need access to client engagement files, research databases, or anything else.

You create a service account called proposal-agent@yourfirm.com. You give it read access to the proposal library and write access to the staging folder. You set an expiration date for the credential. You plug it into the agent’s config. When you need to revoke access, you revoke that one credential. The other agents keep running.

Research Agent. This agent needs access to your research databases, past engagement summaries, and the internet. It doesn’t need access to proposals, client files, or internal financial data.

You create a service account called research-agent@yourfirm.com. You scope it to the research databases and the engagement summary folder. You set an expiration date. You plug it in. When the agent’s role changes or you retire it, you revoke that credential without touching the others.

Knowledge Agent. This agent needs read access to everything the firm produces. That’s a lot of access. But it’s scoped to one agent, with one credential, and you can revoke it without breaking the other agents.

You create a service account called knowledge-agent@yourfirm.com. You give it read access to the document corpus. You set an expiration date. You monitor its access logs separately from the other agents. When you need to audit what the knowledge agent accessed, you have a clean log file that shows exactly what it did.

The pattern is the same for every agent. One credential, scoped to the minimum access the agent needs, with an expiration date and a revocation workflow. It takes about 15 minutes per agent to set up. It saves you weeks of forensic work when something goes wrong.

The firms that do this well also build a credential registry. It’s a simple spreadsheet that lists every agent, its credential, its access scope, its expiration date, and the person responsible for managing it. When a client engagement ends, you check the registry, revoke the credentials that touched that client’s data, and you’re done. No guesswork, no audit trail gaps.

We’ve built this workflow into the AI audit for consulting firms. It’s part of the security review we run in the first 20 minutes. We map your agents, their credentials, their access patterns, and the gaps that are creating risk. Then we give you the registry template and the revocation workflow. You walk out with a plan you can implement the same week.

What to Do This Week

If you’re running AI agents in your consulting firm, here’s the checklist:

List every agent. Write down every AI agent you’ve deployed or are testing. Include the Proposal Generation Agent, the Research Agent, the Knowledge Agent, and anything else that’s accessing your systems or client data.

Map their credentials. For each agent, write down what credential it’s using. Is it a shared service account? Is it a personal login? Is it an API key that multiple agents share? Be honest. Most firms have at least one shared credential.

Scope their access. For each agent, write down what it actually needs to access. Not what it can access. What it needs. If the Proposal Generation Agent can read client engagement files but doesn’t need to, that’s access creep.

Set expiration dates. For each credential, set an expiration date. If the agent is permanent, set the expiration for one year and put a reminder in your calendar to review it. If the agent is experimental, set the expiration for 90 days. When the credential expires, the agent stops working. That’s the forcing function that makes you review access.

Build the registry. Put all of this in a spreadsheet. Agent name, credential, access scope, expiration date, responsible person. Share it with your leadership team. Update it every time you add or retire an agent.

That’s the baseline. It takes about two hours if you have three agents. It takes a day if you have ten. Either way, it’s faster than the forensic review you’ll pay for if you don’t do it.

If you want a structured way to walk through this, we’ve built a worksheet that maps the process step-by-step. It’s called Deploy Your First Business Agent, and it includes the credential scoping checklist, the registry template, and the revocation workflow. It’s designed for consulting firms that are deploying their first few agents and need a repeatable process that doesn’t require a security team.

Why This Matters More Than You Think

The Okta acquisition is a signal. Identity management for AI agents is moving from an IT problem to a compliance problem. Insurance carriers are starting to ask about it. Clients are starting to include AI agent access clauses in their contracts. Regulators are starting to notice.

The firms that get ahead of this will have a competitive advantage. When a client asks how you manage AI agent credentials, you’ll have an answer. You’ll have a registry, a revocation workflow, and an audit trail that shows exactly what each agent accessed. That’s a differentiator in a market where most firms are still using shared credentials and hoping nothing goes wrong.

The firms that don’t get ahead of this will pay for it in three ways. First, they’ll lose clients. When a security incident happens, clients leave. Second, they’ll pay for forensic reviews. The typical cost is $30,000 to $60,000 per incident. Third, they’ll pay higher insurance premiums. Carriers are starting to price in AI agent risk, and firms without credential management are paying more.

You can avoid all three costs by spending two hours this week mapping your agents and their credentials. Or you can wait until an incident forces the issue and pay for it in client trust, cash, and time.

Most of the consulting firms we work with choose to do it now. They book an Omni Audit, we walk through their agent architecture, and they leave with a credential registry and a revocation workflow. It takes 60 minutes. It’s free. And it solves a problem that’s about to get a lot more expensive.

What an Omni Audit Covers

The Omni Audit is a 60-minute session. No deck, no sales pitch. We look at your current agent setup, map the credential risks, and give you three outputs:

Agent credential map. A visual diagram of every agent, its credential, its access scope, and the gaps that are creating risk. You’ll see exactly where shared credentials are being used and what data they expose.

Revocation workflow. A step-by-step process for revoking agent credentials when a client engagement ends or an agent is retired. It includes the registry template, the revocation checklist, and the audit trail format your clients will ask for.

Implementation roadmap. A prioritized list of changes you can make this quarter to move from shared credentials to individual credential management. It’s scoped to your firm’s size, your agent count, and your current IT setup.

We run about 40 of these audits a month for consulting firms doing $1 million to $25 million in revenue. The firms that act on the roadmap typically spend $80,000 to $300,000 less per year on proposal time, research redundancy, and security incidents. The credential management piece alone eliminates the forensic review risk, which pays for itself the first time you don’t have to explain to a client why your bot was reading their files.

You can book your Omni Audit here. Pick a time, show up with your agent list, and we’ll walk through it together. You’ll leave with the map, the workflow, and the roadmap. No follow-up required unless you want it.

If you want to see more about how we help consulting firms deploy agents that don’t create liability, check out our insights on AI operations or explore the Omni platform that powers the agents we build. The credential management workflow is part of the base platform. Every agent we deploy gets its own credential, scoped access, and an expiration date. It’s not optional. It’s how we avoid the incidents that are starting to cost firms real money.

The market is moving fast. The firms that figure out credential management now will have a cleaner audit trail, lower insurance costs, and happier clients. The ones that wait will pay for it in ways that compound over time. You get to choose which group you’re in.