How We Find Critical Vulnerabilities with GLM 5.3 and Red Clippy

Over the last few months our red team exercises for BFSI customers have been run with an AI coding agent sitting in the loop. The findings that came out of them were the usual serious ones: broken authentication, unauthenticated access to sensitive data, an OTP bypass, SSRF, stored XSS, a login form that let us straight in with the password field left empty, a customer search that handed back the entire database when given a wildcard, and on one engagement a payment gateway secret key shipped inside a JavaScript bundle that every visitor's browser downloads.

None of that is exotic. Testers have been finding these things for twenty years. What changed for us was how the work got done, and more importantly, how it got kept.

Give a coding agent a shell and it turns into a fast, tireless tester. It runs the same tools you do. It will read a four megabyte minified bundle line by line without complaining, which is a thing no human on the team volunteers for. It will enumerate an API surface while you are still reading the scope document.

The trouble starts about forty minutes in. The context window fills up. The session compacts, or it ends and you start a fresh one the next morning, and the engagement goes with it. The new session re-scans hosts it already cleared. It re-tests things it already ruled out. Ask it which parts of the scope have been covered and it cannot tell you, because it does not know. And somewhere in a transcript nobody kept there is a confirmed injection that never made it into the report.

That is the problem Red Clippy exists to solve.

An engagement overview. All the screenshots here come from the project's demo database, not from a customer engagement.It is not an AI pentesting frameworkRed Clippy has no scanning engine of its own, no autonomous attack logic, and no opinion about what should be tested next. It will not find a vulnerability for you.
What it does is keep the record of an engagement while an agent does the testing and you direct it. Targets, scope, what has already been tested, findings, evidence. That is the whole job.
It is built for testers who already know what they are doing and want to use Claude Code, Codex CLI, or any other MCP-compatible client alongside their normal workflow. You define the target and scope in the panel, or paste the customer's scope list into the chat and let the agent enter it. From there you guide the agent however you like, the same way you would guide a junior on the team, and it writes down what it did as it goes.
That turns out to be useful for four things: knowing what has already been tested, checking the same finding across multiple domains and assets, keeping engagement history for periodic retesting, and not having to rely on the model remembering everything or on a folder of text files pretending to be a database.The setupThree pieces, all on one machine. GLM 5.3 from z.ai does the reasoning. Claude Code is the client, providing the shell, the file access and the agent loop. Red Clippy holds the record and connects to Claude Code over MCP.
Because it is a client rather than a model, and z.ai serves an Anthropic-compatible endpoint, you can point one at the other and keep the agent harness you already know. The setup is documented on the project page, so we will not repeat it here.
MCP runs client-side, so Red Clippy does not know which model is behind the agent and the tools behave the same either way. That means the discipline of the engagement is not tied to a model you happen to be using this quarter. If we move off GLM next year, the record, the coverage and the findings all survive the move.The rules arrive before the first tool callThis is the part most people skip when they wire an agent into a workflow, and it is the one that changed our output the most.
An agent that has to ask for the rules of engagement generally will not bother. So Red Clippy hands over a Red Team Instructions document during the MCP handshake, before the agent makes its first tool call. It is one document, not a system prompt maintained in five places, and the most specific one wins: a per-engagement override if there is one, otherwise the organization default, otherwise the built-in.
The Red Team Instructions document, served to every agent on connect and overridable per organization and per engagement.
Most of it is unglamorous. The line that matters most on BFSI work is the one about taking the minimum access needed to show impact. An agent that proves an unauthenticated data exposure by retrieving three records and stopping has given you a finding. An agent that helpfully retrieves the whole table has given you a very different conversation with the customer.
The rest is tradecraft, and that is where several of our critical findings actually came from: read the main bundle rather than grepping it, trigger errors deliberately and read the whole response, strip the auth header and retry, then change the identifiers and see whose data comes back.
None of that is new

Read the original article: