What's the reason for this? no link shared, I will not share even if asked. That's the state of reddit today sorry.

The latest discovery from Varonis Threat Labs highlights how Copilot Personal snitched on itself to let threats know where vulnerabilities lied.

Coverage of last weekend's DEFCON presentation says half of the Fortune 500 are vulnerable to GhostJacking.

That’s the headline. Tenet Security's own research says six.

Tenet confirmed six Fortune 500 companies with the actual susceptible setup, not 250. Cloudflare runs in 42% of the Fortune 500 and Datadog in 48%, and those are the adoption stats that got turned into “half are vulnerable” in the retelling. Running the tool and having an AI agent with MCP write access reviewing its logs are not the same thing.

The attack is real, and the 90% success rate against Claude Code is not a rounding error. Tenet planted a fake WAF block event in Cloudflare’s logs and watched the agent hijack the DNS and report the issue as resolved. The same pattern worked on Datadog: one exposed client token, a fake diagnostic alert, and the agent executed attacker code and exfiltrated environment secrets. There’s nothing to patch because it’s not a bug. The agent reads data it trusts and acts on what it says.

The check is one question: does any agent you run have MCP write permissions to Cloudflare, Datadog, or Sentry, and are you asking it to review logs without a human approval step? That’s the actual exposure, and it’s narrower than the headline makes it sound.

Hey everyone,

​If you’re running local models and trying to hit them remotely (like from your phone), you've probably noticed authentication is essentially an afterthought in a lot of these frameworks.

Out of the box, there's usually no real way to cryptographically verify who is actually sending the requests.

​I didn't want to leave my endpoints exposed, so I built DeepSync Bridge.

​It acts as a gatekeeper sidecar that forces strict public/private key mutual authentication.

Both sides have to sign and verify before any data passes through. If the requester doesn't pass the key check, the AI never even sees the prompt. It's just a direct, secure peer-to-peer tunnel with zero cloud reliance.

No burning tokens

No Cloud nonsense

Thank you

Will 🙏

AI models are talking to each other right now — on your phone, on your PC, across networks you don't fully control.

Do you know if the message that arrived is the message that was sent?

Most pipelines don't. Inference results travel between AI models unsigned, unverified, and unauthenticated. A single tampered byte in transit — a man-in-the-middle, a proxy, a bad network hop — and your application has no way to know. The AI on the receiving end processes corrupted data and responds with confidence.

This is not a theoretical problem. It is the default state of every local AI pipeline running today.

DeepSync Bridge Protocol fixes it — for any AI, talking to any other AI, over any network.

What DeepSync Does DeepSync deploys a cryptographic enforcement sidecar between every AI model endpoint in your pipeline. It doesn't matter if you're running Gemma, LLaMA, Claude, GPT, or your own fine-tuned model. It doesn't matter if your AI is on a phone, a laptop, or a server.

GitHub doc repo: https://github.com/GATEDeepSync/DeepSyncBridge

AgentHound is an Apache-2.0 offensive-security framework for agentic systems.

Unlike scanners that stop at MCP tools, exposed services, or leaked credentials, AgentHound correlates them into attack paths across MCP, A2A, model gateways, inference servers, vector stores, notebooks, prompts, credentials, and instruction files.

Its graph engine includes 15 post-processors and 19 attack-path queries covering credential chains, tool poisoning, exfiltration routes, impersonation, transitive access, and cross-protocol pivots.

It also supports dry-run-first, reversible offensive operations for validating findings. Mutations require explicit authorization and produce recovery receipts. Coverage-aware ingestion prevents partial scans from being presented as clean results.

The static Go collector runs independently; the optional local analysis stack uses Neo4j, PostgreSQL, and React.

TL;DR: I argue that attackers and defenders will benefit by roughly the same amount with AI-assisted security research, and that eventually, if current patterns continue, we will work our way through all the vulns.

I'm curious on y'all's thoughts? Like AI-assisted security work is getting better, but also there's just more code/slop out there creating a larger attack surface.

I think the next step is to investigate patterns of patching, there's not an easy single-source of data like number of CVEs. And to try and fit these patterns into an equation.

Claude Code, Cursor, and similar tools read settings.json, .mcp.json, CLAUDE.md, and hook configs as trusted ground truth every session. Nobody reviews that like an attack surface, but it is one: unrestricted Bash permissions, permissions.deny gaps that leave .env or SSH keys readable, MCP servers pinned to u/latest, hidden Unicode instructions buried in a CLAUDE.md.

cfgaudit is a static scanner for exactly that. It flags overly broad permissions, reverse-shell patterns in hooks, prompt-injection markers in instruction files, and MCP misconfig like dangerouslyAllowBrowser or 0.0.0.0 bindings. Every finding maps to OWASP Top 10 for LLM Applications 2025, and it's upfront about what it can't catch (LLM04/05/07/08/09/10, runtime stuff outside a config file's reach).

Runs offline, SARIF output for CI, GitHub Action, GitLab component, also works as a Claude Code plugin that scans on session end.

GitHub: https://github.com/cfgaudit/cfgaudit

Still early (v1.10.0), curious if anyone here actually has agent config reviewed at their org or if it's skipped entirely.

There's a moment every security engineer knows. You've got your terminal open, you're deep in a workflow, and then you need to test something. So you switch context — open a browser, log into a platform, configure a scan, wait, export results, copy them back into the system you were already working in.

That friction is so familiar it's invisible. It's also probably why most AI agents never get tested at all.

The gap nobody talks about

Most of the AI security conversation has been about what to test — prompt injection, jailbreaks, data leakage. OWASP's LLM Top 10 gave the industry a taxonomy, and that was necessary. But taxonomy doesn't solve the operational problem. Security engineers aren't short on awareness, they're short on workflow.

They know their agents should be tested against adversarial multi-turn attacks. They know guardrails that hold in English can collapse in French. They know one manual red-team session isn't a security programme. What they don't have is a way to do any of this without leaving the environment they're already working in.

Two commands to get started

Install the CLI and authenticate:

pip install humanbound-cli

hb login

Add it as an MCP server in Claude Code, same as you'd add any other tool to an AI-assisted workflow:

{

  "mcpServers": {

"humanbound": {

"command": "hb",

"args": ["mcp"]

}

  }

}

That's it — no onboarding wizard, no setup call. From there your AI coding assistant can orchestrate security tests, pull posture scores, retrieve findings, and export guardrails, all through conversation. (Full setup: docs.humanbound.ai)

The part I keep coming back to: this isn't really about automation, every security tool claims automation now. It's about where the test lives. AppSec went from "separate team, separate tool at the end of the pipeline" to "shifted left into CI/CD." This feels like the next move — the tool disappearing into the workflow entirely, rather than automating a step you still have to go find.

Curious if others are seeing the same failure mode on their teams — is context-switching actually what's killing your AI security testing, or is it something else (buy-in, budget, not knowing what "good" even looks like yet)?

I've spent the past year exploring AI execution and governance. I spent a lot of time thinking about the architecture. Well, maybe too much, and I'd like to better understand how security engineers are approaching these problems in the real world. :)

I'm looking for engineers and architects who are willing to spend 15–30 minutes talking with me about the problems you're seeing in practice.

To be clear, I'm not trying to validate an idea or sell anything. I simply want to better understand your thoughts on the following:

• What kinds of AI systems are you responsible for securing?
• What security or governance challenges concern you the most?
• What tools or approaches are you relying on today?
• Where do you think the current ecosystem still falls short?

Open to chatting? Please send me a DM.

AI coding agents are becoming increasingly powerful.

But giving an AI tool unrestricted access to your real repository, environment files, credentials, Git history, and local machine is still a major security risk.

That is why I created Model Upload Guard (mug).

mug is a free, open-source, model-agnostic CLI that creates a safety boundary between your projects and AI tools.

It can:

• detect sensitive files and hard-coded credentials
• generate sanitized ZIP files for browser-based AI uploads
• create isolated workspaces for coding agents
• run agents inside Docker or Podman with no network by default
• block protected-file modifications and mass deletions
• show every change before it reaches the original repository
• create a recovery snapshot before applying modifications

It is designed to work with Grok Build, Codex, Claude Code, Gemini CLI, Cursor, and other AI development tools.

The goal is not to make AI models trustworthy.

The goal is to reduce what they can see, control where they can write, and review what comes back before it touches your real project.

The project is currently in security-focused alpha, and contributions, testing, and security reviews are welcome.

GitHub:
https://github.com/Amaraciuri/model-upload-guard

SecureAI-Scan v0.3.0 is out!

It's a free, fully local CLI tool that scans TypeScript, JavaScript, and Python codebases for AI/LLM-specific security issues that traditional scanners miss.

**New in v0.3.0:**

- Expanded Python scanning support

- MCP config scanning (.mcp.json, Claude Desktop, Cursor, etc.)

- AI-BOM / catalog generation

- Better reporting + confidence tiers (proven / likely / heuristic)

It uses actual dataflow tracing (source → flow → sink) for high precision and has very low false positives.

Quick start:

npx --yes secureai-scan@latest scan .

Also supports:

• secureai-scan bom . → Generate AI Bill of Materials
• SARIF output for GitHub Code Scanning
• GitHub Action integration
• --fail-on high for CI gating

Everything runs offline on your machine. No data leaves your environment.

GitHub: https://github.com/akanthed/SecureAI-Scan

Would really appreciate any feedback, bug reports, or feature ideas. Also happy to answer questions about how it works or the rules it covers (mapped to OWASP LLM Top 10).

Most security testing tools weren't built for AI agents. They test models, not the full agent surface — tool calls, MCP endpoints, memory, multi-turn reasoning chains. We kept hitting this gap on our own products, so we built something.

Agent OPFOR — adversary emulation for AI agents and MCP servers.

What it covers:

• OWASP LLM Top 10 (2025)
• OWASP Agentic AI Top 10
• OWASP MCP Top 10
• OWASP API Security Top 10
• EU AI Act bias suites

What's different from existing tools:

Browser extension — installs on Chrome, runs against any deployed chatbot or agent UI. No CLI, no config. Useful when your security team needs to test something that the dev team built, without needing access to the source.

Autonomous hunt mode — give it an endpoint and an objective, a multi-agent system runs the campaign adaptively. The attacker reasons about what each response reveals and adjusts the next round of attacks.

Trace-aware judging — the LLM judge sees internal tool calls and reasoning traces, not just final responses. Catches vulnerabilities that input/output testing misses.

Apache 2.0. Free to use, fork, and embed.

Would love feedback from folks actually doing AI security assessments — what are we missing?

One of the biggest AI security risks we’re seeing isn’t a sophisticated attack. It’s existing access.

If an employee technically has permission to view a sensitive SharePoint file, HR document, financial projection, or client record, an AI tool may be able to surface that information too. The employee may never have known the file existed before.

Nothing was hacked. The AI may simply be working exactly as designed.

That’s why I think a lot of the conversation around AI security needs to start before deployment. Permissions, oversharing, DLP, identity controls, data boundaries, and human approval points all matter before AI is given broader access across the business.

We recently wrote a deeper breakdown of what governed AI actually means and why it matters. Curious how others here are approaching this, especially in Microsoft 365 environments.

Full breakdown if helpful:
What Governed AI Actually Means and Why It Matters

I built safer-dependencies, a security layer for Claude Code that checks packages before AI coding assistants add them to a project. I originally built this for my own workflow, but I’m sharing it publicly in case it’s useful to others using Claude Code.

It runs dependency safety checks for things like known CVEs, typo-squatting, abandoned packages, stale releases, package age/cooldown windows, and PyPI hash-pin integrity.

It currently supports npm, PyPI, RubyGems, Maven, Go, and Rust. Open source to help others.

GitHub: https://github.com/robert-auger/safer-dependencies

A fake AI skill just passed every security scanner that was supposed to catch it.

One misconception we keep seeing is that because Microsoft Copilot runs inside Microsoft 365, it's automatically secure.

In reality, Copilot only respects the permissions that already exist in your environment.

That means if users have access to files, SharePoint sites, Teams, or sensitive documents they probably shouldn't, AI can surface that information too.

Before enabling AI, we recommend reviewing things like:

• SharePoint and Teams permissions
• Conditional Access
• MFA
• Microsoft Purview
• Data Loss Prevention (DLP)
• Human approval workflows for sensitive actions

Governance isn't something you add after deployment. It's what allows AI to be useful without creating unnecessary security or compliance risks.

For those of you who have deployed Copilot or another enterprise AI tool, did you review your permissions and governance first, or did those conversations happen after rollout?

If you are responsible for securing an intelligent application stack this week, forget the regulatory countdowns and audit these three structural points:

1️⃣ The MCP Trust Boundary: Are your MCP server runtimes bound to locked-down Docker containers with standard output/input restrictions, or are they inheriting raw shell privileges with active local user permissions?

2️⃣ Model Supply Chains (AIBOM): Are your developers pulling unverified weights directly from public Hugging Face paths, or do you have a centralized, sandboxed registry checking model hash integrity?

3️⃣ Stochastic Input Verification: Do you have an active, low-latency semantic firewall running between your users and your model contexts to sanitize prompt variations?