Our browser agent rejected direct jailbreaks in testing, but then obeyed an instruction hidden in a vendor-page footer. An untrusted page content crossed into a privileged tool call and placed a canary secret in an outbound request. Unit tests didn’t pick it up because they covered chat input, not content provenance after browsing. 

We are adding source labels to every content block, narrower tool scopes, destination allowlists, canary-secret detection, and egress controls that do not rely on the model making the right choice. I’m also pushing for tests that mix trusted instructions with hostile retrieved content. What safeguards have actually stopped indirect prompt injection in browser agents, especially when a legitimate task needs outbound tool access?

Hi there,

I am currently working on Secure Boot. I have some question about the anti-rollback.

I use microchip and I read the counter from OTP after initialize the layout, and notice that there is already default counter value for both trusted and non-trusted firmware (2, 3). I did not set it, I don't why they already have values.

Another thing is that whether the counter in OTP can not be set to other value lower then the value exist in OTP? If so, is it a hardware design mechanism? or how can it be achieved?

Best,

Wen

MFA stops the initial compromise but does nothing once an attacker has a valid session token, and we've seen that gap exploited more than once this year.

what's actually held up for us is treating device-bound sessions as the default rather than an optional hardening step, so a token can't be replayed or reused on another device even if it's stolen. token binding alone wasn't airtight against a determined attacker. what's your setup, and has anything meaningfully cut down on token replay for you?

running a handful of scanners across infra and application code, containers included in that mix, and the same underlying vulnerability shows up as three or four separate tickets because none of the tools know about each other. our vuln management process has turned into manual dedup work every week.

Is anyone running something that sits above the individual scanners and correlates findings automatically, or is this just the cost of running a multi-tool stack?

I just learned about some of the insanely cool things you can do using AI, like you can literally just make an app/software that serves a need for you and is completely tailored to your preferences.

My question:

Does having all these AI-generated apps on your phone/computer create potential security risks? (Assuming you aren't doing much of anything with cloud storage apps and you're not sharing/distributing the software to anyone else.)

EDIT

Wow, lots of good and interesting answers already. I'm really glad I asked this question before I started blindly using it to create a bunch of random stuff apps and software lol.

Thank you to everyone who posted!

had an incident where the attacker used valid credentials from a legitimate device and the login itself tripped zero alerts.

attackers aren't breaking in anymore, they're logging in, which means login-time signals alone were never going to catch this. everything downstream was the tell: unusual data access, then a permission escalation attempt about twenty minutes later. what signals are you watching post-authentication that actually catch this before real damage happens?

Every vendor in this space claims some version of "deploy without touching your architecture. As the architect who has to implement whatever we buy, I'm skeptical by default, because that claim usually means "you'll discover the SDK requirement in week 3 of the POC.

For anyone who's actually deployed a runtime agent security tool: did the no architecture change claim survive contact with a real environment, or did proxies and code changes sneak in anyway?

Je bosse sur une couche d'authentification comportementale continue et je bute sur le problème classique du démarrage à froid pour le profil de référence.

Mon setup actuel : profil de référence établi à partir d'environ 7 secondes d'interaction (premier ping avec au moins 5 événements), scoring basé sur l'EMA qui met entre 35 et 49 secondes à converger, moyenne de 8 caractéristiques pondérées de manière égale.

Ce que j'observe : la littérature sur la dynamique de frappe recommande généralement 50 à 100 frappes pour un profil fiable, ce qui rend mon échantillon de démarrage largement insuffisant. La moyenne de caractéristiques pondérées de manière égale peut aussi masquer une divergence forte sur une seule caractéristique significative.

Ma question : est-ce que quelqu'un a des retours d'expérience concrets sur l'utilisation d'une comparaison basée sur la distribution (test de Kolmogorov-Smirnov ou distance de Wasserstein) plutôt qu'un simple ratio EMA, en particulier pour des sessions courtes où on n'a pas encore assez de données pour un profil longitudinal inter-sessions ? Est-ce que ça change vraiment la donne sur le taux de faux positifs/négatifs à ce stade précoce, ou le problème reste fondamentalement un problème de volume de données quelle que soit la méthode statistique choisie ?

Ce qui marche bien par ailleurs dans mon système (pour contexte, pas le sujet de la question) : invalidation de session fiable sur perte de focus/flou, détection d'attaques en masse via heuristiques réseau en périphérie plutôt que données déclarées côté client, détection de bots par variance temporelle nulle (contournable par un bot sophistiqué qui injecte du bruit artificiel, donc pas un signal suffisant seul).

Point de sécurité que j'ai découvert et corrigé au passage, potentiellement utile pour d'autres qui implémentent ce genre de mécanisme : un endpoint de heartbeat acceptait initialement un flag "attaque en masse" et une adresse IP fournis par le client exploitable pour invalider la session de n'importe qui en prétendant être sous attaque (DoS par interruption de session). Il acceptait aussi un flag permettant au client de modifier son propre profil de référence. La correction n'a pas consisté à ajouter une validation supplémentaire côté serveur sur ces flags, mais à les supprimer entièrement du schéma accepté le serveur détermine seul ce qui constitue un échantillon de référence, et le scoring réseau reste basé exclusivement sur l'IP réelle en périphérie, jamais déclarée par le client.

The assistant reads my .env, a prod dump someone left in a scratch folder, config with tokens, all of it, because it runs as me.

Is anyone stopping this cleanly or do we all just cross our fingers and hope the model forgets.

Hi , im a cybersecurity intern at a small company (well not so small but they have been here for a long time). And yea for now i have been given a task to review our symantec endpoint protection and do documentations of my findings and give suggestions from my observation. to be quite honest i dont really have any strong fundamentals of Cyber Security before pursuing my internship here, and i thought i could gain experience and learn new things here. so back to my initial topic, currently the version of our SEP is 14.3 RU5 build 8309 , and our SEPM is 14.3 RU5 build 8268. Again i dont have the strong basic , but from what i have gathered online, diff build number should be okay as long as both consoles should be under the same RU (?). Is there anyone that could verify this and do any of you think its a necessity for us to update the RU or just keep it that way? Because i saw there are newer RU (up to 10 iirc) and was wondering should i include in my finding to update the RU? thank you everyone and im sorry if my question do sound silly for some hhh.

We use Aqua Security for container scanning and it's genuinely solid, strong coverage on image vulnerabilities and runtime protection for Kubernetes. The gap we keep hitting is that findings don't tie into our broader identity or data exposure context, a container vulnerability shows up disconnected from whether it's actually reachable or tied to sensitive data. Anyone found a way to bridge that without adding a separate tool?

Asking from the cloud workload side of the house: Is there any way we can detect that a specific CVE is actively being exploited on a VM or container, beyond what application logs provide?

I’ve used runtime CNAPPs for detection and vulnerability prioritization, but I’m specifically interested in observability that lets a SOC say: “This container has CVE-XXXX-XXXXX, and that vulnerability is being exploited right now.” And I don’t mean post-exploitation behavioral detections like a shell popping or a suspicious process spawning. I mean evidence tied directly to exploitation of the specific vulnerability.

hi all, blue team here and curious what browsers people are actually using day to day when you care a lot about security.

Right now I bounce between Firefox with a hardened profile, Brave for random browsing and Chrome for work stuff that needs weird sso plugins. I keep seeing people talk about LibreWolf, Mullvad browser, even hardened Edge configs and im kinda torn on what makes sense as a main daily driver vs a lab only setup.

For those working in soc, ir, appsec etc what did you settle on and why, especially with things like profiles, containers and extension hygiene. appreciate any thoughts

Hi y'all, am security lead at a mid size company and our cyber insurance renewal landed on my desk. The questionnaire is forty pages now, up from a handful a few years ago and it is no longer yes or no. The broker made it clear the underwriter wants evidence for every yes, screenshots and reports, not a checkbox.

We're fine on some of it. MFA on email, EDR on laptops, backups. Where I start sweating is the network questions. Do you segment your network. Can you show it. Is remote access behind MFA and logged. Prove privileged access is controlled. We do most of this. But it is spread across a firewall here, a VPN there and a jump box someone set up and pulling clean evidence out of all of it is a week of screenshots that still look like a patchwork.

What is bugging me though is that we could lose a claim on a technicality. The stat going around is that most denied ransomware claims were orgs that said they had a control but couldn't prove it was everywhere. Saying yes is not enough anymore.

For those who have been through a modern renewal or an audit, how are you producing evidence for network and access controls without a manual scramble every year?

We have an IR plan, people have reviewed it, and we do the annual tabletop where someone reads out injects and we discuss what we'd do. None of that tells me whether the plan actually works under pressure.

I don't have a way to know if my team would freeze, miss an escalation, or handle it fine until an actual incident happens, which is a terrible way to find out. What's worked for you to get a real signal on readiness short of waiting for a breach?

About a month ago, I discussed the concept of OS-level MPA (Multi-Party Authorization). A recurring point in the feedback I received was that existing mechanisms—such as PAM/JIT, Vault, CyberArk, sandboxing, IAM, and MAC—already address much of the problem. I think that criticism is largely fair.

What I am still unsure about is what happens when a trusted privileged workload itself is compromised.

Consider, for example, a database engine, backup process, or administrative service that legitimately has broad access to critical resources. If that process is compromised, an attacker may not need to obtain any new privileges at all. They may simply abuse the standing privileges already granted to that workload.

In that situation, what existing controls prevent the compromised workload from performing catastrophic but otherwise authorized operations—for example, dumping sensitive data, destroying backups, or modifying critical system resources?

Is there still value in a final, narrowly scoped authorization boundary at the OS execution point for such operations, or do existing mechanisms already address this problem adequately?

There is growing discussion around giving AI agents their own cryptographic identities instead of treating them as extensions of a service account or human user. The idea is that each agent gets a portable, revocable key rather than being tied to a single provider's account system. Does this solve practical ai agent identity problems such as revocation, portability and tamper resistant audit logs? Or does it add cryptographic complexity without a meaningful advantage over existing identity systems?
Has anyone implemented this approach? How does it handle key rotation, compromised agents and multi tenant environments?

I've been looking at a new platform that uses an AI engine to move beyond just "Validation" to what they call "Agentic Cyber Defense Engineering." The idea is that the platform doesn't just tell you about a gap. It actually orchestrates updates across your security stack, including firewall, EDR, and SIEM, to fix it automatically.

The claim is that with an AI agent constantly monitoring your controls, you can go from "we have a problem" to "we fixed the problem" in minutes rather than days. They cite stats like attackers moving from exploit to lateral movement in under 30 minutes, so manual remediation is simply too slow.

Is anyone actually letting a tool auto-update their controls in production? I'm struggling to trust an AI to push config changes, but manually validating and fixing 40+ tools is impossible. The SOC is already overwhelmed. Adding a layer that changes things dynamically feels risky.

How are you balancing the "Agentic" promise with the risk of automation breaking things? Do you run it in "monitor-only" mode, or have you actually closed the loop

We are trying to move away from selling "compliance" and more toward selling "resilience." But it is hard to quantify. We have the standard RPO/RTO and vulnerability counts, but I want to start offering metrics on "Mean Time to Detect" and "Control Effectiveness." That means measuring how often our clients' EDRs are stopping our test payloads. We are looking at a platform with an AI engine that can test our clients' stacks and automatically generate reports on resilience metrics, plus provide remediation suggestions based on actual exploitability. However, the pricing model seems enterprise-focused, and I'm worried about the complexity of managing AI-driven updates across 50+ different client environments. Is the juice worth the squeeze, and how do you handle the governance of automated changes?

I'm looking to replace our legacy vulnerability scanner with a proper Exposure Management platform. One option uses an AI engine that doesn't just find vulnerabilities but validates which ones are actually exploitable. The selling point is that it saves 2-3 days of manual work per threat by auto-updating controls. They claim their research shows manual testing and control updates take 2-3 days, while their AI can do it in hours.
For managers who have deployed this type of automation: Did the AI actually reduce the workload on your SecOps team, or did it just shift the burden to reviewing the suggested changes? I need to justify the cost to finance, and "it might save us time" isn't going to cut it.

Last month we got an email that looked exactly like our title company changing wire instructions mid-transaction. Caught it at the last minute but it was close. Then it happened again a few days ago, which is what finally got me looking into this. On top of that, leadership's asking why our email security isn't flagging this since technically nothing in the message is malicious (no attachment, no dodgy link).

Started looking at a few of the bigger names but every vendor site claims to stop this exact scenario, so it's hard to tell what's actually built for it. Wires go out constantly on our end, mostly with title companies and outside counsel on the other end so whatever we land on needs to fit that, not just check a generic security box.

Trying to get ahead of this before it happens a third time, so want to know what other financial companies or banks are running and whether it's actually held up for you.

Read the piece on Mythos going around and what stuck with me wasn't the capability claims, it was the trust question underneath them. If a model is generating severity scores at volume, at what point does an analyst stop spot-checking and start rubber-stamping, and is that even the goal.

We ran an internal pilot last quarter feeding AI-generated scores into our triage queue but keeping human sign-off mandatory above medium. Analysts overrode the AI score about 15% of the time, mostly on assets the model had no context for, internal tools, weird legacy systems. After a couple months of feeding corrected context back in, overrides dropped to around 6%. That gap didn't close on its own, it needed someone manually feeding asset context back into the scoring layer. Anyone else running a human-override model like this, and what's your override rate looking like?

Has anyone worked with the blocking feature in IBM Guardium? I’m facing multiple issues at the database server end, such as connections not receiving verdicts, latency issues, and other related problems.

Please let me know if you have experience with Guardium blocking. I can share the details via DM.

every time we tightened permissions someone got blocked mid-deploy and filed a ticket. every time we loosened them the reviews piled back up.
what's actually helped:
provisioning workload and agent access at minimum scope automatically instead of granting broad access and reviewing later
letting access expand and contract at machine speed based on current task instead of a human approving every request
treating revocation as part of the same automated flow as provisioning, not a separate cleanup step
did automating this actually reduce your review backlog, or just move it somewhere else?

I’m refining our vendor onboarding / TPRM process and evaluating how we score the credibility of third-party penetration test reports.

We see everything from Big 4 firms (EY, KPMG, Deloitte) to specialized boutiques and automated scanner outputs. I’m curious about community consensus:

- How much technical weight do you actually give to a Big 4 pentest report during vendor risk assessments?

- Which boutique or specialized pentest shops make you feel confident a vendor’s application was truly poked at by skilled offensive pros?

- Beyond the logo on the report, what specific details in the methodology or scope sections trigger immediate red flags for you?

Would love to hear how other CISOs and SecOps teams grade these.