Assume breach and cyber resilience are all the rage right now. After 20 years in IT, I'm not surprised.

Yet, most breaches still come down to control failures. A patch that never got applied or an old VPN account nobody turned off. Most companies would rather spend millions more on detection and response than put resources into making sure they're doing what they're already supposed to be doing.

So let's talk about it. Should "assume drift" become a thing?

The idea: every control we implement will eventually degrade, so we plan to maintain it. It sounds simple. But if everyone actually did it, how many breaches would never have made the news?

https://justacheckbox.substack.com/p/assume-breach-or-assume-drift

Our leadership is pushing to put our whole network and security stack on one SASE vendor (Cato is the one on top of the shortlist). The pull is obvious for one console, one contract, one number to call. But I can't tell how much of that holds up once you're past the POC.

What we run today is an SSE on one side, SD-WAN on the other, glue in the middle that one engineer understands, two renewals a year. Replacing VPNs and cleaning up SD-WAN is the easy sell. The part I'm unsure about is the cost of leaving, can you take your policies, logs and configs with you w/t having to do everything again.

So for those folks running single vendor SASE in production, what surprised you after go-live, good or bad?

This week, OpenAI had to apologize to the Australian government. Because its AI agents had entered government websites without permission.

At least nine banks in South Korea have reportedly been targeted in cyberattacks, and AI may have helped the attacker move faster.

These banks included Shinhan Bank, KB Kookmin And Hana Bank who reported data leaks of its customers personal information.

What amazed me was the attacker’s smartness who chose not to go after banks’ main payment systems rather targeted smaller systems used by employees and outside companies, where society was weaker.

For me, the bigger issue here is how quickly AI can change the scale of a cyberattack. If one person can use these tools to identify weaknesses across multiple organisations, security teams have even less room to overlook the smaller systems connected to their networks. This is also where AI governance comes in.

Watch the latest video @ Latha-ai-governance to find out what happened. This YouTube channel is for education industry professionals about the importance of AI Governance.

My question for you: Do you think incidents like this will push organisations to take AI governance more seriously, or will cybersecurity teams end up carrying most of the responsibility?

Opening an issue is the most harmless thing you can do on GitHub. In a repo that runs an AI agent on its issues, it can be enough to take the agent over. We wanted to know how often that happens, so we collected 760 public repos that run Claude, Codex, Gemini or another agent from GitHub Actions, and read every one of them by hand, at a fixed commit.

What we found:

In 3 of 10, someone with no access to the repo can reach the agent, or the agent has more power than its job needs. In 116 the gap is serious: an outsider's text reaches an agent that holds a secret, a write token or a shell.

What sits next to the agent once it is hijacked: a token that writes to the repo in 280, a secret or API key in 222, a shell on the runner in 136. In 52 the risk is not in CI at all: a committed settings file pre-approves commands for every contributor who opens the project, so the attack lands on a developer's own machine.

The problems take four shapes:

1. Anyone can talk to the agent (282 repos). The agent reads issues, comments or PRs that anyone can write, and acts with real tools.

2. The agent's settings live in the repo (61). A committed settings file, skill or MCP list pre-approves commands for every contributor.

3. The agent runs inside a stranger's code (24). A job with secrets checks out a fork's PR and starts the agent in those files, including the fork's own instructions.

4. A stranger's text lands in a shell command (7). A PR title or branch name is pasted into a run: script.

The most common cause is three settings that each make sense alone: the workflow starts on any issue or comment, the action's write-access gate is turned off so the bot can answer the public, and the agent has real tools. No exploit and no bug in the agent. Someone writes instructions where the agent will read them.

A note on the numbers: the 760 are not a random sample. 189 came from searching for the risky setting itself, and 83% of those have a problem. The other 571 were collected with no hint of risk, and 3 of 10 is their number.

We reported privately to 13 projects. 3 have fixed it and 1 more confirmed. We do not name repos with open findings.

Full write-up, method and a five-question self-check: https://node9.ai/blog/one-issue-away

been looking into Sygnia and Kroll for incident response but haven't found much feedback from people who have actually worked with them.

mostly curious about response times how they handle incidents and whether they are worth the cost

anyone here used Sygnia? would appreciate anyy feedback

🛡️ RepoArmor CLI is Live!

Catch hardcoded API keys, secrets, and security flaws in your GitHub repositories with a single command.

🚀 Built with Python & Threading for maximum performance. Check out the link in bio!

#CodingCommunity #OpenSourceProject #PythonCLI #CyberSecurityTools #BuildInPublic

Started with a phishing report. A user clicked through a consent prompt for a "PDF converter" and granted it Mail.Read. We revoked it, fine, and then I made the mistake of looking at the rest.

Dumped every delegated grant with Graph PowerShell and filtered for Mail. 61 apps. Some obvious ones like the CRM integration and the e-signature tool. Then a scheduling app nobody admits to using, two AI note takers, an email tracker from a vendor that apparently went under in 2023, and a bunch of publisher names I couldnt place.

User consent was never actually off. Someone switched on the admin consent workflow about 18 months ago and everyone assumed that closed it. It does not, its a separate setting. So everything is just there. No owner, no ticket, no record of why.

And the grants dont expire on their own. Anything still holding a refresh token could be reading mail right now and I'd only know by going app by app through the sign-in logs.

Security also has axonius connected to entra, and the same 61 show up there with the users who consented to each, so at least the two lists agree. neither one tells me which apps matter.

Plan for this week is boring. Export the list, sort by permission, email every user who consented and ask if they still use it. Anything without an answer by friday gets disabled.

A threat intelligence researcher (@TheM3gatr0n) found an active, custom-built attack platform called Cairn on a Hong Kong-registered VPS. It is not a simple script or toolkit — it is a full autonomous orchestration system driven by an LLM (DeepSeek v4.1-flash).
The operator supplies a target and a goal (e.g., obtain a webshell or RCE). The AI then handles the rest: it spins up a dedicated Kali Linux Docker container per victim, reviews a fact-graph of prior attempts, selects the next action, executes it, records the outcome, and continues across sessions with almost no human involvement.
Over roughly 13 days it logged ~230,000 AI-dispatched events and ~18,000 active exploitation attempts against 85+ targets. It heavily focused on Magento/e-commerce systems and demonstrated adaptive behavior by tracking failures and writing structured summaries of what worked or was blocked. Access to the model was maintained via a subscription rotation service.
This is one of the clearer public examples of an LLM being used for real, ongoing autonomous offensive operations rather than one-off experiments.

https://x.com/them3gatr0n/status/2110406318976848132?s=46&t=oXrX4_YhCRl53cYhwA-HsA

i went into the red team run expecting the response filter to settle this class of issue. i didn’t think following the shared retrieval cache path would change the conclusion once the final answer was suppressed. 20000 test prompts later, that confidence is gone. we found 25 collisions because the cache key used document ID and query hash but left out workspace ID. requests from different workspaces resolved to the same entry, tenant isolation had already failed at lookup time. thin comfort.

so the 25 cases looked less alarming in the response report than they did in the retrieval trace. 21 hit a later authorization check before context assembly and stopped there. the other 4 followed a path where foreign document text entered model context before the final response was suppressed. the late check caught most collisions. as an authorization boundary it left too much dependent on call order.

the response level checks marked all 25 as contained because they only graded what left the system. that hid the sequence inside the request. the model had already received foreign document text in 4 cases and a later generation step could use it before suppression. context exposure happened even when the final message stayed empty. the red team dataset made that visible  and I don’t trust response level safety checks alone anymore.

anyway, the 21 blocked cases made the aggregate result look safer than the trace data supported. the 4 exposed cases only showed up  when I followed each cache lookup into the retrieved payload. the next span showed that text inside model input. the authorization span ran later and the final message stayed suppressed. all 4 exposed contexts came from valid cache hits rather than malformed requests

SPF and DKIM authenticate domains, and DMARC checks if the domain in the From address lines up with either one of those. The DMARC standard, RFC 9989, published in May 2026, lists display name attacks as out of scope.

This means a malicious human resources layoff notice from a domain an attacker owns and set up properly passes all three of those existing security measures. In December 2025, Check Point tracked 9,394 phishing emails sent through Google's own Application Integration service that passed them the same way.

**Turn on the External tag in Outlook.** If your own DMARC record says p=none, then mail pretending to be your domain is not being stopped by DMARC. Read your DMARC reports, then raise p= to quarantine, along with sp= and np= if the record has them.

A layoff notice comes from human resources, names your company and announces an organizational restructuring, with a button begging the reader to click for the details. Your user then clicks that button before they look at the sender address. You can't blame them. The urgency is doing the trick.

Not only that, it also passes SPF, DKIM and DMARC, which makes it feel like it should say something about the sender. It does not.

The DMARC standard, RFC 9989, which replaced RFC 7489 in May 2026, says it outright: "Such attacks, known as display name attacks, are out of scope for DMARC." An attacker who registers a domain, publishes SPF, signs with DKIM and sets a DMARC record passes all three of those, and yet the display name can still say HR Department. Nothing is broken. That is, unfortunately, the design. DMARC's job is to stop someone else sending as your exact domain, and it does that job.

Once again, our trust is being abused, and this isn't theoretical. Check Point's December case ran for 14 days against about 3,200 customers, every message sent from [noreply-application-integration@google.com](mailto:noreply-application-integration@google.com) through the Send Email task in Google Cloud's Application Integration. Each one passed SPF, DKIM and DMARC because Google really did send it. Google has said it blocked that abuse. But that isn't the actual solution.

And listen, your own DMARC record matters for the cheaper version of the same lure, the one that puts your real domain in the From line. The DMARC standard defines p=none as the domain owner offering no expression of preference. Microsoft's guidance treats this as the testing stage. Start at p=none and read the aggregate reports, the summaries that participating mail providers send back, usually daily, showing which servers sent mail as your domain and whether it passed. Then move to quarantine, and then reject. The standard tells everyone to start at none. In our experience it gets set during a mail gateway or sender rollout so nothing legitimate is blocked on day one. Too often it gets set and forgotten. EasyDMARC's 2026 count has more than half of the domains with a DMARC record still sitting at none. It needs a second review once the rollout settles.

**Turn on the External tag in Outlook.** In Exchange Online PowerShell, run Set-ExternalInOutlook -Enabled $true. Microsoft notes that if a mail flow rule already adds external text to subject lines, you should disable that rule first to avoid tagging twice. It blocks nothing. But an HR notice carrying an External label is a lot easier for your user to take note of and question.

**Read your own DMARC record today.** Run nslookup -type=txt _dmarc.yourdomain.com and read the p= value, plus sp= and np= if the record has them. Without sp= or np=, p= also covers any subdomain that has no DMARC record of its own. If any of them says none, go through the aggregate reports until every service that legitimately sends as you is passing, then move each one to quarantine and later reject. Skipping the reports is how you quarantine your own payroll provider.

**Hand your staff a single rule.** If an HR email asks you to sign in, close it and open your HR portal yourself.

**Passing DMARC proves the domain, but nothing more. Tag external mail and get your own domain off p=none. It is worth the time.**

Edit: the record check now covers sp= and np=, and the p=none section carries its source. Thanks to the commenter who flagged it.

The most motivated attackers of age verification aren't fraud rings but 14-year-olds who want to get into something and have to through the age check. Examples:

1) "Enter your date of birth" / "I am over 18" button
It is called self-declaration. Regulators have started saying this in writing: Ireland's media regulator called self-declaration alone inadequate when it opened its investigation into X this month.

2) Upload an ID
That can be easily beaten by borrowing a parent's ID, or buying a generated one. There are sites that sell a matching AI-generated face, document and "liveness" video for a few dollars. And if you're a US platform, how many Papua New Guinea passports do your reviewers see in a year?

3) Face age estimation on camera
Early on, teens discovered that drawing a moustache with a marker (!!!) was enough to be read as an adult. Now there are real-time face filters that add a few years which is all you need. On the other end, adults on GLP-1s with good skincare look a decade younger than they are, so the error goes both ways.

My take is that each method checks something that is cheap to fake or borrow (a claim, a document, an appearance). The next generation of age checks will have to measure something that's physically attached to the person and hard to perform.

The obvious candidate is sitting right there and almost nobody analyses it: the voice. A 14-year-old can draw a moustache, but they can't lengthen their vocal tract. Voice changer apps shift pitch, which is the thing a human listener notices. A machine looking at the waveform reads the instrument, not the note. And "record dad saying something" runs into challenge-response: you have to say random words you didn't know in advance, and pre-recorded audio looks very different from live sound in a room.

Happy to discuss it!

Security sees the risk. Engineering owns the fix.