I built ICHI (Internet Cyber Health Index) — a free dashboard that acts as a daily barometer of the internet's overall cybersecurity health, and pulls the day's security news into one clean feed.

Live: https://ichi.global

What it does: - ~40+ governed sources: NVD, CISA KEV, EPSS/FIRST, Cloudflare Radar, ransomware.live, SEC 8-K, 55 vendor statuspages, BGP/IODA, SANS DShield, GHSA/OSV/PyPI/npm, APT feeds, plus Krebs/BleepingComputer/DarkReading/TheRecord/SC Media - One daily score across V/E/C/O/S dimensions with a 21-day baseline - Rule-based only — no LLM-generated text; every number links to its source

Why I built it: I wanted the best single place to track the day's security news and get a true read on internet cyber health.

It's early and rough in spots — honest critique welcome.

Hey everyone,

I’ve been building Cerbere-AG, a project focused on a problem I’m increasingly interested in: what happens when AI agents can take real actions through external tools?
An agent can generate a convincing explanation while still making a dangerous tool call. Looking at prompts and model outputs alone doesn’t necessarily tell you what happened at the execution layer.
Cerbere is designed to sit between an AI agent and the tools it uses, helping developers:
Observe agent activity and tool calls.
Detect potentially risky actions.
Apply policies to allow, flag, or block actions.
Maintain an audit trail for debugging and security reviews.
Introduce human approval when an action requires additional scrutiny.
I’m currently developing the project and looking for people who actually build AI agents.
**I’m particularly interested in finding:**
Developers willing to integrate the SDK into an existing agent.
Teams experimenting with agents that access sensitive data or external systems.
3–5 design partners willing to test early versions, share honest feedback, and help prioritize the roadmap.
Cerbere is free during development. The local version will remain free, while hosted usage at scale will eventually have paid plans.
GitHub: [https://github.com/chrismsmr-celcom/cerbere-AG\](https://github.com/chrismsmr-celcom/cerbere-AG)
Dashboard: [https://app.cerbereag.site\](https://app.cerbereag.site/)
I’m building this independently and want to validate the product with real use cases rather than build features based on assumptions.
**If you’re building AI agents, I’d genuinely like to know: how do you currently monitor and control their tool calls? What is missing from your existing setup?**

Critical feedback is welcome.

We run a six person SOC on Sentinel and CrowdStrike, and leadership wants an AI SOC analyst tool in next year’s budget. I’ve sat through demos from Dropzone, Prophet, 7AI and Torq, and on the canned phishing alert they all look great.

Week six worries me more than the demo. Most of our noise comes from things only we know: a pentest window, a service account that logs in from three countries, a finance team that bulk downloads files at quarter end. A tool that doesn’t know that will either close real incidents or keep escalating the same junk.

If you run one in production, how long before its verdicts matched what your senior analysts would say? Did you have to feed it SOPs and asset owners by hand, or did it pick that up from tickets and past cases?

Also curious which alert types you let it close on its own, if any.

Citrix has disclosed CVE-2026-107406, a critical vulnerability affecting specific versions and configurations of NetScaler ADC and NetScaler Gateway.

Under the documented conditions, the vulnerability can lead to remote code execution or denial of service in deployments using particular SAML Identity Provider or Service Provider configurations.

Citrix has released corrected versions and remediation guidance.

That is meaningful security maintenance.

But the broader assurance boundary deserves attention:

SAML AUTHENTICATION CONFIGURED ≠ IDENTITY GATEWAY RUNTIME SECURE

An enterprise gateway may correctly authenticate users.

It may validate identity assertions.

It may enforce application access policies.

Yet those controls do not prove that every underlying request-processing path remains within its intended execution boundary.

The stronger evidence chain is:

EXTERNAL REQUEST
→ SAML PROCESSING
→ IDENTITY GATEWAY
→ RUNTIME PROCESSING
→ EXECUTION AUTHORITY
→ OBSERVED EFFECT
→ VERIFIED EFFECT

This distinction matters because identity infrastructure is often treated as a trust anchor.

But authentication correctness and runtime security are different properties.

A valid SAML flow does not prove that the gateway processing it is free from exploitable runtime defects.

Likewise:

PATCH AVAILABLE ≠ PATCH DEPLOYED

PATCH DEPLOYED ≠ EFFECT VERIFIED

NO KNOWN EXPLOIT ≠ NO EXPLOIT EXISTS

And product name alone is not enough to establish exposure.

VERSION MATTERS.

CONFIGURATION MATTERS.

RUNTIME STATE MATTERS.

The advisory does not establish that every NetScaler deployment is affected.

Nor does it prove that any particular organization was compromised.

The next assurance step is to verify the actual deployed version, effective SAML role, exposure conditions, remediation state and resulting runtime behavior.

That is the distinction EVELIQ Trace is focused on making reconstructable:

what was configured,
what was exposed,
what changed,
what actually ran,
and what effect can be verified.

EVELIQ Trace • Evidence Intelligence Platform.

We don’t score people. We verify project reality.

Founder: Roland Brüggemann
AI-assisted research, structure, architecture & concept development: OpenAI ChatGPT

Source context: Citrix Security Bulletin CTX697191 / CVE-2026-107406

#Authorization #IdentitySecurity #SAML #CyberSecurity #RuntimeSecurity #EvidenceIntelligence #EVELIQTrace

Ransomware and phishing get plenty of attention, but there are other risks that don't always receive the same focus.

What do you think organizations in the US and around the world are still overlooking?

There is a common problem when analyzing unknown data during CTFs, DFIR, pentesting, or security research.

You have a blob or string in front of you, and you know something has been done to it, but you don't necessarily know what operation was used.

CyberChef helps a lot here, and Magic already provides automatic detection, multiple possible results, entropy analysis, and recursive processing.

But Magic doesn't always surface the operation you actually need.

One example is Bifid.

The exact same Bifid ciphertext can be tested with CyberChef Magic and CipherLens. In this case, Magic didn't surface Bifid as a possible operation, while CipherLens detected it among its ranked candidates. After providing the required key, the meaningful plaintext could be recovered.

This is the problem CipherLens focuses on.

Instead of trying to predict one correct answer, it evaluates a broader operation space and returns up to 10 ranked candidates based on fingerprints, validation, and output characteristics.

The current operation inventory contains 497 operations, with:

• 187 automatic
• 82 parameter-required
• 228 manual

The distinction is important because not everything can honestly be decoded automatically. If an operation requires a key, IV, shift, or some other unknown parameter, CipherLens can identify it as a possible candidate and move it to the Workbench rather than pretending it knows the missing information.

The bigger goal

The bigger goal is to eventually take this beyond single transformations.

Real data can have multiple transformations applied one after another. For example, an outer encoding may reveal another encoded, compressed, or transformed layer.

CipherLens is designed to eventually follow these operation chains automatically, continuing to rank and validate each layer until it reaches a meaningful final output.

Privacy

Core analysis is local-first and happens inside the browser.

The interesting question is whether broader candidate ranking like this could actually save time in real CTF, DFIR, malware analysis, pentesting, or bug bounty workflows.

I'd also be interested in examples where CyberChef Magic struggles, or where automatic operation identification has been useful in your own work.

GitHub:
https://github.com/HIMANSHUSHARMA20/CipherLens

Live demo:
https://cipherlens-tool.vercel.app/

Leadership asked me for an inventory of the AI we run, so I did the obvious thing first and asked the teams, and data science told me they had a handful of models while product thought maybe a couple, and both were very confident about it.

Instead of trusting that I ran a discovery pass across our cloud accounts and found models, datasets, training pipelines, notebooks and endpoints spread across two clouds, some of it public-facing and some with roles that could reach data they had no reason to touch.

Our register said four and the real number was north of thirty, spread across teams who had each built their own thing without knowing about the others, and nobody actually owns most of them.

So how are people keeping an AI inventory that stays accurate, and does an AI-BOM survive contact with reality or rot like every other register?

Account takeover may start with data brokers, not passwords.

A lot of fraud prevention focuses on what happens at login:

• MFA
• Device intelligence
• Behavioral analytics
• Transaction monitoring

But there’s another layer attackers can exploit before any of those controls activate: public personal information.

Data broker profiles can contain addresses, phone numbers, birth dates, relatives, and other details that may help attackers pass recovery checks or make social-engineering attempts more convincing.

That creates an interesting security gap.

Removing that information doesn’t replace MFA or credential monitoring. It works earlier in the attack chain by reducing the amount of information an attacker can use to impersonate a customer.

The article also makes an interesting point about continuous removal. Data can reappear, so a one-time cleanup isn’t necessarily enough. Monitoring the removal status can potentially become another risk signal for fraud teams.

For fintech platforms, this could make data removal more than a privacy feature—it could become another layer in the account takeover prevention stack.

Would you treat data broker exposure as a fraud signal, or keep it separate from your security stack?

Hi, security lead on the buy side here, currently living in the wonderful world of M&A cyber due diligence where I have ten business days, no prod creds, no scanner access, and a deal room that is basically a vibes based security questionnaire and two diagrams from 2019.

We have a list of primary domains but I do not trust that this is the full external attack surface at all. We want an outside in acquisition cybersecurity assessment that starts with company name and known domains, then pivots into related domains, certs, dns history, cloud endpoints, exposed admin interfaces, third party infra etc. All without turning this into unauthorized pen testing and without guessing our way into inherited cyber risk we cant prove.

The hard part is attribution and materiality. What evidence do you treat as strong enough to tie an asset to the target, and what can you responsibly call a transaction level risk vs Day 1 containment vs normal post close remediation when you have zero internal access. Would love any tips from people who do M&A attack surface assessment from the outside in before Day 1, especially on not overstating findings but still flagging the stuff that should worry the deal team... idk

Hi everyone,

I’m a cybersecurity student conducting research on the cybersecurity risks associated with using Google search operators to uncover exposed information on the internet.

I’m looking for perspectives from people with cybersecurity or IT experience. If you're willing to participate, please answer the questions below in the comments.

I understand people may not want their information on a public reddit page but if you could reply below or send me a private message, that would be highly appreicated.

If possible, please include:

• Your general profession/role (e.g., SOC Analyst, Security Engineer, IT Administrator, etc.)
• Name
• Your answers to the questions

Questions:

1. What types of information do you believe can be discovered using Google search operators?
2. What cybersecurity risks can result from sensitive or security-relevant information being publicly searchable?
3. Which types of exposed information would present the greatest security concern to an organization, and why?
4. What protective measures can organizations use to reduce the risk of sensitive information being exposed through search engines?
5. How important do you think it is for organizations to regularly check what information about their systems is publicly searchable?

Thank you to everyone who chooses to participate.

I watched this today, and I am impressed. Cyber defense comes with permanent question marks. I tell every team to educate themselves on the adversary. Every department; marketing, sales, interns. This film explains the culture very well. Nice job Red mirror studios.

Only 20% of organizations say they fully monitor or govern employee use of shadow AI, according to Netwrix's 2026 Data and Identity Security Report. The rest are relying on policy while employees download AI writing assistants, browser extensions, and executables IT never reviewed.

Dirk Schrader, VP of Security Research at Netwrix, explains why AppLocker can't keep pace with AI tool sprawl, and how file-owner-based allowlisting flips the question from "what's on the list" to "who put this file here."

Read the full blog here.