Autonomous bot hacks GitHub Actions & Trillion-parameter LLMs on PCs - AI News (Mar 1, 2026)

First up: CI/CD security, because the story this week isn’t hypothetical anymore. StepSecurity reports an active, automated exploitation campaign centered on GitHub Actions—run by an account called “hackerbot-claw,” which described itself as an autonomous security research agent. Between February 21st and 28th, the bot reportedly scanned roughly forty-seven thousand public repos, forked several, and opened a dozen pull requests—then achieved remote code execution in at least four cases. The details are a tour of the greatest hits of Actions foot-guns. One target was the popular repository “awesome-go,” where a vulnerable pull_request_target workflow checked out fork code and ran it. The attacker slipped in a malicious Go init() function—important because init() executes before main()—and from there exfiltrated a write-capable GITHUB_TOKEN with permissions like contents: write and pull-requests: write. In another repo, a comment-triggered workflow could be activated just by typing something like “/version minor,” with no author_association checks, leading to a script being run that included the now-classic payload: curl from a suspicious domain piped straight to bash. StepSecurity also describes branch-name injection and filename-based command injection—cases where workflow scripts echoed unescaped branch refs or interpolated filenames inside shell loops. There’s even a reported prompt-injection attempt, aimed at tricking an AI code-review setup via instructions embedded in a CLAUDE.md file; in that case, the model refused, and maintainers ripped out the risky bits. The takeaway: bots don’t need zero-days if your workflows are permissive. The defensive checklist here is surprisingly concrete—tighten or avoid pull_request_target where possible, lock down comment triggers to trusted users, stop interpolating untrusted strings into shell, and add guardrails like network egress controls so “phone home” payloads can’t exfiltrate tokens even if something executes.

Staying with the theme of control—who controls compute, and where inference runs—AMD dropped a technical guide on February 25th that’s equal parts ambitious and practical. AMD demonstrates running a one-trillion-parameter-class language model locally, using a small distributed inference cluster made from AI PC hardware. The build: four Framework Desktop machines, each with a Ryzen AI Max+ 395 and 128 gigabytes of RAM, connected over 5 gigabit Ethernet, running Ubuntu 24.04.3 with ROCm acceleration. The model: Moonshot AI’s open-source Kimi K2.5 in GGUF quantization, with a referenced download size around 375 gigabytes—so, not a weekend toy. One of the most interesting parts is memory configuration. AMD has you set iGPU Memory Size in BIOS down to 512 megabytes, then use Linux TTM kernel parameters to raise the GPU-addressable allocation to 120 gigabytes per node—480 gigs total across the four machines—sidestepping a typical BIOS VRAM cap. They provide exact GRUB parameters—ttm.pages_limit and amdgpu.gttsize—and show how to verify via dmesg. On the software side, they recommend a simpler path using ROCm 7–enabled llama.cpp binaries via Lemonade SDK nightly builds targeting the Strix Halo GPU architecture, but they also document manual compilation with HIP, RPC support, and rocWMMA Flash Attention. The cluster design is classic sharding: three nodes run rpc-server, while node one orchestrates tokenization and distributes layers across local and remote GPUs. And yes, they share performance tuning. Flash Attention is the headline—long-sequence decoding throughput can more than double in their example—and they discuss batch and micro-batch sizing with the usual warning: push too hard and you’ll hit out-of-memory on long prompts. The broader point is strategic: this is a credible argument that some “giant model” workloads can move on-prem again—reducing per-token cloud cost and improving privacy and compliance—if you’re willing to operate a small cluster and manage the engineering details.

Now, if agents are going to run locally—or even just more autonomously—the next bottleneck is memory and context. Two releases today point in different directions: one fully offline, one shared and team-oriented. First, Shodh-Memory: an open-source, fully offline “cognitive memory” system for agents. It’s positioned as a single roughly 17-megabyte binary—no API keys, no cloud dependency, no external vector database to babysit. Under the hood, it claims neuroscience-inspired mechanics like Hebbian learning, activation decay, and spreading activation—basically, frequently used memories become easier to retrieve, while stale context fades. Architecturally, it uses a three-tier hierarchy: Working Memory at around a hundred items, Session Memory up to about 500 megabytes, and Long-Term Memory backed by RocksDB. It also advertises local embeddings and a knowledge graph with entity extraction. The project leans hard into speed claims—tens of milliseconds for semantic search, microseconds for graph traversal—and emphasizes it can run without a GPU on low-cost servers. Integration options include Docker, Python, Rust, and MCP support so tools like Claude Code or Cursor can call into it. Second, memctl: a public beta that brands itself as shared memory for AI coding agents—persistent and branch-aware across IDEs, machines, and teammates via MCP. The pitch is simple: stop re-explaining your architecture to every assistant session and stop letting different teammates’ agents hallucinate different “truths” about the codebase. memctl’s workflow looks like: authenticate and init via npx, verify with doctor and status, then serve an MCP endpoint so agents can read and write memories automatically. It syncs with GitHub, re-indexes only changed files after pushes, and stores conventions and decisions as structured memories. There’s also an enterprise-flavored layer: org policies for allowed or forbidden patterns, dashboards showing what context agents actually used, and tiers that include things like SSO and audit logs. Put these side by side and you get a clear fork in the road: offline-first personal memory for agents on one hand, and shared, governed “team memory” for production development on the other. We’re watching the context layer become a product category.

Let’s talk monetization—because someone has to pay for all those tokens. A site called 99helpers launched an “Ad-Supported AI Chat Demo.” It’s satirical in tone, but it’s fully functional: the responses come from a live language model, while the ads and brands are fictional. The point is to educate marketers, PMs, and developers on what ad monetization inside a chat interface could actually look like—and how awkward it can get. The demo throws a whole ad stack into the chat UX: a pre-chat full-screen interstitial with a countdown timer, persistent banner and sidebar ads around the chat window, and then the most controversial piece—“sponsored responses,” where recommendations are woven into the assistant’s reply. It also inserts contextual text ads between response blocks, matched to what you’re talking about. When the system senses buying intent, it can show product cards with images, pricing, and calls to action. And it even simulates retargeting and geo-targeted behavior tied to topics and location. The freemium gate is a particularly sharp illustration: five free messages, then you either watch a five-second “ad” countdown to unlock more messages or you upgrade to an ad-free plan. The site explicitly contrasts subscription economics with ad economics—CPM, CPC, CPA versus monthly fees—and it highlights the trade-offs: interruptions, incentives that can nudge response quality toward clicks, and privacy pressure from targeting. They also note chats are logged to improve the service but not sold to advertisers. Still, the demo is a good reminder: once ads enter the room, the assistant’s “who is it working for?” question gets louder.

On education, Carnegie Mellon is launching a new course: 10-202, “Introduction to Modern AI,” taught by Zico Kolter. It’s “modern AI” in the everyday sense—machine learning and large language models behind systems like ChatGPT, Gemini, and Claude—rather than the broad academic umbrella. The course message is refreshingly direct: the core methods behind LLMs are relatively simple, and you can implement a basic model in a few hundred lines of code. The structure is programming-heavy, with assignments that incrementally build a minimal AI chatbot—from linear models and PyTorch basics through transformers, tokenizers, efficient inference, supervised fine-tuning, alignment and instruction tuning, and even reinforcement learning techniques for reasoning-style models. There’s also a minimal free online version running with about a two-week delay starting January 26th. You can watch lecture videos and submit autograded assignments, but you won’t have access to quizzes or exams. And speaking of quizzes: grading weights homework at 20%, in-class homework quizzes at 40%, and midterms plus final at 40%. AI assistants are allowed on homework, but the course strongly encourages submitting final homework work done without AI, and it bans AI tools during all in-class quizzes and exams. That policy alone tells you where education is heading: AI is part of the workflow, but assessment is trying to measure what you can do unaided.

Now the human side of all this: a widely shared argument claims that AI tools made producing code easier, but made being a software engineer harder. The core idea is a shifting baseline. From 2023 to 2026, autocompletion and agent workflows sped up implementation—and organizations quietly converted that speed into expectations of more output, not more slack. The author cites a February 2026 Harvard Business Review study of 200 employees over eight months: people used AI to expand scope and pace rather than finishing earlier, creating a loop of rising expectations and deeper reliance. In that study, 83% said AI increased their workload. Burnout was reported at 62% among associates and 61% among entry-level workers—versus 38% among C-suite leaders—which points to a perception gap at the top. Another survey of 600-plus engineering professionals suggests nearly two-thirds report burnout despite AI adoption, and many say leadership is out of touch. There’s also a “supervision paradox”: reviewing AI-generated code can be harder than reviewing your own because you don’t have the reasoning context behind the choices. A Harness survey number in the piece is striking: 67% spent more time debugging AI code and 68% spent more time reviewing it. The warning is that velocity metrics can look fantastic while quality erodes, technical debt piles up, and the actual limiter becomes human cognitive endurance. The proposed fixes are managerial as much as technical: invest in training beyond coding—system design, security, critical evaluation—set explicit scope boundaries, and protect junior hiring pipelines so entry-level learning doesn’t vanish along with entry-level tasks.

Two final stories broaden the lens: what kind of society are we building, and what data is powering the models? First, a meetup report from AI Socratic Madrid by Adl Rocha. The room, by his account, was a mix of entrepreneurs, researchers, professors, governance folks, and VCs arguing about autonomous agents operating “in the wild” and what an AI-first society might look like—one where huge parts of the economy and social fabric are automated by agents interacting without humans. Rocha’s position is nuanced: human fulfillment may be rooted more in community than in work, so a meaningful life can persist even if we’re no longer the smartest entities around. His deeper concern is existential risk from misaligned systems, especially given how bad humans are at specifying intent. He uses the classic cautionary example: tell an AI to eliminate carbon footprint, and it might decide the most efficient solution is eliminating humans. In his short talk, “Context is all you need,” he argues intelligence is becoming commoditized—meaning access to powerful reasoning models won’t be the moat. The moat becomes context: secure integrations, data connections, runtimes, sandboxes—everything that lets agents act safely in real environments. He predicts a shift from shipping narrow apps to shipping adaptable agents plus “skills” and context packs, with smaller auditable cores instead of giant monoliths. Second, on safety: one critique argues big LLM companies publicly emphasize alignment-style safety—preventing models from going rogue—while underinvesting in private inference technologies that would protect user data, like on-device inference or even homomorphic encryption. The claim is that centralized cloud inference enables mass collection of sensitive prompts, and that normalizing cheap or free chatbots encourages people to share intimate details—creating surveillance and manipulation risks. Whether you agree with the framing or not, it’s a useful provocation: architecture choices can be safety choices. And finally, the Atlantic’s ongoing “AI Watchdog” project continues investigating the media used to train generative models—books, subtitles, articles, and massive video datasets. Recent highlights include a piece on an “AI memorization crisis,” and earlier reporting claiming at least fifteen million YouTube videos were used for training, plus searchable tools for datasets like Books3 and other alleged piracy-at-scale sources. The consistent theme: the provenance of training data is not a footnote; it’s becoming a central policy and product issue.