AI Agents are Recreating the Access Problems that Broke Early Cloud Security
Published
Question: As enterprises rapidly deploy AI agents across internal operations, where are you seeing developers recreate the same identity and access mistakes that broke early cloud security models?
—----------------
Shashwat Sehgal, CEO and Co-Founder of P0 Security
In the words of Ricky Bobby, "if you're not first, you're last.” This adage was more literal than ever during the early cloud era.
- Developers spun up infrastructure
- connected services
- created new accounts and roles
- issued keys and granted permissions that were far broader than the task required
Then entered the security consequences that revealed how widespread, and damaging, overprivileged access had become. Organizations realized they had accumulated massive privilege sprawl that was going to be extremely cumbersome to fix.
It took most teams months if not even years to remediate, apply automated governance and stabilize their environments. And history is going to repeat itself with AI agents.
Before I founded P0, I spent years building DevOps and cloud-native observability products. I was in the trenches during the early days of the cloud and can see the parallel between the mistakes teams are making today when it comes to standing up agentic infrastructure to the mistakes teams made a decade ago with cloud.
These are top areas that needed to be addressed:
- Treating agents like productivity features instead of privileged identities. Developers often connect agents to Slack, Jira, GitHub, Salesforce, cloud consoles, internal knowledge bases, and workflow tools with broad permissions because they cannot predict every action the agent may need to take.
- That may be operationally convenient, but it creates the same standing-access problem that plagued early cloud environments.
- Assuming that authentication solves the access problem. If an agent is connected through a valid token or an approved integration, teams often treat the access as legitimate.
- The more important question is whether the agent should be allowed to take a specific action, against a specific resource, for a specific task, at that moment.
- Early cloud security over-indexed on who could get in.
- AI forces the harder question of what agents are allowed to do at runtime.
- The more important question is whether the agent should be allowed to take a specific action, against a specific resource, for a specific task, at that moment.
- Relying too heavily on observability after deployment. Many organizations are getting better at discovering which agents exist and what systems they touch.
- That visibility is useful, but it does not reduce blast radius when an agent goes rogue.
- If the agent has broad standing privileges, the damage travels as far as those permissions allow.
- That visibility is useful, but it does not reduce blast radius when an agent goes rogue.
The real-world impact is that an agent can take rogue actions, such as deleting a production database. Or an attacker can compromise the agent, and inherit its permissions.
Organizations should change how developers design agent access from the start.
- Every agent should have a clear owner,
- a defined identity,
- scoped permissions, and
- a record of which user or process it is acting on behalf of.
- Access should be time-bound wherever possible and evaluated at the point of action, not just at login or initial connection.
- High-risk actions should require stronger policy checks, approvals, or separation of duties.
The lesson from cloud security is that access decisions made for speed tend to become permanent.
With AI agents, that is even more dangerous because the actor is autonomous, the actions happen through APIs, and misuse can scale much faster than it did with human users.
The organizations that avoid repeating the cloud security cycle will be the ones that treat agents as a new class of privileged non-human identity from day one.
Related
