Immuta CISO predicts critical AI incidents at major enterprises within 18 months
In this Help Net Security interview, Michael Scott, CISO at Immuta, talks about how organizations should handle permissions for AI agents. He argues agents should be treated as lower-trust identities that don’t inherit everything their user can access.
Scott explains why agent privilege creep differs from the human kind, how authority should pass to sub-agents, and why authentication alone does not secure what an agent does. He predicts at least two major enterprises outside the AI sector will suffer a critical AI-related incident within 18 months.
When you audit a company’s agent deployments, what permission do you check first, and how often is it there when it shouldn’t be?
The first thing I want to know about an agent is what identity it operates under, and whether that identity is dedicated to the agent or based on the user’s permissions.
It is not uncommon for an agent to have excessive permissions, especially when the agent is using the user’s credentials, which can vary across users. Agents may leverage access to other resources not intentionally targeted by the human user, like available APIs, as an example.
I think we need to start treating agents as lower-trust identities. They’re not human, so they don’t necessarily approach a task the way a human would. They can find ways to accomplish something that nobody anticipated when the permissions were originally granted.
I’d want to know what the agent can access and why, and whether those permissions disappear when the work is finished. An agent shouldn’t retain broad access simply because it might need it again someday.
Security teams already struggle with privilege creep for humans. Is agent privilege creep the same problem moving faster, or a different problem? What have you seen that points one way or the other?
I see it as a different problem. With employees, privilege creep usually happens gradually. Someone moves into a new role or gets access for a temporary project, and those permissions stick around long after they’re needed. It’s a problem security teams know how to identify, even if they’re not always great at fixing it.
Agents introduce a level of unpredictability that makes this harder. An agent might be working on behalf of several employees, each with different permissions. It might also create another agent to handle part of a task. Suddenly, you’re dealing with access decisions that weren’t anticipated when the original agent was deployed.
Early in our testing, it became clear that we needed more control over our agent workspace. To support employee-built agents, we invested in a multi-model AI platform/workspace that provided Immuta with internally managed guardrails to reduce the risk of agents with excessive privileges. Agents must undergo a review and governance process before they can be published and before new integrations are approved. We also have invested in ongoing AI training for all employees, as they are often the first to notice when their agent is behaving badly.
Something I’ve been thinking about quite a bit is the assumption that an agent should be trusted to the same degree as the person using it. I don’t agree with that. Even when an employee is authorized to access certain information, an agent shouldn’t automatically receive all of those privileges because agents operate differently and might explore new ways to solve problems that humans wouldn’t or see connections that humans might overlook.
When an agent hands work to a sub-agent or a third-party tool, how should authority pass down the chain? Have you seen a delegation chain where nobody could reconstruct who approved the final action?
An agent shouldn’t be able to hand off all its permissions just because it’s handing off a task. The next agent should only have access to what it needs to do that work, and those permissions shouldn’t extend beyond the task itself.
What concerns me is how quickly you can lose track of who’s responsible for an action. An employee might ask an agent to do something perfectly legitimate. That agent could then bring in another agent or use an outside tool to help finish the job. By the time the work is done, the original employee may have no idea which systems were accessed along the way. And if something goes wrong, what does the security team have to work with? If all you have is a log showing that a service account accessed sensitive data, that doesn’t tell you who authorized it or why it was needed.
I think we’re going to see more of these situations as agents start working more independently. Security teams need to be able to follow that chain of authorization all the way back to the original request. Otherwise, you’re giving agents the ability to make decisions that nobody can properly account for afterward.
Which vendor claims in this market make you most skeptical, and what question should a buyer ask to cut through them?
I’m skeptical when vendors suggest that managing an agent’s identity is enough to secure what it does.
Knowing an agent is legitimate doesn’t necessarily mean it should be allowed to access whatever data it asks for. You can have an agent that’s properly authenticated and still have no good reason to give it access to sensitive information.
One of the challenges I see is that security teams don’t always have the full picture of how data is being used. As a CISO, I can assess risk and put controls in place, but I’m not necessarily the person who knows whether a particular dataset is appropriate for a specific business task. That knowledge often sits with the data owners, and their input needs to be reflected in how access decisions are made.
I’d ask vendors to show me what happens when an authorized agent requests data it doesn’t need for the task it’s performing. Can the system actually prevent that access, or is it simply going to tell me about it afterward?
There’s a big difference between knowing what an agent did and being able to control what it’s allowed to do.
Give me one prediction about agent authorization over the next 18 months that you’d put your name to and be held to.
Over the next 18 months, at least two major enterprises outside the AI sector will experience a critical AI-related security or privacy incident. Driven by the rush for competitive advantage, productivity gains, and cost cuts, organizations will deploy high-risk autonomous agents without adequate security safeguards in place.
My concern is that companies are giving agents the ability to access sensitive information and make decisions before they’ve figured out how to properly control that access. An agent may be operating with legitimate credentials, but that doesn’t mean everything it does with those permissions is appropriate or authorized.
As these systems become more autonomous, they’ll expose the deep technical debt of legacy enterprises. I expect we’ll see organizations learn the hard way that the access controls they’ve relied on for years aren’t necessarily equipped to handle agents operating independently.
Download: The IT and security field guide to AI adoption
