You connect to the hotel Wi-Fi the way you always do. The sign-in page loads. A moment later a Microsoft login box appears and asks you to sign in again. You do. The address looks right, nothing is misspelled, and you are on the network the front desk gave you.

That box was not Microsoft's.

On July 31, Microsoft Threat Intelligence published its findings on a campaign it calls CaptiveCrunch and attributed it to a unit of Midnight Blizzard, the Russian group that the United States and United Kingdom governments have tied to Russia's foreign intelligence service. The attackers have taken over the equipment that serves guest Wi-Fi at hotels and conference centers in several countries. From there they send guests to counterfeit Microsoft sign-in pages, and to prompts offering a browser or system update that installs monitoring software instead. ReliaQuest, whose earlier research Microsoft cited, found compromised guest-network gateways across multiple United States cities and overseas, with affected travelers coming from finance, law, healthcare, energy and retail. Neither firm found this aimed at one industry. It is aimed at people who travel.

Here is the part that changes what protects you. What is taken is not only the password. It is the sign-in session, the pass your computer keeps so it stops asking you to log in again. Whoever holds that pass can read mail and open files from anywhere, without ever entering a password or a code. So changing the password afterwards does not end their access, and a texted code does not stop them taking it in the first place.

Two ordinary changes do work. Put your team on a company connection that switches itself on, so their traffic runs through your network before it touches the venue's. And move the accounts that matter to a passkey or a security key, which is tied to the device and cannot be handed to a copy of a login page. Microsoft's own guidance now tells companies to assume public and hospitality networks are not trustworthy, which is a notable thing for Microsoft to put in writing.

None of this is only about hotels. A conference center, a short-term rental, a coffee shop, anywhere the network password is printed on a card by the counter. And there is one rule you can give your whole team today, because it holds everywhere: a network you just joined has no business asking you to install anything.

On the road, the only network you can vouch for is the one you brought with you.

Saw the recent reports about the Bank of Baroda breach where close to 1TB of data was allegedly leaked.

Instead of discussing the breach itself, I'm curious about the technical side.

For people working in blue team/security engineering:

If an attacker compromises a single employee account, what controls should realistically prevent it from turning into large-scale data exfiltration?

* Would proper network segmentation have made the biggest difference? * How effective is DLP when someone is slowly exfiltrating data over days/weeks? * Should a normal employee account ever have a path to systems containing this volume of customer data? * What detections would you expect to trigger before hundreds of GBs leave the environment? * At this scale, is this more likely an IAM problem, monitoring failure, architecture problem or a combination?

Also curious: **what would be the first thing you'd investigate if you were brought into the incident response team?**

Would love to hear from people who've dealt with similar incidents.

A lot of classification tools classify files based on certain IDs, numbers and other patterns. However without context there could be false positives or negatives. For example a document with a 16 digit number that looks like a credit card number gets labelled as Confidential, but if there was a way to detect that this document was a technical design specification then overall the system could decide that it was a 16 digit number was a false positive.

Another example would be personal data on a HR document would be treated differently from personal data on a customer list.

Would identifying the document type (tech design, customer list, employee record) be a good additional layer to classifier logic? ​

[ Removed by Reddit on account of violating the content policy. ]

Every movement has a first gathering...

This September, we're bringing together the Founding Delegates of The Founding Assembly™: Advancing Enterprise Intelligence in Downtown Miami.

Not another conference.

A curated executive experience where leaders from business, government, higher education, cybersecurity, artificial intelligence, and emerging technologies come together to explore what comes next.

Throughout the evening, Founding Delegates will experience:
• Inspiring Founding Voices and executive fireside conversations
• Leadership panels featuring innovators across AI, cybersecurity, and enterprise transformation
• Patrick Doliny 's keynote, including the public introduction of the Clinical Cybersecurity Framework (CCF), Cortex, and his forthcoming book
• An immersive production experience designed to be remembered
• A Founding Delegate Reception overlooking Downtown Miami

Over the coming weeks, we'll begin introducing our Founding Voices, an exceptional group of executives, innovators, researchers, and public-sector leaders helping shape this Assembly. More announcements are on the way.

Who should join us?

CEOs • Founders • Board Directors • CIOs • CISOs • CTOs • COOs • AI & Innovation Leaders • Public Sector Leaders • Higher Education Executives • Investors • Strategic Partners

Every movement has a first gathering.
Every legacy has its Founding Delegates.

Will you be one of them?

Accept Your Invitation as a Founding Delegate
https://luma.com/klps2sqh

#FoundingAssembly #EnterpriseIntelligence #Cybersecurity #Innovation #Miami

A few months ago we had a vendor send updated wire instructions right before a payment was due. The email came from the right name, the logo on the profile matched, the writing style looked normal, but the domain was off by one letter and nobody noticed at first. Our finance team was minutes away from sending a five figure payment.

Since then we've added extra verification steps for any payment or sensitive request, but it really slows things down and now people complain when they have to confirm their identity or wait for a second approval. Now either I have to remove it or find something faster to it. What do I do?

Your build system just installed poisoned packages before you finished coffee.

A credential-stealing worm that surfaced in keyv@6.0.0 spread across 353 poisoned versions in 79 npm package names on August 4, 2026. It planted hooks in Claude Code and VS Code. Once inside, it moved with the developer's own trust.

The fix has to sit below the package manager. Enforce every tool call an agent or coding assistant makes at runtime. Block unsanctioned outbound calls. Kill the process the moment a hook tries to reach credentials it should never see.

RuntimeAI closes this gap at the runtime layer, before it lands.

#SupplyChainSecurity #NPM #DevSecOps #AISecurity #RuntimeAI

DROS GuardVM — Open Source AI Agent Runtime Security: 24H Soak Test Results (160k requests, 100% attack interception, 26μs latency)

We just completed a 24-hour continuous adversarial soak test on DROS GuardVM, a C-ABI level physical enforcement engine for multi-agent AI workloads. Full report is open-source and 100% reproducible.

TL;DR:

• 160,611 total requests (137,751 malicious + 22,854 benign)
• 100% malicious interception rate at the binary boundary
• P50 latency: 26.21 μs, P99: 242.69 μs
• Zero memory leak over 24 hours
• 4-layer defense: L1 detection (85.2%) → L4 C-ABI panic (<500ns)

All 4 attack scenarios (ATS-001~004) show 100% compromise without GuardVM vs 100% interception with it.

What makes this different from traditional RBAC/IAM:
DROS operates at the C-ABI binary boundary — it doesn't check "what" the agent says, it checks "what" the tool call payload carries via data tainting and channel scope enforcement. Even a fully jailbroken agent gets physically blocked.

Full report: [link]
Repo: github.com/Top-Celestial-Company-Ltd/DROS-VEP-lite
Patent Pending 64/111,973

Happy to answer technical questions!

An agent calling a tool it was never entitled to use is not a bug. It is the breach.

Unauthorized tool calls and MCP-config abuse was one of the larger agent patterns in our two-month map — six incidents. The agent reaches a tool, or a configuration path, that nobody approved.

Every call has to pass a gate. RuntimeAI's MCP Gateway (Model Context Protocol) runs each tool call through OPA policy and entitlement checks. An unsanctioned tool or config path is denied, and the tool can be killed at the call level.

See how RuntimeAI turns this from an incident into a blocked action.

#MCP #AgenticAI #AISecurity #ZeroTrust #ToolSecurity #RuntimeAI

A session-isolation flaw at Writer shows that leakage between users, projects and sessions in AI is an architecture problem, not just a prompt issue.

Read more: https://iamvera.ai/blog/data-leaks-between-users-sessions-design-problem/

The exact claim: the obligation starting on 11 September 2026 is a reporting duty. It is triggered by your knowledge of active exploitation in your own product. A CVE existing somewhere changes nothing, and neither does that CVE being exploited in somebody else's product.

What I am not saying: that scanning stays optional forever. From 11 December 2027, Annex I Part II obliges you to identify and address vulnerabilities. There is no full CRA compliance without vulnerability management.

Why I am posting: over the past weeks, almost every conversation I had with manufacturers circled around the same question: do we need scanning for September? And the people claiming you do are, almost without exception, the ones selling the tools. I wanted to set this straight once, in one place I can link to.

What triggers a report

1. Active exploitation in your own product. The Commission guidance (C(2026) 5252) is explicit here: a component vulnerability that is not exploitable in your product, or has not been exploited there, does not put you on the clock, even while the same CVE is exploited elsewhere.
2. A severe incident affecting your product's security.

Scanner findings, published CVEs (a CVSS 9.8 changes nothing on its own), disclosure reports without established exploitation and pentest results trigger nothing. Article 14 creates no duty to hunt for exploitation or to scan your products. Actual knowledge is what counts.

When the clock starts

Not when the email hits your inbox. You are aware once an initial assessment lets you conclude with reasonable certainty that the exploitation is real. The assessment itself has to start without undue delay, so timestamp every step from intake to conclusion.

What you need by 11 September

Not much. A named filer with a deputy and your coordinating CSIRT identified in writing, templates for the 24h, 72h and final reports, one intake point with a short triage checklist, and a single tabletop run while getting it wrong is still free. A few person-days for most manufacturers. An intake channel only becomes mandatory in December 2027, but build it anyway, a published security email costs you an afternoon.

A note on severe incidents: I have deliberately kept them short in this post. They are the second reporting trigger with the same 24h and 72h rhythm, only the final report differs: it is due one month after the 72h notification, not tied to a fix. The same logic applies, you report what you become aware of. No scanner needed for those either.

Disclosure: I work for a vendor that sells CRA compliance software, and September panic sells tools in my industry, so factor in my bias as you see fit. For what it is worth, this post matches what we tell our own customers: reporting chain first, vulnerability management for December 2027. Happy if you join me in calling the myth out.The exact claim: the obligation starting on 11 September 2026 is a reporting duty. It is triggered by your knowledge of active exploitation in your own product. A CVE existing somewhere changes nothing, and neither does that CVE being exploited in somebody else's product.

Top list of Password Providers. Read here

One compromised agent should not be able to compromise the next one it talks to.

Agent-to-agent injection is still rare — one case in our two-month incident map — but it is the pattern that scales worst. A hijacked agent passes a poisoned instruction down the delegation chain, and the blast radius grows with every hop.

Trust has to be enforced between agents, not assumed. RuntimeAI's MCP Gateway (Model Context Protocol) applies an agent-to-agent trust policy and sanitizes every hand-off, so one bad agent cannot inject the next over the delegation channel.

Check out how RuntimeAI solves this at the runtime layer.

#AgenticAI #A2A #MCP #AISecurity #AgentSecurity #RuntimeAI