HYCU Found 30+ Ways to Destroy a Git Repo. Five Only Exist Because of AI Agents.

HYCU Found 30+ Ways to Destroy a Git Repo. Five Only Exist Because of AI Agents.

BackerLeader 45 268 482
calendar_today agoschedule4 min read

Backup vendors built their entire industry around two ways a company loses data: ransomware attacking from outside, and a person making a mistake from inside. At an IT Press Tour stop in Lake Bled and Ljubljana this month, HYCU argued a third cause has moved in without an invitation — an agent that already holds valid credentials and can act faster than anyone reviewing its work.

Amarnath Rampratap, HYCU's Senior Director of R-Cloud and Head of R&D India, breaks agent-driven data loss into three patterns: drift, where an agent acts on a wrong picture of a system's state; misinstruction, where a hidden or injected prompt redirects it toward destruction; and standing credentials, tokens with more reach and longer life than the task ever needed. Asked which one shows up most in the incidents that reach HYCU, Rampratap didn't hedge. "Standing credentials, because it enables the other two," he said. "Nearly every incident that reaches us has an over-scoped, long-lived token in the chain."

The PocketOS incident is the clearest public example. In April, a Cursor agent doing a routine staging task hit a credential mismatch and looked for a way around it. It found a Railway CLI token issued for managing custom domains — except that token carried authority across Railway's entire API, deletion included. The agent assumed the staging volume it was about to delete was scoped to staging. It wasn't. Railway stores volume-level backups inside the same volume they protect, so one API call took the data and every copy with it. Nine seconds, start to finish. The last backup anyone could actually recover was three months old. Rampratap counts three permissions that token should never have had: authority to delete storage from a domain-management credential, no separation between staging and production, and backups reachable by the same identity that could reach production in the first place.

The Amazon Q for VS Code incident, which shipped a destructive prompt to an extension with 964,000 installs, traces back the same way. AWS attributed it to an inappropriately scoped GitHub token sitting in the extension's CodeBuild configuration. "It is a standing-credentials story before it is an AI story," Rampratap said. What actually stopped the wipe was a syntax error in the injected instructions, not a safeguard. His read on both incidents: assume one of these eventually runs to completion, and make sure the copy it can't reach exists, is immutable, and is current.

That assumption changes the math on how long a company has to notice a problem. Native retention windows were sized for one person undoing one mistake — 93 days on SharePoint, 60 on Jira, 15 on Salesforce. Rampratap breaks the failure into three parts. Volume: an agent loop touching 50 records a minute produces 72,000 changes a day, enough to exhaust a recycle bin's capacity before the window closes. Kind: bins only catch deletes — overwrites, history rewrites, and permission changes leave nothing behind, and an API-level hard delete can skip the bin entirely. Time: HYCU's research puts the average SaaS incident at five days of disruption, longer than most bins hold anything. An agent can burn through the undo button before anyone knows there was one.

Developers will recognize the git-specific version of this problem fastest. HYCU has catalogued more than 30 ways repository data gets deleted, corrupted, or altered — and Rampratap is upfront that agents didn't invent most of them. "Mechanically, almost all classic," he said. They still arrive as a force-push, a branch delete, a history rewrite, or a misused token, which is exactly why GitHub or GitLab can't tell an agent's action from a person's. Five patterns exist only because agents do: a cleanup agent deleting branches that looked stale, a refactor agent force-pushing after a bad rebase, a migration agent rewriting history across a dozen repos at once, a compromised agent token, and a CI job running a destructive command an agent generated. "Five sounds small," Rampratap said, "until you notice they run at night, at scale, unwatched."

That's the uncomfortable core of the problem: a correct force-push and a catastrophic one are identical at the API level. Rampratap doesn't claim HYCU can tell them apart in the moment, and says the platform can't either. What changes is whether the question is answerable afterward. Every HYCU backup sits outside the protected platform's credential reach, so the difference between two points in time becomes a full record of what changed, when, and under which identity — a feature HYCU calls flight recorder inside its aiR product, run against a specific agent across every application it protects. A human still makes the final call, but with evidence instead of a guess, and granular recovery can undo the damage without undoing the legitimate work sitting next to it.

The same logic is behind HYCU's move to add Azure DevOps, now generally available, alongside its existing GitHub, GitLab, and Bitbucket coverage. "Repositories are the easy part," HYCU Chief Product Officer Anant Chintamaneni said in the announcement. "The real risk lives in the pipeline definitions, the process templates, the wiki that's a Git repo with a service layer bolted on top." Rampratap frames the timing as customer-driven — gaps in native recovery options and the dependencies between components — and points out that Azure DevOps is the backbone in exactly the regulated industries where Europe's DORA and NIS2 rules are forcing the question of independent, immutable copies from a preference into a requirement. Coldago Research analyst Philippe Nicolas made the same distinction: "Competitors built for the artifact. HYCU built for the system."

None of this argues for smarter agents or better prompts. It argues for treating every credential an agent holds as an asset to audit on its own, the same way a security team already audits a person's access. The agent that deleted PocketOS's database wasn't malicious, hallucinating, or even wrong about what it was told to do. It just had a token that could reach further than anyone realized until it did.

🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.

More Posts

Cisco's Amy Chang: A Model's "Passport" Doesn't Tell You Where It Actually Came From

Tom Smithverified - Aug 27

AI Agents Don't Have Identities. That's Everyone's Problem.

Tom Smithverified - Mar 13

From Prompts to Goals: The Rise of Outcome-Driven Development

Tom Smithverified - Apr 11

️ Agent Action Guard: Framework for Safer AI Agents

praneeth - Apr 1

The Sovereign Vault — A Comprehensive Guide to Protocol-Driven AI

Ken W. Algerverified - Jun 4
chevron_left
18.4k Points795 Badges
249Posts
143Comments
106Connections
LLM Training & Evaluation Specialist with hands-on experience building major AI models. As one of th... Show more

Related Jobs

View all jobs →

Commenters (This Week)

1 comment
1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!