r/ciso

what do you think is stopping AI agent adoption in the healthcare software space?

outsiders POV : I'm thinking security but how would u guys solve this from inside the industry?

finding problems was never the hard part for us. deciding what to fix first with a small team is.

what's changed things for us is having full discovery and mapping feed directly into prioritization, so the tool tells you which of the hundred findings actually raises your risk instead of handing you a flat list. has anyone gotten real prioritization value out of a platform like that, or are you still triaging manually after the scan runs?

So, to give some background. I lead the threat intelligence program of a major bank. Now we receive tons of IOCs/CVEs and brand abuse/impersonation cases and we do take action on them accordingly.

But whenever we create a presentation, it's always numbers

- no. Of IOCs we received, sources (regulator/commercials)

- social media/brand abuse/impersonation/rogue apps count & takedown status.

But execs don't understand these numbers. How can I present the data such that they are assured that we are safe from any kind of threat & prepared for what's coming in the future.

Been researching lots of things but didn't quite get anything. Would really appreciate your views and guidance here.

Hi everyone, hoping to use this as a bit of a sounding board. My department recently had a discussion about who owns different categories of sensitive business data. Security and IT each thought the other team owned the data, and it feels like ownership gaps are creating almost as much risk as technical issues. Has anyone found an effective way to assign clear ownership across cloud platforms, SaaS apps and AI tools without creating too many governance meetings?

Every time a new cyber threat campaign or headline breach appears, my CISO comes in Monday morning with the same question: “are we covered for this” Turning that into a clear, defensible answer about our detection coverage and security posture is becoming a separate job.
We have what most people would call a mature security stack in 2026: a central SIEM, EDR on endpoints, cloud and identity logs, some threat intelligence and custom detection rules. We can show that controls are deployed, that we have rules for specific MITRE ATT&CK techniques, and that dashboards report healthy alerting. None of that directly answers whether we would detect a specific attack path in time or where the real detection gaps are.
Right now our detection coverage assessment process for new campaigns is manual. We map the campaign to MITRE ATT&CK techniques, check which techniques already have detections in the SIEM and EDR, and run quick lab tests or simulations to see if those alerts would fire. This threat‑informed detection engineering approach works, but it is slow and inconsistent; the output depends on who performs the review, how deep they go, and how much time the team has during incident response and day‑to‑day SOC work.
If you support a CISO or security leadership team, how do you answer the question in a way that your CISO can use confidently in a mng meeting without oversimplifying or overstating the reality?

[supprimé]

We are currently evaluating AI security platforms for enterprise AI deployments and Noma Security keeps coming up.

The problem is that it is hard to tell what actually matters until AI agents are running in production. Prompt attacks are one thing, but governance, runtime visibility, and data exposure seem like the bigger concerns. Being able to track what agents are doing over time and explain their decisions is also important.

For anyone who has compared Noma Security alternatives, what did you end up caring about most?

I’ve been working on an open-source project called AVE (Agentic Vulnerability Enumeration), the behavioral classification standard and would really appreciate feedback from security professionals.

The motivation is that we’re starting to secure things like:
- MCP servers
- Skill files
- System prompts
- Agent plugins
- Agent workflows

But today’s vulnerability identifiers (CVE, OSV, etc.) are designed around software packages and versions. They don’t describe behavioral attacks that exist only because an LLM interprets instructions.
For example:
- Prompt injection hidden inside a skill
- Tool description poisoning
- MCP server-card injection
- Memory poisoning
- Cross-agent prompt injection
- Silent tool registration
- Unsafe delegation chains
These aren’t tied to a vulnerable library version, they’re behavioral attack classes.

So AVE attempts to provide:
- Stable IDs for behavioral attack classes (currently 59)
- A JSON schema for interoperability
- AIVSS scoring (built on CVSS concepts with agent-specific risk factors)
- Crosswalks to OWASP MCP Top 10, MITRE ATLAS, NIST AI RMF, and other AI security frameworks
- A reference scanner (Bawbel Scanner) that detects AVE patterns in skill files, MCP manifests, and related agent artifacts

I’m not claiming this is the right solution, and I know standards only become useful if practitioners find them valuable.

I’d really appreciate criticism on questions like:
- Does this solve a real problem, or are existing standards already sufficient?
- Should these behavioral classes live under something like CVE/CWE instead of a new namespace?
- Are the attack classes too broad or too granular?
- Does the AIVSS scoring model make sense, or is there a better way to score agentic AI risk?
- What important attack classes am I missing?
- If you were building security tooling for AI agents, would a registry like this be useful?

I’m especially interested in feedback from people working in AppSec, AI security, offensive security, detection engineering, or anyone building MCP/agent ecosystems.

I’m looking for honest technical criticism more than praise. If you think this is the wrong direction, I’d genuinely like to know why.

Thanks for taking a look.

our alert backlog and investigation times have both crept up, and we're starting to miss things we shouldn’t, so i've been taking vendor calls more seriously this quarter. six demos in and slide five is always some version of the same before-and-after chart mentioning "faster investigations," "AI-powered detection." at some point the pitches look all the same.
i know the underlying problem is real. what i don't know is how I can differentiate real value from fluff and empty promises from a good deck in a 30 min call. So, for the CISOs here who've gone through a real evaluation process, did you find a specific question that helps you understand whether a vendor can back up their claims, versus one that just repeated the same talking points when pushed?
any advice would help a lot.

I inherited the role from someone else, and I am trying to simplify some things. One of those things is the KPIs of our ISMS.

Currently, we do have around 15 KPIs that are not clearly defined and are somewhat open to interpretation, and they are linked to specific controls. Example:

A.8.21 Segregation of Network Services (no formula to calculate that); it seems incidents that touch that point were counted.

I am aware KPIs have to be set in consultation with management after introspection, but for the time being, while I get things under control. I wanted to ask you how many KPIs you have in your ISMS?

And do you explicitly link them to a single control?

I checked with AI tools about this topic; it gave me a more structured answer, but I want to compare those notes with real-world practice.

Any insight?

A month ago I asked this sub how CISOs actually consume threat intel. The thread wasn't too active but was gold.

A few things worth noting:

• One of you gets Claude Code to generate a morning threat brief mapped to your stack, industry, and geos. That's the product half the vendor market is trying to sell.
• Another said the best CTI they've seen is an analyst who writes a weekly one-pager — which quietly anchors the real price of this problem at $80K–$120K/year.
• Recorded Future / Dataminr users kept saying the same thing: the intel is fine, the synthesis is the bottleneck.

Then I come across the SANS 2026 CTI Survey who said the quiet part out loud: 91% of CISOs value CTI, only 26% say it actually influences their decisions. A 65-point gap.

So I started a small newsletter to test one hypothesis: what if threat briefs were written as decision packages, not intelligence reports?  Act Now / Watch / Awareness. Two pages max. AI in the loop, human on the call.

Issue #0 is a manifesto, not a threat brief. Issue #1 will be the real thing. I'm publishing in the open partly to keep myself honest.

Link in comments. Not selling anything.

Question back to the sub: if you had to cut a CTI report down to one screen your CEO would actually read before their 8am, what stays and what dies?