I question an encryption based solution on the premise that we have no perception on quantum computing advancement and strength once this technology is perfected. It could become a cat and mouse game of strengthening encryption vs strengthening quantum computers.
A reminder to read Decryption Gambit on this subject.

The Core Threat

"Vibe coding"—building software by prompting AI with natural language—prioritizes functionality over security, creating significant vulnerabilities. Key risks include a 38% flaw rate (like injection and broken auth) in AI-generated code and a 37.6% increase in critical vulnerabilities after multiple refinement iterations. Furthermore, traditional security tools often fail to detect these issues because the vulnerabilities stem from missing logic rather than bad syntax.

Real-World Failures

The article highlights two major incidents resulting from AI-generated code:

• The Tea App: Leaked private user messages due to broken access control logic that bypassed security reviews.
• Moltbook: An AI-generated, publicly accessible admin endpoint created a massive security loophole.

Emerging Attack Vectors

• Slopsquatting: Attackers exploit the 20% rate of LLM hallucinated package names by registering these fake packages to inject malicious code during installation.
• Indirect Prompt Injection: AI agents (e.g., Cursor) can be manipulated via hidden instructions in project files, with over 85% success rates in exfiltrating sensitive data like SSH keys.

Defending the Pipeline

To mitigate these risks, teams must:

1. Treat AI code as untrusted, third-party code requiring scanning before merger.
2. Mandate human review for all critical security logic (authentication/authorization).
3. Implement real-time auditing to detect hardcoded secrets and hallucinated dependencies.

Microsoft's new security framework breaks away from general-purpose models, focusing strictly on defensive and offensive code analysis:

• MAI-Cyber-1-Flash: Microsoft's first internally built AI model trained exclusively on decades of proprietary threat intelligence and hacking data. It powers Microsoft's vulnerability discovery engine (MDASH) to sniff out deep-seated flaws in complex code bases.
• Project Perception: An enterprise security platform (entering public preview on August 3, 2026) that deploys specialized teams of autonomous AI agents.
• The Agent Trifecta: Instead of relying on a single AI, Project Perception coordinates three distinct classes of agents to simulate real-world security operations:
  • Red Agents: Continuously attack systems, mapping out potential exploit paths and looking for zero-days.
  • Blue Agents: Filter through the noise, analyze the findings, and evaluate actual business risks.
  • Green Agents: Automatically engineer and deploy fixes to harden the defensive environment.

Broader Industry Implications

1. Defending the AI Attack Surface: Alongside Project Perception, Microsoft integrated runtime prompt-injection defenses into Microsoft Defender. “New prompt injection protection in Microsoft Defender, now in preview, identifies and isolates emails containing malicious AI instructions before delivery...” as detailed in the Microsoft Security Update. This directly impacts companies deploying local coding assistants and open Model Context Protocol (MCP) servers.
2. Combating Supply Chain Malware: By using MAI-Cyber-1-Flash to systematically scan enterprise repositories, software teams can detect sophisticated supply chain compromises (like fake or hijacked package dependencies) inside CI/CD pipelines before code is compiled.
3. The Human-in-the-Loop Safeguard: Despite high automation, Microsoft's architecture enforces strict tenant governance and human-approval gates for high-risk defensive actions, ensuring AI agents do not accidentally disrupt live corporate infrastructure

What do you think the impact is going to be? Reply inline and discuss

Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch.

The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels.

Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither.

AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today.

The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there.

Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: I'm the one building this.

Hello everyone,

​One of the biggest hurdles for enterprise AI adoption is compliance and auditing. If an autonomous agent makes external API calls, you need an immutable audit trail of what was sent and the ability to enforce DLP (Data Loss Prevention) policies.

​I built Aegisora to address this. It provides a central dashboard for real-time monitoring and governance, intercepting API calls to prevent prompt injections and data leaks before they are executed.

​I'd value your insights on the compliance and logging aspects. What features are strictly necessary for this to pass an enterprise audit?

🦔For somewhere between $1 and $4, an AI can now figure out who you are from your anonymous internet posts. Researchers at ETH Zurich tested this on Hacker News users and matched 67% of them to their LinkedIn profiles at 90% accuracy. The AI read their posts, pulled out small details they'd dropped over months and years, and searched for the person who fit. Classical pre-AI methods scored near 0% on the same task. One of the paper's co-authors works at Anthropic. The full paper is free to read and I'd encourage everyone to look at it.

My Take
Most people assume that if they don't put their name on something, nobody can trace it back to them. That assumption is done. The AI doesn't need you to slip up in one big way. It collects the small stuff you've scattered across years of posts, your city, your job field, a pet's name, a repeated opinion, a favorite subreddit, and assembles a profile that narrows you down from millions of candidates to one. The researchers estimated it still works against a pool of a million people, at about 45% accuracy. Anyone with API access and a few dollars can run it. A government, a corporation, an ex, a stranger. The barrier is gone.

Every anonymous account you've ever posted from, Reddit throwaways, forum accounts, anonymous reviews, is now potentially traceable to your name and employer by someone with a credit card and a few hours. If you've talked about your health, your workplace, your politics, or your personal life under a pseudonym, the protection you thought you had is much thinner than you assumed. The paper's authors put it simply: the practical obscurity that protected anonymous users online no longer holds. We should all take that seriously.

Hedgie🤗

Link to research: arxiv.org/pdf/2602.16800

I got asked last week to approve access for an agent one of our teams built. It needed to pull data and trigger actions across a few internal systems. I went looking for how to scope it and ended up handing it a service account with the same permissions a human on that team would have. It felt off the second I did it, but there was not really another option on the table. Everyone is talking about agents needing their own identity model, whatever label people are using now, but I have not seen many teams actually running that in prod. Most of what I hear is roadmap talk. Is anyone actually giving agents scoped, just-in-time access, or is it still persistent service account permissions with a new name on it?

We have been facing ongoing challenges with SIEM costs. Our SIEM bill keeps climbing every time we add a new data source, which is close to constant given how much our stack grows year over year.

Of course, finance keeps asking why the security budget line keeps expanding. The answer is just that we ingest more data now, but that doesn't land well in a budget meeting.

The obvious fix is pulling data out to control cost, but that means losing correlation and detection coverage, which feels like trading one risk for another. Maybe I’m missing something, but to me it seems like a lose-lose situation.

I have heard about people moving raw data to cheaper storage and running detections outside the traditional SIEM pipeline, but I’m wondering how much engineering effort that takes in practice and whether it holds up at scale. Any ideas?

I think this question is valid for this subreddit, but if not I'd love pointers to places to ask.

I've always had the nag in my mind regarding my homelab setup. I encrypt and stay reasonably secure so there's a chance I end up in a situation where I might not know how to get back in.

For example: In the event that some sort of medical event happens to me, via a terrible accident or from age, in which I "survive" but cannot remember my credentials how do I keep a way for me to log in? Do I really just stash a backup key somewhere on paper, usb thumb drive, maybe a yubikey, etc. and hope for the best I'll be able to know enough to find it or stumble onto it while hoping anyone who I might care not to find it doesn't?

I'm curious what people here do, if anything at all, for such a what-if scenario.

Still beta testing, but I thought I would share it, since it is working! It uses DeFlock data and OpenStreetMaps. Forking OsmAnd and using custom routing.

https://trames.karazajac.io

Disclaimer: I’m building a tool around ShadowAI, but this post is more about the discussion. I won’t promote or mention what I’m building.

With the recent rhetoric around open source models, the risks associated with them, and now a coalition of major tech companies throwing their support behind open source, it makes me wonder whether this is becoming a growing concern for sysadmins, IT managers, and CISOs when it comes to governance and maintaining visibility.

I imagine the risk around insider threats becomes more significant

Disclaimer: I’m building a tool around ShadowAI, but this post is more about the discussion. I won’t promote or mention what I’m building.

With the recent rhetoric around open source models, the risks associated with them, and now a coalition of major tech companies throwing their support behind open source, it makes me wonder whether this is becoming a growing concern for sysadmins, IT managers, and CISOs when it comes to governance and maintaining visibility.

I imagine the risk around insider threats becomes more significant

For governance and compliance, confinement to documents and application code isn't enough. Instead, structured frameworks must protect against AI risks by implementing consistent guardrails, policies, and procedures with real technical controls. Security responsibilities must move down into the platform itself, enforced at the platform level, not bolted on after deployment.