DEV Community: Mikail Kocak

Vulnerability hunting without OpenAI 'Daybreak' access

Mikail Kocak — Sat, 24 Oct 2026 18:25:05 +0000

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:

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)
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?)
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)
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, ...)
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.

‍

Vulnerabities are being exploited faster than ever: opportunity in disguise

Mikail Kocak — Tue, 07 Apr 2026 08:31:35 +0000

The Zero Day Clock is now at 1.0d TTE (Time-to-Exploit), meaning vulnerabilities are getting exploited within 1 day on average. 50% of vulnerabilities are exploited within 17 hours.

Source: https://zerodayclock.com/

That's a crazy time for cybersecurity! On one hand we have TTE approaching zero, and on the other hand we are actively throttling dependency updates in our software due to the increased risk of supply-chain attacks (or as PyPI puts it: we are no longer drinking from the firehose)

So we have three problems:

We need to patch CVEs faster, and unlike attackers: moving fast is risky. One wrong patch or one wrong live-patching can lead to downtime or can lock out legitimate users. Unlike attackers: we have something to lose, and we have processes that we need to follow.
We need to slow down updates due to increased risk of supply-chain attacks
And at the same time, the volume of new CVEs is increasing alarmingly

This is an interesting dilemma. This is something that traditional processes cannot handle efficiently and requires increased automation.

Rather than panic, we can treat TTE approaching zero as an opportunity. You need to build solid defenses: zero trust, defense in depth, WAF, API Gateways, and defensive programming should be a must, and not a nice-to-have. Defensive programming is especially powerful. Take Log4Shell: how could you have prevented it from being exploited in your application?

With these defenses in place, you are on the right side of the TTE curve, the next CVE won't become a disaster and it will be an opportunity: fast exploits are fast feedback. The speed allow you to quickly verify where your defenses are working well, and where they need to be reinforced.

This is the new reality for defenders. TTE is shrinking, but with the right defenses, it becomes a tool, not just a threat.

Fast exploits = opportunity to validate defenses

Controlling AI Sprawl in a Startup Environment

Mikail Kocak — Wed, 25 Feb 2026 18:13:07 +0000

You probably felt it: new AI tools are constantly popping up, engineers experiment with running multiple agents concurrently and marketing team is using other tools.

It can feel overwhelming, it can even feel impossible. Especially in a startup or small business: limited budget and resources. Meanwhile, the AI space is evolving fast while security teams can be left in the dust.

You might even think:

"If companies 10x or 50x bigger than mine are struggling, how can my startup even have a chance?"

You are not behind, you are not failing, you aren't alone, and company size doesn't matter.

Worry shows up when we believe we have no control over the outcome. So you should ask yourself: "how do I gain control?". This is an incremental process, you don't need perfection.

In this article, I'll share what I learned on how to tame what I call AI sprawl, and without burning out you or your team, and importantly: without stopping innovation.

So let's see how you can surf the AI wave!

The Challenges

First of all, let's take a look at the key issues startups and small businesses are facing:

Shadow AI - if you know the term "shadow IT" then this will sound familiar: it's the use of unsanctioned AI tools inside the organization, these are AI providers, chatbots, local models, tools, extensions, skills, MCPs, agents, etc.

The ecosystem is constantly expanding, new tools appear faster than policies can be written and that speed can feel intimidating. Speed itself isn't the enemy but rather the lack of visibility.
Shadow Cloud - Shadow AI rarely exists alone, it's connected with unsanctioned Cloud storage (OneDrive, Proton Drive, Google Drive, …), personal Cloud Computing accounts (AWS, GCP, Azure), SaaS platforms (Notion, Grammarly, etc.), personal VPS or Cloud Compute instances.

This isn't malicious most of the time, but rather about convenience. It creates blind spots, we do not see nor know what is leaving our environments, credentials are stored in unknown systems, security is never reviewed. It's a black box. The issue isn't experimentation but rather the unchecked experimentation.
The visibility problem - when Shadow AI and Shadow Cloud expand unchecked, the organization starts losing situational awareness. You don't know where the data is flowing to, what or who is processing it, what is connected to what.

All this uncertainty is very dangerous.
The startup culture (this is not a bug!) - startups are full of builders and enthusiastic people: they experiment, they optimize, they automate. Security losing sleep over innovation is a sign of growth and not failure.
And what's most important: security must be an enabler, not a blocker.
There are so many tools, so much stuff. It's hard to know what to focus on.
Constrained resources, startups have very limited number of people, time, and budget. That's normal, and that's part of the fun in startups.
Agentic systems are junior employees at machine speed, they make decisions, call API, trigger workflows and modify data very quickly. They are junior employees except they move at machine speed.

Now, the question is: what do we actually do? Controlling AI sprawl isn't about building a fortress overnight but rather about gradually regaining control, empowering your employees, and creating safe and flexible guardrails.

I recommend a four-step approach:

Step 1: Talk.

The first step can be summed by one word: talk.

Your goal objective is not to restrict employees or to slow down innovation but rather to understand why they are using these tools and how you can create a safe environment together. On top, you might be surprised by the ideas and solutions the teams have.

This is critical for three main reasons:

Trust - you are engaging, you are demonstrating that you are an ally. Without trust employees may attempt to bypass the controls you try to implement which defeats the purpose.
Insights - you will understand what tools people are using, why they use multiple tools, and what workflows are critical. Make sure to document these insights but remember that AI is evolving quickly thus this needs to be a living document.
Champions & Feedback lines - you are indirectly establishing feedback lines, and at the same time you are able to identify potential AI security champions. You need to look for employees who seem passionate about AI safety. These people can become your "Safe AI Use Committee" or your champions that help you build and iterate a robust AI security program.

Some employees can be pretty passionate about AI, you might get surprises!

Step 2: Governance

Once you understand the landscape, you can start building policies. Policies are one of the most powerful tools: they are low-cost and flexible.

Focus on directives rather than implementing technical controls otheriwse it's time consuming, costly, and makes it difficult to experiment. And most importantly: you are reducing risks quickly.

To start, perform a simple risk assessment:

What are the key risks?
How could they materialize?
What's the impact?
What directives can reduce the likelihood and severity?

Engage your AI enthusiasts in this step, they often have insights that will make policies more practical and easier to adopt.

Finally, define metrics to track the effectiveness of your policies and monitor risk levels over time.

Step 3: Keep Monitoring & Iterating

Now, once you have the policies, you need to keep monitoring and keep iterating using the metrics you defined.

Remember: policies aren’t "set and forget".

As well, keep your feedback lines open, regularly check-in with team leads, or employees with influence, and your champions.

Again: talk is your greatest tool, this builds trust and ensures employees see you as an enabler, not a blocker.

Step 4: Technical Controls

Once you have a solid and stable foundation, you can start investing in technical controls. These tools can help enforce your policies at scale and further reduces (or even eliminates) the identified risks.

For example, startups may consider:

EDR/XDR - for example Wazuh if you are on a tight budget.
Purchasing enterprise plans for AI tools such as Claude, they give you a lot of control.
Use scanning tools for things like MCPs, AI skills, models, etc. - for example companies like Socket and Snyk are creating amazing (and open-source) tools around AI: use them.
Use custom AI configurations, for example the ~/.claude folder allows to manage global settings and you can create custom security hooks, or AI skills focused on security, etc.

So, remember: it's a leadership moment. If you approach AI with fear, you will burn out. Instead approach with curiosity.

Your friends are:

Talk
Governance
Your colleagues and champions

And lastly: size doesn't matter. You don't need to be a tech giant to tame AI.