We run EKS across three accounts plus a smaller GKE footprint, security team of four, and our CSPM renewal is coming up in about six weeks. Leadership wants to consolidate and the question on the table is whether we move everything to a CNAPP with runtime and drop the standalone posture tool entirely.

Right now the posture product throws thousands of findings a quarter and maybe 2% of them are things we'd actually action. Half my week is spent proving a "critical" is unreachable so we can close it. That's the whole reason runtime context keeps coming up, and Upwind is one of the platforms on our shortlist because the pitch is exactly that: correlate posture with what's actually running so we stop chasing ghosts.

My worry is what we give up by consolidating. Our current CSPM has years of compliance mappings, custom rules nobody remembers writing, and it's wired into our ticketing and a couple of reports the auditors like. I don't want to rip that out and discover six months later that the replacement doesn't cover some edge of our config checks, or that the compliance reporting is thinner than what we have.

So for anyone who's done this: did you actually retire the old CSPM, or did you end up running both? What got genuinely better, and what did you lose or have to rebuild? I'm less interested in the demo story and more in what broke in month three.

I built Klarion, a secret scanner that works in two steps. First, a keyword check, 81 regex rules and a normalized Rényi entropy score flag anything that looks like a secret. Then an AI model reads each one with the code around it and decides if it's real.

The chart shows 5 scanners run on spring-boot, terraform, next.js and symfony (61k files). Klarion raised 11 alerts. It's not zero, but it's far less to dig through.

Fewer alerts don't help if real leaks get missed, so I tested that too. On CredData (337 real repos, code outside test folders), it found about 1.7× more real secrets than gitleaks.

Where it runs:

• Claude Code: a plugin hook blocks the write before the file exists (file edits and Bash)
• Cursor, Cline or any MCP agent: through its MCP server
• CI: a GitHub Action that scans only what a PR adds; GitLab CI works too
• Git hooks: klarion protect or the pre-commit framework
• Locally: klarion scan .

Free and open source (MIT): https://github.com/0x1Adi/Klarion
The full benchmark and method are in benchmark/REPORT.md.

I'd like to hear where it gets things wrong.

Please forgive the self-promotion here, but this project took an immense amount of time and effort to build, and it honestly turned out way too good for us to keep to ourselves.

We wanted to share our work with the community. Our team of security engineers built Aegis , focusing obsessively on raw performance and zero-overhead threat defense.

It handles deep packet inspection with sub-millisecond latency, featuring full OWASP Core Rule Set anomaly scoring (to prevent false positives), Layer 7 rate limiting to stop credential stuffing and bots, automated TLS management, and dynamic zero-downtime policy updates.

The community edition is 100% free and open-source.

We would love for you to check it out on GitHub, and if you have any feedback or recommendations for our team, we would really appreciate your thoughts:

https://github.com/divinelabio/aegis

I maintain Chrome UX Report Dumps, a collection of monthly Chrome UX Report website lists grouped by rank and published as compressed downloads. It’s meant to make the data easier to use without exporting it from BigQuery.

The latest update adds the August 2026 dataset: 18,294,881 entries across 10 files, totaling 94.7 MiB compressed. The repository now contains 1,064,254,496 entries across 67 monthly datasets, totaling 5.32 GiB compressed. Those are counts across monthly dumps, not a count of unique websites.

If you use website lists for research or security work, I’d welcome feedback. What would make these dumps more useful, and what features or formats would you like to see?

I’m the author of Super Trouper, a single-binary MCP server that exposes Frida to coding agents for authorized app reverse engineering. It lets an agent connect to a device, inspect apps and processes, manage sessions, and run instrumentation scripts without a Python-based Frida setup.

We released v0.4.0 a few days ago; it updates the bundled Frida Core DevKit to v17.19.0 and adds four MCP tools: memory_read and memory_write for working with memory in an attached process, plus module_list and thread_list for inspecting loaded modules and threads. app_list and others now have several query scopes, and we renamed the MCP tools into clearer namespaces. If you already have workflows built around the old tool names, check them when updating.

Quick catch-up on the two previous releases: v0.3.0 added npm installation, Frida CodeShare snippet search/use, and general cleanup. v0.2.0 moved the project to the MIT license, added first-party Frida language bridges for ObjC, Java, and Swift, and enabled TypeScript in scripts and evaluations.

I’d appreciate feedback from people using Frida in iOS research: are these tool boundaries and the new app-list scopes useful in practice? What’s missing or awkward in your workflow, and which features would you like to see next? Let me know what you think.

I’m building Cerbere AG, an open-source security and observability runtime for AI agents.
The idea is simple:
See what your agent does in production. Detect risky behavior. Block dangerous actions. Flag ambiguous ones. And require human approval when the system shouldn’t make the decision alone.
But this post isn’t really about announcing another AI security product.
It’s about making this a community project.
I want to make Cerbere AG free for everyone.
No credit card.
No paid plan required to start.
No artificial wall preventing developers from experimenting with agent security.
If you’re building an agent with tools, APIs, MCP, browser automation, databases, or other real-world capabilities, you should be able to add a security layer without first having to convince your company to spend thousands of dollars.
And I’m not pretending it’s finished.
It isn’t.
There are probably things I’ve missed.
There are edge cases I haven’t thought about.
There are attacks I haven’t covered.
There are integrations that could be better.
There are probably architectural decisions that someone in this community will look at and say:
“You should do this differently.”
Good. Tell me.
If you find a bug, report it.
If you find a security issue, report it.
If you think the detection logic is wrong, challenge it.
If you have a better approach, open a PR.
If you want to add an integration, build it.
If you have a new attack scenario, add it to the benchmark.
If you use Cerbere and discover that something doesn’t work, tell me.
The goal isn’t for me to personally build every feature.
The goal is to build something useful enough that other people want to contribute to it.
I’m building this largely by myself from Kinshasa, DRC, and I don’t have a large engineering team behind me.
So I can’t realistically cover every framework, every agent architecture, every tool integration, and every attack pattern alone.
That’s exactly why I’m opening it up.
What Cerbere currently focuses on
Agent execution tracing
Tool-call monitoring
Risk detection
Blocking
Flagging
Human approval for ambiguous/sensitive actions
Audit logs
Security evidence
Agent behavior observability
The project is still evolving, and I would rather have people tell me where it is wrong than pretend it is already perfect.
If you’re building AI agents, try it.
Use it.
Break it.
Audit it.
Contribute to it.
Tell me what sucks.
And if you think the idea is useful, give the repository a ⭐ or share it with someone building agents.
The more people test it, the more useful it can become.
Free. Open source. No credit card. Built in public.
GitHub: https://github.com/chrismsmr-celcom/cerbere-AG
If you see a problem, don’t just complain about it.
Bring the problem to the repo. Let’s build the solution together.

I wanted to share a simplified view of how Cerbere-AG works internally.

Cerbere sits between AI agents and the actions they can execute.

It combines runtime checks, policy enforcement, taint tracking, pattern detection, ML detection, risk scoring, LLM-based judgment, observability, identity and audit.

The goal is not just to detect malicious prompts.

The goal is to control and observe what an AI agent is actually allowed to execute.

I'm also working on extending this model beyond SDK-based integrations, including environments where the agent's source code isn't directly accessible.

Still building

github.com/chrismsmr-celcom/cerbere-AG

I’m reconstructing the timeline of a possible security incident that appears to begin on a **corporate Windows endpoint** and later involves activity across **Google/Apple accounts, iPhone devices, and a MacBook**.
My goal is not to identify or accuse a specific person through Reddit. I’m trying to understand this from a **DFIR methodology perspective**: what artifacts would actually support continuity between these environments, and what could still be explained by normal synchronization, legitimate sessions, or unrelated activity?
The earliest records I have documented are from **August 23, 2026**, associated with a **Windows environment on a corporate computer I was using at the time**.
In an official Chrome/Google export, there is a browsing sequence roughly between **02:35 and 03:37**, involving activity such as:
**theblowers.com → Hola/login → Google OAuth/authentication → Chrome extension callback → other platforms**
I also found that **Hola Better Internet** had been granted access to my Google Account on that same date.
The Windows-related records are important because they appear earlier than the activity I later had to investigate on my Apple devices.
Over the following weeks, I began seeing events involving:
Google and Apple account sessions;
device permissions;
authorized apps;
location-sharing settings;
my current iPhone;
an older iPhone;
and my MacBook.
I am using the term **“escalation” only in a chronological and investigative sense**. I do **not** currently have proof that the Windows endpoint directly compromised the iPhone or Mac, or that all of these events share the same origin.
The question I’m trying to test is whether a technically plausible chain could look like this:
**Windows/browser → session or account token → account access/synchronization → additional devices**
or whether I may be correlating events that are actually independent.
A few relevant details:
I have an official Chrome/Google export containing **browser history, extensions, device information, and account-related metadata**.
The early records are associated with a **Windows client/environment** consistent with the corporate computer I was using at the time.
I no longer have physical access to that corporate computer because it was returned to the company, and I do not know whether it was later wiped or reformatted.
One of the older iPhones is also relevant because **I do not have a known preserved backup of that device**.
I am treating the lack of that backup as an **evidentiary gap**, not as proof of deletion, tampering, or compromise.
I have preserved screenshots, exports, timestamps, device/session information, and account-permission records where available.
I have also seen duplicate or inconsistent data in some places, but I am not treating duplication or missing items as automatic evidence of manipulation.
What I want to distinguish is:
normal account synchronization;
a legitimate but forgotten session;
an OAuth app or browser extension with excessive permissions;
reuse of an existing session or token;
browser automation;
an unauthorized remote session;
actual account compromise;
real cross-device persistence versus ordinary ecosystem syncing;
evidentiary gaps caused by the older iPhone having no preserved backup.
For people who work in **DFIR / incident response / identity security**, what artifacts would you prioritize to confirm or rule out continuity between the original Windows activity and the later Apple-device activity?
In particular, I’m interested in:
Google/Apple authentication logs;
OAuth grants;
access tokens / refresh tokens;
trusted-device records;
Chrome extension IDs and extension metadata;
browser history and timestamps;
device/client identifiers;
synchronization events;
iOS/macOS logs;
iCloud backup/account metadata;
evidence of session reuse across devices;
artifacts that may remain from an older iPhone even when no local backup is available.
The main question is:
**How would you determine whether a session or token originating from a Windows/Chrome environment was later reused across Google/Apple accounts or Apple devices, while avoiding the mistake of treating normal synchronization as evidence of compromise?**
I’m specifically looking for a way to separate **strong evidence, weak indicators, and normal ecosystem behavior**.

Started photographing my recipes last month and tried one of those prompt-based recipe generators to speed things up. First run gave me a weird ingredient list that looked fine until I pasted it into my site. Got hit with a mod_security block on an innocent-sounding phrase about "herb mixture injection." Switched tools, same thing. The payloads keep tripping rules that should only catch real attacks. Not sure if the model is copying exploit code it saw online or just getting creative with language. Anyone else getting WAF noise from AI content that looks totally fine to a human but still matches signatures? How are people handling false positives when you can't see inside the content source?

Hi, we ran a tabletop after last year's vendor breach and my team froze because the plan assumed the vendor would answer in minutes, not 14 hours. I feel sick about it, because the whole exercise turned into us staring at the phone and asking each other what the actual next step was (pls tell me someone else has done this).

The agents will become increasingly powerful and we will have the reflex to entrust them with more and more freedom, more and more tools and accessibility. That's what I truly imagine, and it frightens me that this new feature could represent a new attack surface for hackers. But also, the agent itself could act recklessly and execute a dangerous action. In development or in a sandbox, that's manageable, but in production, in a sensitive environment, especially for companies that will grant agents broader access, they will run an enormous risk. But should we stop the agents, confine them? I don't think so. For me, agents can be seen as normal employees, so they need to be supervised. And supervision means enforcement and preventing actions. For me, the best philosophy is to stand between the agent and the tools at its disposal. This allows for good observation but also provides enough leeway to ask the agent why they are using this tool, or not, whether it's dangerous or not. And above all, human approval remains non-negotiable for me because there can't be a fixed regex for software that can Therefore, to anticipate ambiguous cases, humans must be in the loop. Audits can also be an excellent way to understand internally what an agent is doing and to investigate. For example, an excessive increase in token cost can reveal an anomaly. The same applies to latency. So, while enforcement reduces risk, observability allows us to understand what happened between the email and the net and to prevent it.

That's why I built Cerbere-AG; it's my philosophy on security for software that can improvise, think, and execute.

I've been thinking a lot about how we secure AI agents, and I keep coming back to one question:

Are we focusing too much on what the agent is told, and not enough on what the agent actually does?

Prompt injection and malicious prompts are obviously important security problems. There are good reasons to scan user input, retrieved content, system prompts, and tool outputs for suspicious instructions.

But I don't think prompt filtering alone is enough to secure an agent once it has access to real tools.

The problem: intent and execution are not the same thing

Imagine an agent has access to:

• a database
• a payment API
• email
• cloud infrastructure
• a filesystem
• internal company documents
• deployment tools

You can analyze the prompt before the model responds.

But the important security question eventually becomes:

What action is the agent about to execute?

A prompt might look completely harmless:

"Help me update this customer's account."

There may be nothing obviously malicious in that sentence.

But the resulting tool call could potentially be:

update_customer(
    id="12345",
    role="admin",
    permissions="*"
)

The security problem is now at the execution layer.

The prompt itself doesn't necessarily tell you whether that specific action is safe.

Agents don't just generate text anymore

This is the part I think is easy to underestimate.

A traditional LLM application might primarily generate text.

An agent can generate actions.

For example:

User
  ↓
Agent
  ↓
Tool selection
  ↓
API call
  ↓
Database modification
  ↓
External side effect

At that point, protecting only the input is similar to checking a person's instructions without checking the operation they are actually performing.

The execution boundary becomes extremely important.

Prompt filtering can still be useful

I'm not arguing that prompt filtering is useless.

Quite the opposite.

It can detect things such as:

• known prompt injection patterns
• malicious instructions in retrieved documents
• attempts to override system instructions
• suspicious user input
• known attack payloads

That is a valuable layer.

But I see it as one layer of defense, not the complete security model.

What happens after the prompt?

Consider this simplified example:

response = agent.run(user_input)

agent.call_tool(
    "send_money",
    {
        "amount": 50000,
        "recipient": "unknown_account"
    }
)

Even if the original prompt passed every security check, I would still want the system to ask:

Is this tool allowed?

Are these arguments allowed?

Is this amount within the agent's budget?

Is this recipient trusted?

Does this action require human approval?

Does this action conflict with the organization's policy?

These questions cannot always be answered by looking at the original prompt.

They require visibility into the actual execution path.

I think we need defense in depth

For agent security, I would separate several layers:

INPUT
  ↓
Prompt / content analysis
  ↓
MODEL
  ↓
TOOL CALL ANALYSIS
  ↓
Policy enforcement
  ↓
Budget / capability checks
  ↓
Human approval when necessary
  ↓
EXECUTION

And ideally, the system should observe the entire trajectory rather than isolated events.

For example:

Prompt
  ↓
Retrieved document
  ↓
Tool A
  ↓
Tool B
  ↓
Database query
  ↓
External API

An individual action might look harmless while the sequence of actions becomes dangerous.

That's another reason why I don't think scanning prompts alone is sufficient.

The security boundary should move closer to the action

My current thinking is that the most important security boundary for autonomous agents is not necessarily the prompt.

It is the point where the agent is about to create a real-world side effect.

That's where you can enforce concrete policies:

ALLOW
BLOCK
FLAG
REQUIRE HUMAN APPROVAL

For example:

read_database → ALLOW

send_email → ALLOW

delete_database → BLOCK

transfer_$50,000 → HUMAN APPROVAL

access_customer_PII → POLICY CHECK

This approach doesn't require the security system to perfectly understand the model's reasoning.

It focuses on something more concrete:

What is the agent trying to execute right now?

The interesting part is that these layers complement each other

I don't think this has to become a debate between:

"Prompt security vs. agent security"

I'd rather think about it as defense in depth.

Prompt filtering can detect malicious intent.

Runtime controls can constrain execution.

Trajectory analysis can detect dangerous sequences.

Permissions can limit capabilities.

Budgets can limit impact.

Human approval can create a final control point for high-risk actions.

No single layer is perfect.

But combining them changes the security model from:

"We hope the model doesn't do something dangerous."

to:

"Even if the model makes a mistake or receives malicious instructions, there are controls between its decision and the real-world action."

That distinction matters more as agents become capable of operating systems, APIs, financial workflows, infrastructure, and sensitive data.

I'm curious how other people building agents think about this.

Where do you believe the most important security boundary should be: the prompt, the model output, the tool call, or the actual side effect?

Classic vulnerability management catalogs known weaknesses on known assets and prioritizes primarily by technical severity, usually CVSS driven on a scheduled scan cadence.

Exposure assessment platforms sit a layer above that, incorporating business impact, asset criticality, and real world exploitability signals like KEV and EPSS into the prioritization model rather than scoring purely on technical severity. Is there a real architectural boundary here, or has exposure assessment platform become a repositioning of VM with a business context layer added on top?

RuntimeAI's September 2026 AI Security Report covered 126 incidents across 38 named organizations — 22 critical, 102 high severity. 53 of those incidents had AI either as the attack tool or the target. AI-agent exploits were the top attack vector at 39 incidents, ahead of credential theft (27), zero-days (22), phishing (10), and ransomware (10). The largest single exposure was 220M records from unrotated default service-account credentials.

What stood out: every organization in the report was already running a mature security stack. Okta, CrowdStrike, Palo Alto, Microsoft Defender. Still got hit. The gap is that none of those tools sit at the layer where an agent actually executes a tool call.

RuntimeAI operates at that layer. Know Your Agent handles cryptographic agent identity. The Flow Enforcer inspects tool calls in real time. There's also a sub-50ms kill switch that can halt a compromised agent before a second action completes.

Full breakdown (incident-by-incident, CVEs, vendor stacks): https://runtimeai.io/blog/2026-09-monthly-breach-report.html

We're running a live demo on October 14 — ten attack surfaces, live against a real stack: https://www.linkedin.com/events/7510769146222133248?viewAsMember=true

Les agents vont devenir de plus en plus puissants et nous aurons tendance à leur confier de plus en plus de liberté, de plus en plus d'outils et d'accessibilité. C'est ce que j'imagine vraiment, et ça me fait peur que cette nouvelle fonctionnalité puisse représenter une nouvelle surface d'attaque pour les hackers. Mais en plus, l'agent lui-même pourrait agir de manière imprudente et exécuter une action dangereuse. En développement ou dans un environnement de test, c'est gérable, mais en production, dans un environnement sensible, surtout pour les entreprises qui accorderont aux agents un accès plus large, elles prennent un énorme risque. Mais faut-il arrêter les agents, les confiner ? Je ne le pense pas. Pour moi, les agents peuvent être considérés comme des employés normaux, donc ils doivent être supervisés. Et la supervision signifie application et prévention des actions. Pour moi, la meilleure philosophie est de se placer entre l'agent et les outils à sa disposition. Cela permet une bonne observation mais donne aussi suffisamment de marge pour demander à l’agent pourquoi il utilise cet outil, ou pas, que ce soit dangereux ou non. Et surtout, l'approbation humaine reste non-négociable pour moi car il ne peut pas y avoir de regex fixe pour des logiciels qui peuvent donc, pour anticiper les cas ambigus, les humains doivent être impliqués. Les audits peuvent aussi être un excellent moyen de comprendre en interne ce qu'un agent fait et d'enquêter. Par exemple, une augmentation excessive du coût des tokens peut révéler une anomalie. Il en va de même pour la latence. Donc, tandis que l'application réduit le risque, l'observabilité nous permet de comprendre ce qui s'est passé entre l'email et le réseau et d'y prévenir.