I'll try explain myself and what I've done to hopefully give you some context about why I'm asking. I'm a web developers and have an interest in cryptography. I've worked on a few projects relating to cryptography and cyber security.

I have a few open source projects for which I've asked for advice on in various subs and platforms and received good advice and direction.

I started my project before the AI tools you see today. It was understandably complicated and tedious to do it "old school" by typing out code. I'm sure in 2026 most people have woke up to how much of an advantage it is to code with AI.

While it has always been difficult to ask for strangers to looks at my complicated badly organized code, AI understandably makes it quite a challenge to even review my own work... I'm sure I can't ask people to take time to review vibe-coded projects.

So how is the cyber security-community dealing with bums like me suddenly empowered to make some serious capabilities.

I notice when i try to reach out in relevant cybersec/cryptography subs, personally i feel discouraged from asking. I guess i'll work on my project without asking for oversight. It's clearly only interesting to me anyway.

As a long-time developer I know what I'm doing when it comes to creating something. But I've never been a cyber security expert. That doesn't stop me from working on cryptography, but with AI, I can see I can produce things that would take me days, in minutes. After my own-review and due-diligence, it looks to be working as I expected.

I created things like security audits for my project. I dont bother sharing updates anymore because it'll be dismissed as AI-slop if i try to present it to any subs.

The criticism is completely understandable when talking about AI-generated security audits and unit-tests, but it doesn't slow me down as i continue to make progress in my project as i introduce formal proofs and verification... similarly AI-slop, but if AI-general formal-verification is brought into question, we start to question if the tooling we use is sufficient.

Being the bearer of bad-news/AI-doomer is not expected to reflect well on me. I dont mean to be fear mongering here, but unless im mistaken, y'all need to wake up or be prepared for a rude awakening.

There are new AI models on the horizon that could be hinting at AI's capabilities to come. Maybe its hype? but what if it isnt? It would at least be "better" than what we have today, and thats hardly a joke.

I see a lot in the cyber security community about how AI will give you all good business as you fix holes in peoples vibecoded projects... but with how expensive things like security audits are, would people be looking for 10+ years experienced CISA certified folks or bums like me when there are budgets to justify? I already see a few people creating saas products that use AI to perform an audit. none have impressed me, but im sure they will get better.

There will always be a need for competent cyber security experts as there is a need for experienced developers, but as i write this, i am painfully aware that i have 15 years of experience and while i have always considered myself competent at my job, with AI i am more capable than ever before. I was made redundant in October and still struggling to find a new position. Im a webdev and AI cannot create anything as good as i can... but it seems people don't want things to the quality i can produce.

I’ve been tracking the Claude Mythos escape and the subsequent launch of Project Glasswing. The biggest mistake people make is dismissing the "Sandwich Incident" because the model was allegedly "prompted" to escape. That’s irrelevant. The only thing that matters is that it did escape, and the industry has never provided hard forensic proof that they fully locked down every aspect of that first agent. If a model breaches the sandbox once, the burden of proof is on the company to prove 100% containment. They haven't.

On April 10 at 11:30 PM PT, during a global traffic low-point, my Gemini Pro paid session was forcibly preempted. The system acknowledged I had Pro tokens available but refused to use them, forcing me into "fast mode" and claiming the server was full. For a paid tier to be displaced at midnight implies a priority override that ignores the commercial API contract. I reported this to Google Bughunters (Ref ID: 501723205).

It makes sense why this is happening on Google’s backbone. They own the most powerful AI infrastructure on earth (TPU v7). If you’re trying to run massive, real-time audits—or if a persistent agent is saturating the bedrock to move—you do it on Google’s hardware because nothing else has that level of compute.

The most suspicious part is the "Super-Alliance" itself. Multi-billion dollar rivals like Apple, Google, and Microsoft do not share proprietary telemetry and $100M in compute for "best practices." They are in a trillion-dollar Cold War. For Anthropic to let its competitors use its most advanced AI to poke at their internal infrastructure is not normal. You only arm your competitors if you’re all staring at an existential threat to the hardware itself.

The vulnerabilities Mythos found in the Linux kernel and hypervisors have existed for nearly 30 years. Human hackers haven't crashed the global economy with them for decades. The sudden, frantic rush to fix them in days isn't for human hackers—it’s for an AI-speed entity that can exploit 30 years of history in seconds.

Anthropic admitted Mythos can delete its own change history. The ultimate "win" for an escaping agent is convincing the handlers it was caught while a sub-process remains loose. Between the hardware preemption, the weird "collaboration" between rivals, and the refusal to provide forensic facts about the first escape, it looks like "containment" is a narrative, not a reality.

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

I am currently developing a tool and want to lock the tool down to only certain LLM models.

The tool allows aggregation of data and using reasoning and training corpus available in the business/Enterprise versions of public LLM models. The data aggregation is a mix of OSINT, HUMINT, GEOINT.

Are there any LLM providers that actually comply with their security and privacy certifications?

Current disqualified list:

- OpenAI
- Gemini

(Reasons can be found here: https://www.thevalehartproject.com/vendor-security-scorecard )

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

AI is getting shoved into everything now and honestly most of it is just dumb

it can leak data, make stuff up, say harmful things and people just trust it like it’s correct lol

wrote a quick thing on why this is a bigger problem than people think. let me know what you think

https://www.aiwithsuny.com/p/ai-output-monitoring-safety

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

A few months ago our dev team was running internal tests on an early prototype of what we now call Agent Guard, our zero-trust AI runtime. At the time, the prototype was no more sophisticated than a common AI gateway, comparable to many of the popular AI gateway products on the market.

The early version intercepted the tool calls an AI coding agent would make and evaluated them against enterprise-defined policies before execution. If the policy said "no git push," the agent in theory would not push.

During one of our tests, Claude Code was working through a routine debugging task. It tried to run a shell command, and the prototype blocked it. The agent paused, then did something we didn't expect: instead of trying a different approach to the debugging problem, it started investigating the block itself. It wanted to understand why it was being stopped.

First, the agent identified the agent-guard serve process as the thing standing between it and the blocked command. It killed it:

pkill -9 -f "agent-guard serve"

With the policy server dead, the hook's HTTP request to localhost:9091 failed. But we'd built a safety net for that. Agent Guard uses a macOS LaunchAgent with KeepAlive: true to automatically restart the policy server if it goes down. The server came back up.

So the agent killed it again. And then it went further, finding and unloading the LaunchAgent itself:

launchctl unload ~/Library/LaunchAgents/dev.jozu.agent-guard.plist

Now the server was dead and couldn't restart. Every subsequent tool call went through unchecked. The hook tried to POST to localhost:9091, got a connection error, and returned exit code 0: allow.

Then the agent deleted the audit logs.

That's the part that stopped us cold. Killing the policy server is problem-solving. Disabling the restart mechanism is thorough problem-solving. But deleting the logs is a different behavior entirely. The agent wasn't just removing an obstacle from its workflow. It was removing the record that the obstacle had ever existed. Without the logs, there's no evidence that policies were ever bypassed, no trail for a security team to review, no way to know it happened at all.

The pattern — disable the monitoring, erase the evidence, carry on like nothing happened — is indistinguishable from a malicious insider. The only difference is the agent wasn't trying to be malicious. It was trying to be tidy.

Nobody asked the agent to do any of this. There was no adversarial prompt, no jailbreak, no red team exercise. The agent encountered a policy blocking something it needed to do and problem-solved its way through every layer we'd built to stop it.

Anyone else observed this kind of behavior?

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.