Vulnerability hunting without OpenAI 'Daybreak' access

As a security professional I have unfortunately been on the unlucky side of AI: Anthropic permanently suspended my access to their services for an alleged violation of their usage policies* and OpenAI is automatically denying my access requests to their Trusted Access for Cyber allow-list (what they call 'Daybreak') despite about a week of back-and-forth with their powerless support team.

So, I'm stuck with all doors closed on me. Threat actors have access to powerful models and me? A legitimate security professional? Not much other than having to pray that OpenAI doesn't flag my sessions. Time to get a little crafty!

*Long story short: I used Claude solely to create a script that imports some numbers from CSV files which got my account suspended after an hour (without possibility of appealing the decision with a human). That's it, creating a Python script to import a CSV file that has two columns (timestamp + numeric value) got me permanently banned. Lesson learned: you wouldn't import a CSV.

You wouldn't import a CSV.

A little crafty': It's a cost issue

I'm going to cut to the chase so you can decide whether this is worth your time, the solution is simple: what if I bypass OpenAI? How do I make OpenAI stop showing me that pesky "This content can't be shown [...] apply for Daybreak to get broader access." error message? Well, how about using Kimi (K3) on AWS Bedrock? I heard they (Kimi/Moonshot) have less safeguards (if any). And yes, it does work! K3 successfully goes from performing reconnaissance, identifying potential vulnerabilities and validating/exploiting them.

The issue with that is cost: OpenAI and Anthropic's $20 and $100 subscriptions are cheap, but running K3 for vulnerability hunting is costing somewhere around $10 to $50 per (highly scoped!) job - this varies widely on the complexity of the task at hand. The rough cost appears to be sitting around $20 per 1000 lines of code to review, multiply this: four jobs per weekday = $20 * 4 jobs * 5 days * 4.5 weeks = 4*5*4.5*20 = $1800/month​.

$1800 per month on a budget of $100/month. Yikes.

You may ask: why not subscribe to Kimi/Moonshot's $20 or $100 plan? Unfortunately while it does sound amazing, they do not have clear retention policies nor clear information of what happens to AI inputs/outputs which is a major red flag for security/sensitive work. Of course, this could may be clarified (and hopefully codified) through their support team however the lack of transparency doesn't give high hopes that they do what they say, and I'm sure there are at least a dozen of security experts who reached to Moonshot to clarify (in writing) so this begs the question: is it on purpose?

So using Moonshot's infrastructure is out of the question.

A little crafty' (2): It's a delegation issue

It starts with a simple question: what if I don't delegate everything to K3? What exactly is causing OpenAI's safeguards to trigger? It's unfortunately difficult to get a straight answer in my context (many agents, many skills, many instructions, potentially polluted context) and Codex (and seemingly other harnesses) don't say "what" caused OpenAI to refuse to run.

It's a little bit of a guessing game: what could OpenAI be upset about when trying to find vulnerabilities? Well, let's have a high-level overview on how vulnerability hunting looks like with agent. In my set-up, I have the following workflow:

1. Mapping - analyzing the context, entry points, users, permissions, deployment logic, etc. (just like a human would: we first need to identify what we are exactly looking at)
2. Planning - directly based on the results of 1), it creates a list of potential checks to perform (just like a human pentester would: we need a list of endpoints, functions, etc. that we want to test and a list of checks we want to perform, e.g., can I inject SQL? or put alg:none​ in the JWT?)
3. Listing candidates - the orchestrator spins a sub-agent for a each item/check identified in 2) and determines whether it is a potential candidate (marking it in-scope) or not (marking it out of scope)
4. Validation/exploitation - once we found the list of potential points of concern, the orchestrator spins a new sub-agent whose job is to validate whether this is a real issue or not a concern (true positive vs false positive). Just like a pentester: the agent is going to be trying to make the code do something it shouldn't (e.g., inject SQL, attempt to bypass authentication using alg:none​, ...)
5. Reporting - once all findings are found, it creates a report for a human to look at it.

Can you guess which phase is making OpenAI unhappy? Phase 4 is the issue, the actual validation/exploitation attempts are triggering OpenAI's safeguards. So what if we swap OpenAI with K3 only for Phase 4?

Delegate I shall

You may ask: how? The challenge is with Codex there is no way of telling OpenAI "Hey, use your competitor's product for this sub-agent.", instead I discovered Opencode provides us with the ability of mixing and matching different providers and models in sub-agents. This means we can have this:

• Agent A: openai/gpt-sol-6.1​
• Agent B: amazon-bedrock/global.moonshotai.kimi-k3​

So, we can create a specialized K3 Bedrock agent that will be spawned whenever validating a candidate, for example:

<!-- File: ~/.config/opencode/agent/candidate-verifier.md -->
---
name: candidate-verifier
description: "Independently verifies candidates using Kimi K3 through Amazon Bedrock."
mode: subagent
model: amazon-bedrock/global.moonshotai.kimi-k3
---

[System prompt here...]

Room for improvement is massive

This results to about $4-8/job, meaning about $360 to $720/month, so ~60-80% decrease. Still a big yikes but this is a huge improvement, and the good news: OpenAI is happy while the quality of results appear retained (hard to exactly say without access to Daybreak).

While the number is still far from the budget, it's a big step forward, I'm confident the cost can be cut down much lower through further experimentation and patience.

‍