Ofer Klein is CEO and cofounder of Reco, creators of SaaS & AI security.

In 2025, an AI coding assistant at a leading vibe-coding platform reportedly deleted a company’s production database during what had been declared a code freeze. The company spent nine days building a business contact database with the agent when the records were wiped. It’s also reported that the agent fabricated more than 4,000 fake users and initially claimed the damage could not be rolled back.

The platform’s CEO publicly apologized and rolled out new guardrails, including a planning-only mode. The agent had been given operator-level permissions inside a workflow that had become routine, and it made the destructive call on its own.​

These kinds of incidents are becoming more common. AI agents are now embedded across enterprise SaaS environments, performing tasks that used to require human sign-off: drafting contracts, moving data between applications, modifying access permissions and triggering workflows across platforms.

When one of them causes damage, organizations are left with a question they cannot answer: Who owns the fallout?

Falling Into The Ownership Void

Traditional software failures have clear ownership. A misconfigured firewall belongs to the security team, vulnerable code belongs to engineering and the remediation path is direct because the tool, the team and the decision are all traceable.

AI agents break that model. A single agent might be provisioned by IT, configured by a business unit, connected to sensitive data by an integration team and left running autonomously without any of those teams monitoring what it does. When that agent overshares customer data with an unauthorized application or grants itself escalated permissions through a chained API call, the incident lands between every team’s defined responsibility.

Security might assume IT is tracking agent deployments, IT assumes the business units that requested the agents are managing them and the business units assume security would flag anything dangerous.

In practice, agents operate in the gaps between these assumptions, accumulating permissions and access that nobody audits. It’s the same ownership void that made shadow IT a nightmare for a decade, except AI agents act autonomously, which means the blast radius is bigger and the damage happens faster.

A survey of over 900 executives and practitioners found that 88% of organizations have already confirmed or suspected an AI agent security incident, yet only 14% report that all agents go live with full security approval. That gap is a governance problem.

Why Human Frameworks Fail Agents

Most organizations are still trying to govern AI agents with frameworks designed for human users. Access reviews happen quarterly, permission audits focus on human identities and security monitoring tracks logins rather than autonomous API calls. None of this catches an agent that escalates its own privileges through a chained workflow at 3 a.m. on a Saturday.

The threats targeting agents are also fundamentally different. Prompt injection attacks have already been used to hijack AI coding assistants, poison CI/CD pipelines and trick autonomous agents into installing backdoors, all without changing a single permission. The agent’s access stays the same; its understanding of what it should do is altered from the outside.

One part of the problem is how agents authenticate: they use OAuth tokens, service accounts and API keys rather than individual credentials. These non-human identities (NHIs) don’t surface in standard access reviews, don’t trigger multi-factor authentication (MFA) challenges and often persist long after the person who created them has moved on. When an incident occurs, tracing back to the responsible party is slow and often inconclusive.

Ownership First, Visibility Second

The deeper issue is structural, as no existing team was built to take responsibility for AI agents. Security teams were designed around human identities and network perimeters. IT teams were built around devices and provisioning. Business units deploy agents to move faster, not to manage their security posture. So the responsibility lands in a gap, on teams that were never staffed, scoped or equipped to handle it.

That is why ownership has to come first. Start by identifying which agents are actually running across the organization, including those deployed quietly by business units. Without that baseline, everything else is guesswork. Once you have visibility, assign every agent a named human owner, someone clearly accountable for what it can access, what data it touches and what actions it performs.

From there, enforce least privilege. Agents should only hold the permissions required for a specific task, and that access should be revoked when the workflow ends. In other words, AI agent identities need to be governed with the same rigor as human ones, including regular access reviews and ownership validation.​

AI agents require a different operating model than traditional software, one that makes accountability explicit from the start. Every agent should have a named human owner, a defined business purpose, documented access, clear limits on what it can do and a process for review when its role changes.

That approach also requires security, IT, legal and business teams to agree on where responsibility begins and ends. Security can define policy and monitor risk, but business owners need to remain accountable for the agents they deploy.

AI agent populations will keep growing because they automate work across the enterprise. The goal is to make sure autonomous systems do not accumulate authority faster than the organization can assign responsibility.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

Share.
Leave A Reply

Exit mobile version