Major Bank Caused 4-Hour Outage: How AI Agents Break Security Systems and What to Do About It

Last year, a major bank faced a serious incident: an LLM agent with standing access to a production Kubernetes cluster triggered a four-hour outage by pushing a malformed configuration. In the Identity and Access Management (IAM) system, this agent appeared as a service account with a long-lived API key, no multi-factor authentication (MFA), and no scoped revocation path. When the incident review team tried to find out which human had authorized the agent’s last action, no one in the room could answer. This situation, unfortunately, is not unique and has been replicated in various industries.

AI agents are disrupting traditional security paradigms. Conventional service accounts perform predictable tasks, and their actions are easily controlled. But an agent that receives an intent, decomposes it into steps, and chooses its own tools to achieve a goal acts unpredictably. It can cause an outage, data leak, or become an entry point for an attack, and existing security systems are simply not ready for such behavior. This is not just a strategic question; it's a control question that auditors and the board will eventually ask. Ignoring it means voluntarily creating vulnerabilities.

Why AI Agents Don't Fit the Existing Security Model

Traditional service accounts in enterprise systems are designed to perform narrow, predictable tasks: fetch a backup, run a scheduled report, sign a build artifact. Their functionality is fixed at design time, and their control mechanisms (rotation, vaulting, auditing) are well-established.

An AI agent operates differently. It receives a general intent, independently breaks it down into steps, selects appropriate tools or APIs, and achieves an outcome that was not strictly predetermined. As a result, the agent's actions become less predictable and more challenging to control.

Experts note that the number of non-human identities (NHIs) in enterprise environments already exceeds human identities, sometimes by a factor of 25-50. IAM tools, designed to manage employee lifecycles, are not intended for discovering, attributing, and governing these NHIs at such a scale.

Key Risks Associated with AI Agents

The OWASP GenAI Security Project has identified key threats related to AI agents. Three of the four highest-rated risks directly concern identity and access issues:

• Tool misuse and exploitation (ASI02). An agent may use authorized tools for unintended purposes, leading to undesirable consequences.
• Identity and privilege abuse (ASI03). This includes delegated and inherited trust, where an agent gains overly broad permissions.
• Rogue agents that act outside their intended behavior (ASI10). Agents may act beyond their intended scope.

These risks underscore that the primary problem with AI agents is not novel cryptography or exploits, but rather the unbounded scope of an identity that the existing IAM model was never asked to govern.

Six Minimum Requirements for AI Agents Before Production Deployment

Before discussing maturity, it's crucial to establish a baseline for security. These six requirements are mandatory for any AI agent deployed in an enterprise environment:

1. Uniquely attributable non-human identity. Each agent must have its own unique identifier. Sharing service accounts between agents or between an agent and a human is unacceptable.
2. Permissions granted under an "on-behalf-of" model. The agent acts on the authority of a named human principal, inheriting that principal's permissions, scoped to a defined purpose. It should never act from its own standing authority.
3. No long-lived credentials. No API keys valid for more than an hour. No embedded secrets in code. Only short-lived, context-bound credentials, revocable upon anomaly.
4. Complete audit trail through SIEM integration. Every agent action must be logged with a timestamp, executing identity, instructing human principal, input context, and outcome.
5. Continuous re-authentication. For long-running agents, identity must be re-validated based on risk at regular intervals, not just at session start.
6. Real-time revocation. The ability to disconnect an agent from systems within seconds is not optional; it is the only way to contain an incident caused by an agent.

An organization that cannot meet all six requirements does not have an agent governance problem; it has a deployment readiness problem.

Maturity Model for Non-Human Identity (NHI) Management

Most maturity scales evaluate access management from the perspective of human identities. However, an organization with a high level of maturity for humans (e.g., centralized IAM, MFA) and a low level for agents does not have a mature security practice. It has a "lit" half and a "blind" half.

A six-stage maturity model is proposed, where each stage assumes the completion of all preceding ones. The threshold of responsibility lies at Stage 3. Deploying AI agents in production below Stage 3 is considered indefensible from the perspective of the board, regulators, or incident investigations.

• Stage 1: Inventory. Agents are discovered and cataloged.
• Stage 2: Basic Controls. Unique identities, basic logging.
• Stage 3: Controlled Deployment. All 6 minimum requirements are met.
• Stage 4: Bounded Behavior. The agent's mandate has explicit limits it cannot violate.
• Stage 5: Accountable Actions. Every agent action is logged with intent, execution, and result, and an accountable owner is assigned.
• Stage 6: Self-Regulation and Reversibility. The system detects anomalies in agent behavior and intervenes before a human reasonably could. Agent actions are reversible.

"Human in the Loop" — Not Always a Guarantee of Security

A common misconception is that the presence of a human in the agent's decision-making process ensures sufficient oversight. This is not the case. If a human is asked to approve hundreds or thousands of agent actions without the time to inspect each one, what exists is not control but an approval automation with a human signature on it. Human review does not scale to the action volume of an autonomous system.

A mature governance system shifts control from per-action approval to structural constraints: defining the boundaries of what the agent can do, continuously monitoring its behavior for anomalies, and ensuring that oversight is loyal to the principles, not to the system's actions. An organization that relies solely on human approval for every action will not reach Stage 4 of the maturity model.

How to Implement This in Your Organization

For the secure implementation of AI agents in your company, you should adhere to the following principles:

• Separate reporting for human and non-human identities. Do not average maturity scores. Separate reporting will reveal actual security gaps.
• Assign an accountable owner. For every production system with an AI agent, a named individual must be responsible for the agent's actions.
• Start with an inventory. Before deploying agents, know exactly how many you have, what rights they possess, and how they are used.
• Implement minimum requirements. Ensure that all six requirements described above are met before deploying an agent in production.

If this case sounds like what's happening in your company, our manager can help: he'll analyze your business and niche for free and point out where an AI agent would bring a real result in your case. Message the manager