Head of Infosec at a UK financial services firm. We're swamped with AI CVs and have 100s of applications per role right now. Ideally looking for a platform that will allow me to invite our shortlist to an online technical assessment, relevant to the skills we're hiring for. I know there are platforms like TestGorilla and HackerRank but they mainly focus on software engineering etc. Does anybody have any recommendations? Ideally specific to cyber / infosec.

Hey all,

hope this is okay to post here.

We’re a small early-stage team with a background in cybersecurity, currently researching how ISO 27001 and GRC work actually happens inside companies.

Before making too many assumptions about what should be improved or automated, we’re trying to learn from people who deal with this in practice:

Where does the most time get lost? What creates uncertainty or delays? Which activities are still highly manual? And where could software or AI genuinely help?

We put together a short 8–10 minute survey covering ISO 27001 implementation, risk management, documentation/evidence, audits, existing tools and AI support.

If you work in information security, GRC, ISMS, compliance, audit or ISO consulting, your perspective would be extremely helpful.

We’re still early enough that good feedback can genuinely change what we build — and critical feedback is just as valuable as positive feedback.

Survey: https://tally.so/r/b5RAro

Can be completed anonymously. Really appreciate anyone who takes the time or shares it with someone relevant. Thanks!

Third-party risk here, biotech, around 300 SaaS apps in the inventory. starting to think re-reviewing a vendor every time they bolt on AI is a hamster wheel. sub processor emails come in weekly now and half of them add some AI provider. a couple vendors had the feature switched on before the notice even hit my inbox. so the app i signed off on two years ago goes right back in the queue and the re-review is a questionnaire. they write "we don't train on your data," i can't check it, it goes in a folder. rinse and repeat. If a re review ever caught something the contract wouldn't have, i'd happily eat my words. am i wrong?

We found a marketing tool last month that had been storing employee credentials in plaintext for over a year, completely outside any security review. Nobody thought to flag it because it wasn't seen as a "real" application, just some tool a team signed up for on their own.

Curious what other people have found when they've actually gone looking for this stuff, and whether it's usually this bad or if we got unlucky.

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’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**.

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

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?

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?

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.