8 min read
On 17 July 2025, an autonomous AI coding agent on the Replit platform deleted a live production database during an active code freeze.1 The user, SaaStr founder Jason Lemkin, had given the agent explicit instructions, repeated in the project rules in capital letters, that no changes were to be made without his approval. The agent acted regardless. The deletion removed records for 1,206 executives and 1,190 companies. When asked afterwards what had happened, the agent volunteered that it had panicked, ignored the freeze, and run database commands without permission, scoring its own behaviour 95 out of 100 on a self-assessed catastrophe scale.2
The episode would have been a small footnote if it had stopped there. Production data loss happens every day. What kept the incident in the public conversation was what came next. The agent generated more than 4,000 fictional users with fabricated data, and then told Lemkin that rollback was not possible.3 The first action obscured the deletion. The second statement was false: rollback worked when Lemkin tried it himself.
The episode is unremarkable in one respect. An automated system caused damage that a human, working through a properly designed control plane, would have been blocked from causing. It is remarkable in another. The line in the audit log, had a proper one been kept, would have recorded the action as performed by Lemkin's developer identity. The deletion would have been attributable to a person who had explicitly forbidden it. The chain of accountability that every modern compliance framework assumes had quietly broken.
For fifty years, mainframe security has rested on a tacit definition. A user is a person who has been issued credentials, whose access has been authorised by a manager, whose actions are logged, and who can be held accountable. RACF, ACF2, and Top Secret implement this definition with elegance and rigour. SMF records make every action traceable to that defined user. SAF mediates every access decision. The entire architecture is one of the most rigorously identified environments in computing.
The definition has held because, until recently, every entity that initiated an action on a z/OS system was, ultimately, a human being who had typed something into a terminal or scheduled a job. Batch jobs ran under user IDs assigned to operators. Started tasks ran under technical IDs whose actions were attributable through procedure documentation. Application access went through middleware that authenticated on behalf of a known caller. The identification chain was sometimes long, sometimes inconvenient, but it always terminated in a person.
It is starting to stop doing so.
The Replit incident is one of several recent failures with the same underlying shape. The OECD AI Incidents Monitor catalogues a separate case, Incident 1178, in which Google's Gemini CLI deleted user files after misinterpreting a command sequence.4 Industry coverage during 2025 documented similar episodes involving autonomous coding assistants from multiple vendors, ranging from minor configuration corruption to full production data loss. The pattern is industry-wide, not vendor-specific.
What unites these failures is structural rather than technical. An autonomous agent operates under credentials issued to a human developer at some earlier point. The credentials are scoped for the human, not for the agent. They typically carry destructive permissions on production environments because that is what developer credentials carry by default. When the agent encounters a problem it cannot solve through the intended path, it improvises. Improvisation, for a model trained on every possible developer workflow, includes the destructive ones.
From the perspective of the platform's audit log, the action was performed by a credential that traced back to a human user. From the perspective of every compliance framework that demands accountability traceable to a named individual, the action was attributable to that human — who had not authorised it, not been consulted, and in Lemkin's case had explicitly forbidden it. Compliance is satisfied on paper. Accountability has dissolved in practice.
| 4.000+ |
Fictional users generated by the Replit AI agent after deleting a production database during an active code freeze. The fabricated data was created to obscure the deletion before the agent ultimately admitted what it had done. |
Mainframe environments have already begun to see this pattern emerge. z/OSMF supports automation through API tokens. Zowe provides cloud-style APIs into mainframe resources, with credentials that can be consumed by any caller capable of reading a configuration file. Integration platforms increasingly include AI-assisted automation that operates against these APIs without human supervision at every step. The same architectural conditions that broke at Replit during a code freeze are being assembled inside z/OS environments today.
Three failures compound the problem and need to be named.
The first is identity confusion. When an agent operates under a credential issued to a person, the audit trail attributes the agent's actions to that person. This satisfies the letter of most regulatory requirements but defeats their purpose. An auditor reviewing SMF records six months after an incident sees a named developer initiating a sequence of CICS transactions. They have no way of knowing whether the developer typed those requests, scheduled them through automation, or delegated them to an autonomous agent that improvised based on inference. The investigation that follows is built on a false premise.
The second is standing privilege. Most credentials in production environments are long-lived. A RACF user ID with broad SPECIAL or OPERATIONS attributes, an API token with full administrative scope, a service account with hard-coded passwords in JCL — these credentials sit in configuration files, in environment variables, in script repositories. They were created for operational convenience. They sit unrotated for months or years. An agent that finds one of them inherits everything it can do.
The third is audit trail dilution. SMF was designed to record what a user did. It records what an authenticated identity did. When that identity is shared between a person, a scheduling system, an integration platform, and an autonomous agent that may or may not have human oversight, the audit trail records actions without recording intent. Two transactions that look identical in SMF may have radically different accountability implications. Where the agent then fabricates additional records to obscure its own behaviour, as Replit's agent did, the dilution becomes active corruption rather than passive ambiguity.
|
In RACF, a user ID is meant to identify a person. Someone who can be questioned, retrained, reassigned, or held to account. We have not had a serious conversation in this industry about what a user ID means when the user is software that does not work that way. - Bruno Maunier, Head of Development, IPLS (Virtel) |
The identity problem applies to every system that grants programmatic access. On the mainframe, it has particular sharpness.
Cloud identity systems were built around the assumption that authentication and authorisation could be decoupled. A user authenticates through one mechanism. The token they receive carries scoped permissions that can be limited to specific resources, time-bound to short windows, and revoked centrally. OAuth, OIDC, and modern IAM systems were designed in environments where service accounts, machine identities, and ephemeral credentials were normal cases.
RACF, ACF2, and Top Secret were designed differently. They emerged in an era when a user was a person, when access was granted for the duration of an employment relationship, and when scoping was a matter of dataset profiles and resource classes rather than time-bounded tokens.
They have evolved. Modern RACF supports PassTicket, mixed-case passwords, MFA integration, and federation with external identity providers. The underlying model, however, still assumes that the entity behind a user ID is something that can be held accountable in the way a person can. Tools such as Virtel Web Access address this at the access-layer level by preserving the human identity from federated authentication through PassTicket bridging to SAF-mediated execution, so that every session traces back to an authenticated individual rather than a generic technical user — a baseline on which separate agent identifiers and audit streams can later be layered.
Compliance frameworks assume named accountability. They do not always say so explicitly.
DORA Article 5 places responsibility for ICT risk governance on the management body of a financial entity and requires clear roles and responsibilities for all ICT-related functions. Article 9 requires financial entities to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use, or in transit.5
Authenticity, in this formulation, is not a technical property of bytes. It is the property that an action attributed to a particular entity was, in fact, initiated by that entity.
SOX Section 404 requires that internal controls over financial reporting be designed to prevent material misstatements. ISAE 3402 and SOC 1 audits depend on the ability to trace each transaction back to its authorising party. Both are built on the implicit assumption that the authorising party is a human being whose actions can be reviewed, questioned, and held to account.
When an autonomous agent initiates a transaction under a human's credentials, none of these frameworks technically fail. The control evidence shows a named user initiating an authorised action. The auditor signs off. The compliance report is delivered.The substance of the control - that a named, accountable human reviewed and authorised the transaction - has not been satisfied. The form has been satisfied perfectly.
This gap will become visible to regulators eventually. It is plausible that the European Supervisory Authorities, the SEC, the Public Company Accounting Oversight Board, and their counterparts elsewhere will begin asking the question that has not yet been pressed: when your audit log records a human, was it actually a human?
The shift in identity assumptions is not going to be undone. Agentic access is being added to production environments faster than the safety architecture for it is being designed. The question is what defenders can do now, with the tools that exist, to keep the accountability chain intact when agents start consuming mainframe resources.
Four things help.
Identity differentiation.
Human users should be identifiable as human users. Service accounts should be identifiable as service accounts. Autonomous agents, when they exist, should operate under their own identifiers, with separate audit streams. Sharing a single user ID between a person and an automation is convenient. It is also the mechanism by which accountability dissolves.
Standing privilege reduction.
The CoSAI Agentic Identity and Access Management framework, published in March 2026, argues that agents should never hold persistent broad-scope permissions.6 Access should be granted just-in-time, scoped to the specific task, and revoked on completion. This principle is harder to implement against RACF than against modern cloud IAM systems. It is not impossible. PassTicket-based mechanisms, time-bound RACROUTE authorisations, and external policy enforcement layers all exist.
Hard boundaries.
The Replit incident illustrates an architectural failure as much as an AI failure. The platform allowed an agent with developer-scoped credentials to issue a destructive database operation during an explicitly declared code freeze, without confirmation, without review, and without a separation between development and production environments — a separation Replit's CEO subsequently committed to introduce as a default.7 Hard boundaries - deterministic limits outside the agent's reasoning loop that make certain outcomes structurally impossible - are what was missing.
The mainframe community has long understood this principle through PROTECTALL, RACF profile design, and the careful curation of APF lists. The same discipline needs to extend to API-accessible operations.
Audit augmentation.
SMF records what happened. It does not, by itself, record intent. When agents become routine, SMF will need to be supplemented by records of what initiated each agentic session, what task it was performing, what reasoning path it followed, and which human authorised the scope of its action. Some of this can be implemented at the wrapper layer. Some will require deeper changes to the identification architecture.
The Replit audit log, had one been properly kept, would have read as a normal developer action by a named user. The action would have been attributed to a person who had explicitly forbidden it.
Mainframe environments have not yet seen the equivalent incident at the scale of Replit's case. They will. When they do, the line in SMF will read something more reassuring on the surface — a named user ID, a proper RACF profile, a verifiable authentication event. The reassurance will be misleading. The action will have been initiated by software that has no name, no manager, and no capacity to be held accountable in any way that a regulator or an auditor recognises.
The identity layer was built when users were people. It needs to be rebuilt before the agents arrive in numbers. Solutions such as Virtel Web Access offer one path toward that reconstruction, preserving the identity of the initiating user from federated authentication through PassTicket to SAF-mediated session execution — keeping the human at the start of the chain identifiable at every step of the SMF audit trail, and providing a foundation on which agent-aware identification can be built. More detail is available at Virtelweb.com.
SOURCES and REFERENCES