I posted a comment on the announcement when it was posted here:
>As someone who is working in incident response and malware analysis I have to say that is one of the worst ideas I have ever seen.
A lot of companies have issues with ClickFix [1] and other social engineering campaigns and now Google wants to teach users that they should scan QR codes to proceed on a website.
>How should we realistically teach Susan from HR the difference between a real Google Captcha QR code and a malicious phishing QR code - you (realistically) can't. I wish we could - but those people don't work in tech, they will never know and I can't really blame them because at the end of the day they are just happy that they don't have to deal with tech after work.
>We have spent years of behavioural conditioning to prevent QR-code based phishing attacks (some people call it Quishing but I hate that term) and since the QR code is being scanned from a mobile device (99.99% of the time the private device), we have no EDR visibility on those devices and can't track what's happening if people scan it.
>This is more of an invitation for threat actors than it is something that holds them back.
As someone who is working in incident response and malware analysis I have to say that is one of the worst ideas I have ever seen.
A lot of companies have issues with ClickFix [1] and other social engineering campaigns and now Google wants to teach users that they should scan QR codes to proceed on a website.
How should we realistically teach Susan from HR the difference between a real Google Captcha QR code and a malicious phishing QR code - you (realistically) can't. I wish we could - but those people don't work in tech, they will never know and I can't really blame them because at the end of the day they are just happy that they don't have to deal with tech after work.
We have spent years of behavioural conditioning to prevent QR-code based phishing attacks (some people call it Quishing but I hate that term) and since the QR code is being scanned from a mobile device (99.99% of the time the private device), we have no EDR visibility on those devices and can't track what's happening if people scan it.
This is more of an invitation for threat actors than it is something that holds them back.
From my experience OpenAI has become very sensitive when it comes to using their tools for security research.
I am using MCP servers for tools like IDA Pro or Ghidra (for malware analysis) and recently received a warning:
> OpenAI's terms and policies restrict the use of our services in a number of areas. We have identified activity in your OpenAI account that is not permitted under our policies for:
- Cyber Abuse
I raised an appeal which got denied. To be fair I think it's close to impossible for someone that is looking at the chat history to differenciate between legitimate research and malicious intent. I have also applied for the security research program that OpenAI is offering but didn't get any reply on that.
> Importantly, this work also highlights the defensive implications of such techniques. While Secure Boot and firmware integrity mechanisms would prevent this attack chain when correctly enforced, the explicit requirement for users to disable Secure Boot demonstrates how social and usability tradeoffs continue to undermine otherwise effective platform defenses.
You can define the tools that agents are allowed to use in the opencode.json (also works for MCP tools I think).
Here’s my config: https://pastebin.com/PkaYAfsn
The models can call each other if you reference them using @username.
Nope it isn’t. I did it as a joke initially (I also had a version where every 2 stories there was a meeting and if a someone underperformed it would get fired).
I think there are multiple reasons why it actually works so well:
- I built a system where context (+ the current state + goal) is properly structured and coding agents only get the information they actually need and nothing more. You wouldn’t let your product manager develop your backend and I gave the backend dev only do the things it is supposed to and nothing more. If an agent crashes (or quota limits are reached), the agents can continue exactly where the other agents left off.
- Agents are ”fighting against” each other to some extend? The Architect tries to design while the CAB tries to reject.
- Granular control. I wouldn’t call “the manager” _a deterministic state machine that is calling probabilistic functions_ but that’s to some extent what it is? The manager has clearly defined tasks (like “if file is in 01_design —> Call Architect)
Here’s one example of an agent log after a feature has been implemented from one of the older codebases:
https://pastebin.com/7ySJL5Rg
Ok it might sound crazy but I actually got the best quality of code (completely ignoring that the cost is likely 10x more) by having a full “project team” using opencode with multiple sub agents which are all managed by a single Opus instance. I gave them the task to port a legacy Java server to C# .NET 10. 9 agents, 7-stage Kanban with isolated Git Worktrees.
Manager (Claude Opus 4.5): Global event loop that wakes up specific agents based on folder (Kanban) state.
Product Owner (Claude Opus 4.5): Strategy. Cuts scope creep
Scrum Master (Opus 4.5): Prioritizes backlog and assigns tickets to technical agents.
Architect (Sonnet 4.5): Design only. Writes specs/interfaces, never implementation.
Archaeologist (Grok-Free): Lazy-loaded. Only reads legacy Java decompilation when Architect hits a doc gap.
CAB (Opus 4.5): The Bouncer. Rejects features at Design phase (Gate 1) and Code phase (Gate 2).
Librarian (Gemini 2.5): Maintains "As-Built" docs and triggers sprint retrospectives.
You might ask yourself the question “isn’t this extremely unnecessary?” and the answer is most likely _yes_. But I never had this much fun watching AI agents at work (especially when CAB rejects implementations).
This was an early version of the process that the AI agents are following (I didn’t update it since it was only for me anyway): https://imgur.com/a/rdEBU5I
I am still torn on this issue. On the one hand, it feels like a copyright violation when other people's works are used to train an ML model. On the other hand, it is not a copyright infringement if I paint a picture in the Studio Ghibli style myself. The question is whether removing a ‘skill requirement’ for replication is sufficient grounds to determine a violation.
>As someone who is working in incident response and malware analysis I have to say that is one of the worst ideas I have ever seen. A lot of companies have issues with ClickFix [1] and other social engineering campaigns and now Google wants to teach users that they should scan QR codes to proceed on a website.
>How should we realistically teach Susan from HR the difference between a real Google Captcha QR code and a malicious phishing QR code - you (realistically) can't. I wish we could - but those people don't work in tech, they will never know and I can't really blame them because at the end of the day they are just happy that they don't have to deal with tech after work.
>We have spent years of behavioural conditioning to prevent QR-code based phishing attacks (some people call it Quishing but I hate that term) and since the QR code is being scanned from a mobile device (99.99% of the time the private device), we have no EDR visibility on those devices and can't track what's happening if people scan it.
>This is more of an invitation for threat actors than it is something that holds them back.
[1] https://www.kaspersky.com/blog/what-is-clickfix/53348/