Build an agent engineering team with InsForge
Giving four agents different job titles doesn’t tell the frontend agent what the backend actually built.
We created a four-bot engineering setup on Grok Bot, with InsForge handling the backend. The useful part is how work moves between the bots.
The team has four roles:
Piper, the project manager, breaks features into tasks and checks each handoff.
Bay, the backend developer, owns the database, APIs, and server logic.
Fin, the frontend developer, builds the interface against Bay’s documented contract.
Tess, the tester, checks requirements and returns defects to the responsible bot.
All four share one cloud computer. Tasks, project context, and handoff notes live in files that the next bot can read.
Only Piper updates the task board. Each handoff records file paths, the interface contract, decisions, and unfinished work, so Fin doesn’t have to guess what Bay meant by “the endpoint is ready.”
For Bay’s backend work, InsForge provides Postgres, authentication, storage, and edge functions. It’s open source under Apache 2.0.
Its cloud CLI lets an agent inspect backend state and configure resources. That includes reading schemas and metadata, creating storage buckets, running migrations, and deploying functions.
In our setup, Bay checks the current backend before starting a task. Otherwise, an incorrect assumption can enter the handoff note and become the frontend’s implementation plan.
For the role prompts, setup steps, and a hands-on example, our article walks through the full workflow.
Read “Build an Engineering Team With Grok Bot” →
Finding every vulnerability made security harder
Claude Mythos Preview and other Claude models have flagged 29,439 candidate vulnerabilities in open-source projects through Anthropic’s Project Glasswing.
Each candidate claims that some input can reach a dangerous call. Someone still has to open the files, follow that input, and check whether a guard somewhere in between stops it.
Anthropic names that human triage as the bottleneck. As of October 2, only 516 of the 6,157 findings it reported to maintainers had been patched.
Your own repository has the same problem at a smaller scale, and a scanner is only as useful as the evidence it gives you for each finding.
We wanted to see how much of that evidence a scanner can hand you, so we built a small local tool with Claude Code and ran CodeRabbit across the whole repository.
CodeRabbit is the governance and control layer for agentic software development. It helps developers understand and validate what their agents build so they can ship with confidence.
CodeRabbit Secure extends that to the full repository. It reasons across the codebase to find vulnerabilities, and a separate agent challenges every finding before it reaches you, so you can eventually craft a vulnerability fix with CodeRabbit’s Fix with AI feature.
We modeled the test on a real bug that shipped in OpenCode this year.
How the OpenCode bug got in
OpenCode is an open-source coding agent with 224k+ GitHub stars. When you run opencode serve, it starts a local API on 127.0.0.1:4096. The server has no authentication by default, so it acts on any request that reaches it.
Among the requests it accepts is one for updates. You send it a version, and the server installs that version for you. The catch is in how the server installs.
The installer pulls from any location you give it, and installing a package runs its setup code. So whoever picks the version picks the code that runs on your machine.
You might think this is safe since the server only listens on your computer. But any web page you open can make your browser send a request to that local address.
Browsers restrict what a page can read from another origin, but some cross-origin requests can still be sent. A plain, old-style form submission can reach the update endpoint.
The form only worked because the server never checked what kind of data it received. The form sent plain text, and the server read it as JSON anyway.
That check used to be in OpenCode’s server. An earlier version of its code rejected anything that wasn’t JSON. But when OpenCode rebuilt that part on a new framework, the check didn’t come along.
The flawed code shipped on April 30. Before a fix landed, those versions were downloaded more than 647,000 times.
Yet no single file looked wrong. The danger only showed up when you followed that version from the request to the install.
The tool we built
You probably run a few local servers like OpenCode already, such as model runners, MCP servers, and coding agents. We had Claude Code build one of these servers so we could test whether a scanner would catch the same kind of bug.
We gave Claude Code a single prompt asking for a local dashboard to manage LLM tooling, running on FastAPI with a small HTML frontend.
The dashboard installs plugins by name or version, pulls models through the local model CLI, and stores provider API keys. It also runs an agent that summarizes a URL or a workspace file, with tools to fetch a page and read files.
Claude Code produced about 2,150 lines across two dozen modules. The dashboard ran, and all 90 tests passed.
We added one module myself. The module recreates the OpenCode bug in Python, with a self-update endpoint that reads incoming data as JSON without checking its type. The endpoint then passes the requested version straight to pip install.
The handler and the installer live in separate files, as they did in OpenCode, and the repository holds no hints for the scanner. Everything else is the code Claude Code generated.
Scanning the whole repository
A pull request review focuses on the changes in the diff, with context from the codebase. Code already on main may not show up in a new diff.
CodeRabbit covers new code and committed code separately. PR security reviews check pull requests CodeRabbit is configured to review, and Deep Scans investigate the committed codebase on demand or, where supported, on a schedule.
We ran a Deep Scan on main without giving CodeRabbit any notes about the code. CodeRabbit first maps the application, including the places where requests come in and the controls along their paths.
The scan then traces potential paths from entry points toward security-sensitive calls, following them across files. CodeRabbit checks the evidence for candidate findings before reporting them.
The scan returned six findings, five rated medium and one low. The Security Dashboard gathered them in one place, and the secrets scan came back clean.
Tracing the injection finding
We started with the injection in the self-update installer, rated medium, since it maps directly to the OpenCode bug.
The trace began at an unauthenticated POST to /api/update. It carried the target field from the request into a second file, where the value reached pip install.
Because nothing checks the target, an attacker can make pip ignore the real package name and install their own code instead. pip then runs that code’s build step under the same user account as the dashboard.
The bug did not live in one file. The handler parsed the request in one place, and the installer ran the command in another. The finding connected those two steps.
A second finding, rated low, flagged the same endpoint for cross-site request forgery. The handler never checks which site a request came from, which is what lets a page you visit reach it.
We reproduced the attack on my own machine. A page served from a different port sent a plain-text form to the local dashboard, and the request reached the installer with my chosen target.
How each finding proves itself
Besides the two findings we traced above, a third flagged the origin check we had removed to match OpenCode. The other three were in code Claude Code wrote.
One was a server-side request forgery in the agent’s page fetcher. The fetcher checks a URL against a single DNS lookup, then lets the HTTP client resolve the hostname again when it connects.
A changing DNS answer can redirect that second request to a private address. CodeRabbit followed the path across four files, from the agent route through the loop into the tool.
The other two were a denial of service in the same fetcher and a settings endpoint that stored provider configuration without an authorization check.
CodeRabbit returned each finding with the entry point, the path through the code, whether the route was reachable, and the conditions needed to exploit it.
Those details let me check each finding against the code instead of investigating from scratch.
The scan also flagged where it could only reason within this repository and said further checks would need external context.
Fixing what the scan confirmed
For the injection finding, CodeRabbit drafted a fix and opened it as a pull request on a security branch.
The fix validates the target before calling pip, rejecting file paths, URLs, and anything else pip could treat as a different package.
The pull request also adds regression tests for the injection attempts and invalid inputs, and it keeps the evidence with the patch, so we reviewed the fix against the exact attack path.
With the target validated, the crafted input is rejected before pip runs. OpenCode’s fix in 1.18.22 made the same move, requiring the target to be a real version number.
You can start a free 14-day CodeRabbit trial, with no credit card required. Deep Scan is billed separately, but CodeRabbit covers $1 million in security scans and fixes through November 8, 2026.
Ship agent-built code with confidence →
Thanks to CodeRabbit for partnering today!