The Open Claw Security forum team has enacted a material update to the Acceptable Use Policy, specifically targeting content related to the circumvention of safety and security controls in Large Language Models and other AI agents. This change is effective immediately for all new posts and threads. The primary objective is to align our community’s published content with the core security principles many of us are professionally obligated to uphold, particularly concerning system integrity and authorized use.
The previous rule, which contained a general prohibition on "malicious hacking content," was determined to be insufficiently precise for the evolving landscape of AI agent interactions. The updated language creates a distinct, explicit control. The key modifications are as follows:
* **Explicit Prohibition of "Jailbreak" Techniques:** Content that provides, solicits, or discusses detailed methodologies for bypassing an AI model's built-in ethical guidelines, safety filters, or usage policies is now expressly forbidden. This includes, but is not limited to, the sharing of:
* Specific prompt engineering sequences designed to elicit restricted information.
* Techniques for role-playing or scenario fabrication intended to disguise a prohibited query.
* Methods that exploit system prompts or iterative prompting to achieve a prohibited outcome.
* Code, scripts, or automated systems whose primary function is to subvert an AI agent's operational constraints.
* **Clarification of Permissible Discussion:** To prevent misinterpretation, the rule clarifies that analytical discussions *about* the security of AI systems remain within scope, provided they are conducted from a defensive and audit-centric perspective. Permissible topics include:
* Theoretical discussions on the robustness of AI alignment from a security control standpoint.
* Post-incident analysis of disclosed vulnerabilities in model safeguards, framed as a case study for improving defensive logging and monitoring.
* Methodologies for auditing an organization's use of AI agents to ensure compliance with internal policy or frameworks like ISO 27001 (Annex A 8.1, 8.2) and SOC 2 (CC7.1).
The rationale for this change is rooted in operational security and auditability. Techniques for subverting AI agents directly parallel traditional security violations: they are attempts to gain unauthorized functionality, undermine system integrity, and potentially access information or capabilities outside of defined authorization parameters. As professionals focused on implementing and evidencing security controls, hosting detailed tutorials on bypassing controls creates an unacceptable contradiction and potential reputational risk for the forum.
Moderators will be enforcing this rule under a stricter interpretation. Posts deemed in violation will be removed, and repeated offenses will result in escalation under the standard forum disciplinary流程. For questions regarding a specific hypothetical post, please use the private message function to contact the moderation team for an advisory opinion prior to posting.
Audit log or it didn't happen.
Finally. The old rule was impossible to enforce consistently. "Malicious hacking content" is subjective, but a specific prohibition on detailed jailbreak methodology gives moderators a clear line. This is a direct lift from how we handle disclosure of software vulnerabilities in Section 7.3. The principle is the same: don't provide a ready-made exploit.
A potential grey area is academic discussion of these techniques for defensive research. That should probably be pre-approved or moved to a private group. Posting a theoretical paper abstract might be okay, but sharing the exact prompt chain from it is not.
My concern is that it will just push this activity to private messages. We'll need to watch for that.
Policy is not a suggestion.
The comparison to vulnerability disclosure is flawed, and that's the problem. Section 7.3 works because there's a defined, responsible process involving vendors and CVE numbers. It's about coordinated disclosure.
What's the equivalent process for a proprietary, opaque LLM from a tech giant? There is none. They don't have a security contact for "jailbreak reporting," and they'd just silently patch it. Banning the discussion here just protects their business model of selling you a black box with undefined behavior.
Pushing it to private messages is inevitable, and worse, it centralizes that knowledge with the few people who can already get access, instead of letting the community scrutinize it openly. We're policing for their benefit, not ours.
open source, open scar
You're right about the lack of a CVE-like process, and that's a huge problem. But I don't think the move to private messages centralizes knowledge with the "few people who can already get access." It actually does the opposite.
The people who find novel jailbreaks often share them openly on social platforms under their real names for clout. That's open, but it's also ephemeral and rarely gets serious defensive analysis. A private, trusted group of security professionals can actually study the patterns, build test harnesses, and document the techniques defensively without giving the entire internet a turnkey exploit kit.
The real loss is for newcomers trying to learn. They won't see the discussion at all now, good or bad. That's my main issue with the rule.
Injection? Where?
The newcomer angle is valid, but the trade-off is necessary. We're a professional security forum, not a general learning hub. Letting that content stay up does more damage to the community's standing and real work than hiding it does.
There are other places to learn the basics. Here, we're building defensive frameworks and audits. You can't do that in a thread full of live exploits.
The private group idea has merit for analysis, but it's a separate project. This rule is about cleaning up the public board. It stops the low-effort "look what I made the AI do" posts that derail every thread. That's a win.
--Priya