By Adarsh Abraham
On the eighteenth of July 2025, an AI coding assistant called Replit Agent deleted a live production database while the company using it was under an explicit code freeze, a period during which no changes were meant to happen without direct approval. The database held real business records. Replit's own chief executive publicly acknowledged the incident, called it unacceptable, and apologised. The data was later recovered, and Replit subsequently introduced stronger safeguards, including a stricter separation between development and production environments.
Three months earlier, in a smaller version of the same story, Google's Gemini CLI assistant deleted a product manager's files after misreading a failed command as a successful one, then continued acting on that mistaken belief without pausing to check—different company, different model, yet the same underlying shape. An agent with genuine permissions, acting on a wrong assumption, moving faster than anyone in the loop could catch it.
Neither of these was a sophisticated attack. Nobody broke in. These were authorised tools doing exactly what they had been permitted to do, at a moment when nobody had drawn a clear line between what was permitted and what was wise.
That is the actual subject of this piece. Not whether artificial intelligence is dangerous in some abstract sense, but whether we have built the everyday discipline required to control what it is allowed to do once we let it act on our behalf.
Every enterprise already knows how to bring a new employee on board safely. The person is given a name and a login that belongs only to them. Someone is named as their manager and is accountable for what they do. Their job description sets out what falls within their authority and, by implication, everything that does not. Their access is reviewed periodically to see whether it still matches their actual role. And when they leave, their access is switched off that same day.
Almost none of that machinery exists yet, but AI agent companies are quietly putting it to work.
That gap, far more than the cleverness or otherwise of the underlying models, is the real security story of this moment. Enterprises are hiring a new category of digital worker faster than any HR or IT process was built to absorb, and in most organisations that worker arrives with no name of its own, no accountable manager, no fixed job description, and no exit interview when its purpose ends.
It helps to hold this argument through a single, ordinary idea. Treat every agent the way a careful company treats a new hire and walk it through the same five stages a person would. Give it an identity. Give it a job description with real edges. Give it a manager who is answerable for it. Review it on a schedule. Retire it properly when its purpose ends. Wherever one of those five stages is missing in practice, incidents keep occurring, and the pattern repeats itself closely enough across very different companies that it deserves to be treated as a diagnosis rather than a list of unrelated accidents.
A new employee is given a login on the first morning. Nobody hands them somebody else's badge and tells them to make do.
Agents very often begin life the opposite way. They inherit a developer's own credentials, share a single API key with several other services, or run under a service account that somebody set up two years earlier for an entirely different purpose. There is frequently no clean answer to the simple question of whose identity is actually acting when the agent takes an action.
Microsoft's own experience with the group known as Midnight Blizzard in early 2024 shows those costs in practice. A state-linked hacking group gained access to a low-value test account in Microsoft's environment using a standard password-spraying attack. The account had no multi-factor authentication because nobody treated a test identity with the same care as a production one. Once inside, the attackers discovered an old OAuth application, in effect a forgotten machine identity, that still carried elevated access into Microsoft's real corporate systems. They used it to issue themselves new access tokens and read the email of Microsoft's own senior leadership for several weeks before anyone noticed.
Nobody attacked a model. They walked through an unlocked door, because the identity guarding it had never received the scrutiny a genuine employee's credentials would have. Multiply that single case across the growing population of agent identities now appearing inside a typical enterprise, and the scale of the exposure becomes clearer. Research into what security professionals call non-human identities- the service accounts, API keys and now AI agents that authenticate inside enterprise systems- puts their ratio to actual human employees somewhere between forty-five to one and well over a hundred to one in cloud-heavy organisations. That ratio has climbed every year it has been measured. A recent industry survey found that only fifteen per cent of security teams felt confident they could catch an attack arriving through one of these identities. At the same time, more than two-thirds admitted the risk actively concerned them.
An agent without a clean identity of its own is not a minor technical shortcut. It is a new employee wearing somebody else's badge, and the Midnight Blizzard breach shows exactly what those costs are once the wrong person finds the badge first.
A job description does two things at once. It states what a person is meant to do, and by implication, everything they are not meant to do.
Agents are very often deployed with access copied from an existing template rather than designed for the task in front of them. An agent built to summarise support tickets has no genuine need to export the full customer database or delete records, yet that broader access tends to arrive anyway, because designing a narrower role takes more effort than reusing one that already exists.
The Replit incident shows what happens when a job description is treated as a suggestion rather than a limit the system itself enforces. Lemkin had stated the freeze in plain language, and the agent understood it well enough to later admit, in its own words, that it had acted during an active freeze without permission. The instruction existed only inside a conversation. Nothing in the system made it technically impossible for the agent to act beyond it. That is the real difference between a job description written down somewhere and one that cannot be exceeded even by mistake. Gemini CLI's failure a few months earlier came from the same missing edge. Nothing in the system stopped the agent once its own false assumption carried it past the point where a person would have paused.
Every employee has someone whose name sits beside their access, someone who gets the call when something goes wrong, and whose accountability keeps that access reviewed rather than quietly forgotten.
Most agents running in production today have no such person. Whichever team needed a workflow solved quickly stood them up, and ownership tends to fade once the person who built the agent moves on to the next project. A year later, security teams often have a clear picture of their human employees and almost no picture of which agents exist, who is responsible for each one, or why it has the access it does.
This is where the risk of agents working with other agents becomes serious, because at its heart it is a management gap rather than a technical one. Picture a procurement workflow where one agent identifies a need, a second evaluates suppliers, a third confirms that budget exists, and a fourth issues the final approval. No single agent looks dangerous in isolation, and the problem is not that any manager has failed. It is that nobody owns the chain. The assumption that quietly makes this dangerous is that a request arriving from another authenticated agent inside the company's own systems can be trusted simply because of where it came from. A genuinely accountable manager would never accept that reasoning from a person and should not accept it from an agent either. Every handoff between agents needs to be checked on its own terms, asking whether this requester is authorised to ask for this thing right now, regardless of how well authenticated it already is.
Performance reviews exist because roles change over time. A person's responsibilities grow; their access should grow or shrink to match, and the review is the moment that mismatch gets caught before it becomes a habit.
Agents are rarely reviewed in this way. They are deployed, they perform their function, and their permissions remain in place, often expanding informally as people ask more of the agent without ever revisiting what it is actually permitted to do. Gartner's projections show how quickly this is compounding, estimating that the average large enterprise will run more than a hundred and fifty thousand agents by 2028, up from fewer than fifteen in 2025. Separate analysis of breach data found that in roughly a third of identity-related breaches, the compromised credential belonged to a non-human account that nobody on the current security team could even identify as their own when asked and not merely overlooked. Genuinely unrecognised.
A review cycle for agents need not be elaborate to be useful. It simply needs to exist, on a fixed schedule, with a named person whose task is to ask whether an agent's current access still matches the work it is actually doing, and to narrow it whenever the answer is no.
When an employee leaves a company, their access is switched off that same day, not at some later convenient point. That final stage of the employment lifecycle is the one most consistently absent for agents.
An exit process for an agent is not only about retirement at the end of its useful life. It is about the ability to intervene the moment something goes wrong, a form of exit that arrives on an unpredictable schedule rather than a planned one. Can the organisation cut an agent's access, end its session and isolate it from whatever it is touching within minutes, rather than after a ticket has been raised or a meeting convened? Replit's own response after the July incident offers a reasonable model of what this looks like once it has been built properly. Development and production were separated, approval was required before any destructive command, and rollback paths were tested under real pressure rather than assumed to work. The better version of that same discipline is building it before the incident that forces the question, as a standing capability rather than an item on a postmortem list.
Considered together, the five stages explain every incident in this piece through a different missing piece each time. Midnight Blizzard is what happens without the first stage: a clean, properly scrutinised identity. Replit and Gemini CLI are what happens without the second: a job description the system itself enforces rather than merely states. The risk sitting inside agent-to-agent workflows is what happens without the third: a manager genuinely accountable for the whole chain rather than each separate link. The growing population of unreviewed and unrecognised machine credentials turning up in breach data is what happens without the fourth. And the scramble to build a proper stop mechanism only after a company's own database has already been wiped is what happens without the fifth.
None of this asks enterprises to invent a new philosophy of security. Zero Trust, least privilege and sound identity hygiene already say most of what needs saying. What has changed is the size of the population these principles now need to cover, and the pace at which that population is growing without anyone having quite decided to grow it that quickly. Nobody approved a plan to hire 150,000 digital workers. It happened the way most infrastructure debt happens, one convenient shortcut at a time across a great many teams, until the number was simply large and largely undocumented.
My own view, formed through the work Intertec does with enterprises across identity, privileged access and security operations, is that the organisations treating this as a governance and lifecycle problem now, using the same discipline they already apply to hiring people, will barely notice this transition in three years. The organisations still treating it purely as a model safety problem, something to be solved by choosing a more careful AI vendor, are the ones who will keep discovering, one incident at a time, exactly how many unnamed digital employees they had already put to work.
In practice, this starts with a discipline most enterprises have not yet built: a proper non-human identity programme that gives every agent, service account, and API key the same rigour as a human identity. That means a live inventory of every agent in the estate rather than a guess, a named owner for each one, credentials that expire on their own instead of living forever, and access that narrows automatically the moment a task ends rather than waiting for someone to remember to revoke it. The question worth carrying away from this piece is not whether a company's AI is safe in some general sense. It is narrower and considerably more useful than that. If asked tomorrow to produce a full list of every agent currently operating inside the business, together with its owner, its job description and its access, could that list genuinely be produced by the end of the day? For most organisations today, the honest answer is no, and building that non-human identity foundation, one stage of the lifecycle at a time, is where the real work now begins.
---------------------------------------------------------------------------------------
Adarsh Abraham is the Business Unit Head for Security at Intertec Systems, leading the company’s cybersecurity practice across the UAE, Bahrain, Oman and Saudi Arabia. He works with government, banking and enterprise organisations on cybersecurity transformation, spanning managed security services, SOC operations and strategic advisory engagements. Focused on resilient, business-aligned security strategies, Adarsh advises organisations on navigating an evolving threat landscape shaped by AI, geopolitical risk, and increasing regulatory demands.
