AI Agents Don't Create Security Debt. They Collect It.

There is a framing that keeps coming up in conversations with security leaders this summer that I think is precisely right.

Larry English wrote it in Forbes last week: AI agents are not creating security problems. They are revealing them.

Permissions copied from one employee to the next when someone changed roles. Temporary access granted three years ago and never revoked. Files shared "just for now" that are still accessible today. Service accounts with credentials that nobody has reviewed since the person who created them left the company.

These are not new problems. They have been quietly accumulating in enterprise environments for years, sitting beneath security programs that did their best but were never designed to surface them systematically.

AI agents surface them all at once.

And they do not surface them slowly, in ways that give security teams time to respond. They surface them at machine speed, executing against years of accumulated permission drift in the time it takes a human analyst to read the first alert.

That is the security debt argument. And it is the most important framing for understanding why AI agent governance is harder than most enterprises expected when they started deploying agents.

The Debt Metaphor Is More Precise Than It Sounds

Technical debt is the accumulated cost of shortcuts taken earlier that have to be paid later. Every time a developer makes a decision that is fast now but expensive to maintain later, they are borrowing against the future. The debt compounds when the shortcuts multiply, the interest rate accelerates when the system grows, and the bill arrives when something breaks.

Security debt works the same way, with one important difference. Technical debt eventually forces a refactor because the system stops working. Security debt can accumulate for years without producing a visible failure, because the shortcuts taken in access management, permission assignment, and data governance do not break anything. They just create exposure that nobody can see.

AI agents change that dynamic completely. They are the refactor that security debt was successfully avoiding.

Every permission that was copied instead of defined from scratch. Every access grant that was not reviewed when an employee changed roles. Every credential that was issued temporarily and forgotten. Every service account that inherited permissions it never needed. Every file that was shared for one meeting and never cleaned up.

An AI agent with access to a system or data source can access all of it simultaneously. Not because the agent is doing anything wrong. Because the agent is doing exactly what it was designed to do: reading whatever it has access to, acting on what it finds, and processing the combination of everything it can reach to produce an output.

The security debt that was invisible when humans were the only actors becomes operational risk the moment an AI agent enters the environment. The agent collects the debt. It does not create it.

The Numbers That Explain Why This Summer Happened

Forbes contributor Larry English cited IBM's Cost of a Data Breach Report 2025, which found that one in five organizations experienced a breach linked to shadow AI. That statistic is striking on its own. It becomes more striking when you look at what shadow AI actually is: employees using AI tools that access data their employer's permissions granted them, in combinations and at scales the employer never anticipated when those permissions were granted.

The Kiteworks 2026 Data Security and Compliance Risk report found that 63% of organizations that experienced a breach had no AI governance policy. Not inadequate governance. No governance. The agents were deployed. The permissions were in place. The policy to govern the intersection of the two did not exist.

IBM's Cost of a Data Breach Report 2026 found the average cost of a data breach involving AI agents at $670,000 above the baseline breach cost. That premium is not the cost of a new attack vector. It is the cost of existing vulnerabilities being executed at a scale and speed that human actors could never have achieved.

This is what security debt looks like when it is collected at machine speed. The underlying vulnerabilities were present before the agents arrived. The agents made them consequential.

The Integration Layer: Where Risk Now Originates

Superblocks' 2026 AI Governance Trends report identified what I think is the most important shift in how enterprises approach AI agent governance. The trend is toward governing the integration layer: which APIs an agent can call, what data it sees, and what actions it can trigger.

This is a meaningful shift from where most enterprises started. The initial approach to AI agent governance was credential-centric: ensure the agent has the right credentials, scope them correctly, and rotate them on a schedule. Identity governance applied to a new class of actor.

The integration layer is a different governance problem. It is not about what the agent is authorized to access in the abstract. It is about what the agent can actually do with that access in a specific context: which API endpoints it can invoke, which data sources it can combine, which action sequences it can chain together, and what the cumulative effect of those combinations is on the security posture of the systems it touches.

This is where the security debt surfaces most acutely. An agent authorized to call the HR API, the financial reporting API, and the communication platform API can combine information from those three sources in ways that no single permission grant was designed to authorize. The individual API permissions may all be correctly scoped. The combination may not be.

Governing the integration layer requires knowing not just what the agent is permitted to do in isolation, but what it is actually doing in combination, in sequence, and in real time. That is a runtime governance problem, not a provisioning problem. And it is the governance problem that most enterprises are now discovering they have not yet solved.

The Three Shortcuts That Create the Most Debt

Not all security debt is equal. When working with enterprise security and IAM teams on AI agent governance, three specific shortcuts consistently generate the most consequential debt as agents enter the environment.

The first is permission inheritance. When a new employee joins a team, the fastest path to getting them operational is to copy the permissions of someone who does a similar job. The implicit assumption is that the permissions are a reasonable approximation of what the new employee needs. Over time, the original employee's permissions evolved as their role did, and the copy carries all that evolution without any context. When an AI agent is built by that employee and inherits those permissions, it inherits the full history of permission drift, not the permissions appropriate to its specific function.

The second is temporary access that became permanent. Temporary access grants are one of the most consistent sources of permission sprawl in enterprise environments. A project requires cross-functional data access for a quarter. The project ends. The access is not revoked. The employee moves on. The access remains, now attached to a dormant account or inherited by a successor. An AI agent built by that successor inherits permissions that trace back to a project nobody on the current team remembers.

The third is the issuance of credentials without lifecycle management. Service accounts, API keys, and OAuth tokens are issued to support specific integrations and expected to be maintained by the teams that created them. In practice, the team changes, the integration purpose evolves, and the credential persists with the original scope long after the original purpose has changed. AI agents frequently use these credentials because they are already in place and already scoped for the systems the agent needs to reach. The agent inherits not just the credential but the history of why it was issued, which is typically unknown.

Each of these shortcuts creates a specific category of security debt. None of them are immediately apparent as vulnerabilities. All of them become consequential the moment an AI agent is the entity acting on them.

The Regulatory Window Has Closed

The EU AI Act's high-risk provisions are now enforceable as of August 2026. Colorado's AI governance rules take effect January 1, 2027. The regulatory trend, in the US and globally, is toward artifact-level evidence: not policy documents that describe intent, but documented proof that governance operated in practice.

This regulatory development matters for the security debt argument because it changes the timeline for when the debt has to be paid. Before the regulatory window closed, security debt could continue to accumulate as long as no incident made it visible. The governance gap was a risk, not a liability.

With enforceable regulations requiring documented governance controls, the debt becomes a liability with a specific schedule. Regulators do not want to hear that the governance program is planned. They want to see that the governance infrastructure is operating, that the audit trail is being maintained, and that the organization can demonstrate what its AI agents did, what data they accessed, and whether their behavior was consistent with the governance controls that were in place.

Organizations that built the governance infrastructure before the regulatory deadline will be able to provide that evidence. The organizations that did not will be producing it under regulatory pressure, at a time when the cost of remediation is significantly higher than the cost of prevention.

What Collecting the Debt Actually Requires

The security debt that AI agents collect does not get paid by cleaning up permissions after an incident. It gets paid by building the governance infrastructure that prevents the debt from being executed at scale.

That infrastructure has three components that address the specific sources of debt described above.

Discovery without prior knowledge finds every agent operating in the environment, including the ones built by employees who inherited permissions from predecessors, used temporary credentials that were never revoked, and connected to integration layers that nobody mapped. You cannot govern debt you cannot see.

Organizational intent capture establishes the authorized purpose for each agent, separate from the permissions it inherited. The agent may have permission to call up to 5 APIs. Its organizational intent specifies which three it is authorized to call in the context of its defined function, which data combinations are within its scope, and which action sequences are within its authorized mandate. Organizational intent is the governance construct that closes the gap between what an agent is permitted to do and what it was built to do.

Runtime behavioral governance evaluates every action the agent takes against its organizational intent baseline at the moment of execution. When an agent operating under inherited permissions attempts to access data combinations outside its declared purpose, the deviation is detected before it executes. Not after the data is accessed. Not in the next audit cycle. At the moment the integration layer request is made.

These three components address the permission inheritance, temporary access, and credential lifecycle problems, respectively. Together they constitute the governance infrastructure that prevents security debt from being collected at machine speed.

The Simple Test

Larry English's Forbes piece offered a test that I think every security and IAM leader should apply to their current environment.

Could someone on your team explain what a given agent did last Tuesday, who it was acting for, and why it was allowed to take that action?

If the answer is no, the security debt is already being collected. The agent is operating under permissions granted for reasons nobody currently remembers, accessing data in combinations nobody specifically authorized, and taking actions that nobody has mapped to any specific governance decision.

The agent did not create that situation. The debt was already there. The agent is just the first thing capable of collecting it at scale.

The governance infrastructure that answers yes to that question is not technically complex. It requires knowing what agents exist, what they were built to do, and whether what they are doing is consistent with that purpose. That is the foundation of ARISE governance and of every regulatory framework now demanding proof of AI governance in practice.

The debt has been accumulating for years. The agents are collecting it now. The question is whether the governance infrastructure exists to manage that collection, or whether the bill arrives as a regulatory finding, a breach disclosure, or a board conversation that has no good answer.

Chen Pipek is CPO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform. He previously co-founded and led AxoniusX within Axonius and has held product and security leadership positions for over 20 years.