I’ve conducted a small analysis and would be glad to hear your opinion.
I've been looking at how AI may change the underlying dynamics of offensive and defensive cybersecurity.

My main question is not simply whether AI makes attacks more powerful. The more important issue may be how much it compresses the time available for human-driven defense.

A few observations seem particularly important:

1. The main change may be the economics of attack

AI can significantly reduce the cost and effort required to discover vulnerabilities, generate attack techniques, adapt tooling and scale operations.

The important shift may therefore be less about making individual attacks more sophisticated and more about making sophisticated capabilities available at much lower cost and much greater scale.

2. The attack cycle may become shorter than the human decision cycle

The timeline from vulnerability discovery to exploitation has already been a major security concern. If AI continues to compress this from weeks to days, hours or potentially minutes, human analysts may no longer be able to remain a primary component of the defensive response loop.

That creates a different problem: security systems may increasingly have to operate at machine speed.

3. The traditional patch cycle may become insufficient

The classic model:

discover → analyze → patch → test → deploy

assumes that defenders have enough time to complete the cycle.

If exploitation occurs before an organization can complete that process, patching remains necessary but may no longer be sufficient as the primary response mechanism.

4. Attack behavior may become less predictable

Many defensive mechanisms still benefit from recognizable patterns, repeated techniques and known indicators.

AI can make it easier to generate and modify attack paths, payloads and social-engineering content at scale.

The question is whether detection systems can continue to rely on relatively stable attacker behavior when the cost of producing variation approaches zero.

5. Regulation may operate on a fundamentally slower timescale

Cybersecurity controls, standards and regulation typically evolve over months or years.

If offensive AI capabilities evolve continuously, there may be a growing gap between the speed at which the threat environment changes and the speed at which organizations and regulators can formally adapt.

6. What happens to digital trust?

This is the part I find most interesting.

As AI becomes better at reproducing text, voice, images and increasingly convincing human behavior, some digital signals that have traditionally helped establish trust may become less reliable.

This raises a broader question:

If both attacks and defensive responses become increasingly autonomous, what forms of evidence remain reliable enough to establish that a critical digital action actually originated from the intended human actor?

The broader question

AI may not simply make existing attacks faster.

It may reduce the amount of time available for human decision-making itself.

If that happens, cybersecurity may increasingly become a competition between autonomous offensive and defensive systems — while raising a more fundamental question about what evidence can still be trusted when the digital environment itself becomes highly automated.

Curious how practitioners here see this. Are we actually approaching a point where human response time becomes an architectural constraint in cybersecurity, or is this overstated?

I pulled together every AI-security incident from August. The number that stood out: AI-agent exploits are now the single largest attack-vector category, ahead of credential theft, zero-days, supply chain, phishing, and ransomware — each counted individually.

The month in numbers: 123 incidents, 23 critical and 97 high severity, across 38 named organizations, 331M+ records exposed. 65 incidents involved AI as the weapon or the target. Attack vectors broke down as: AI-agent exploits (37), credential theft/reuse (28), zero-days (23), supply chain (12), phishing (9), data exfiltration (8), ransomware (6).

The stories that stood out:

- McKesson: 284M records, the largest single breach of the month by a wide margin.

- Carhartt (12.9M), Exact Sciences (10.9M), and CareCloud (3.7M) round out the biggest named incidents — three of four sit in or next to healthcare.

- Five confirmed RCEs landed across Microsoft SharePoint, Windows, F5/nginx, and the PyPI package index twice.

- Two separate PyPI supply-chain poisoning campaigns, plus a compromise of n8n, an AI workflow automation platform.

Every one of the breached companies almost certainly runs a modern security stack — CrowdStrike, Okta, Palo Alto Networks, Microsoft Defender, that class of tooling. None of it stopped these incidents, because none of it operates at the point where a credentialed agent actually acts, or where a poisoned dependency resolves at build time.

Full report, with the specific control that maps to each incident: https://runtimeai.io/blog/2026-08-monthly-breach-report.html

Genuinely curious how others are approaching this: is anyone actually testing whether their existing guardrails hold against a real simulated attack, or is it still mostly an assumption that they will?

Google has deprecated EncryptedSharedPreferences. If you're storing sensitive data locally on Android with EncryptedSharedPreferences, our latest blog covers what you should be doing instead!

https://blog.includesecurity.com/2026/08/encryptedsharedpreferences-is-dead-heres-what-you-should-use-instead/

Hey, curious if anyone here is actually leaning on AI tabletop exercises as part of their SOC 2 evidence stack.

Weve started running short incident response sims with an AI facilitator, it spits out nice after action reports, mapped controls, timelines etc. On paper it feels perfect for showing readiness, but our auditor keeps treating it like "interesting training" instead of actual evidence and im lowkey annoyed.

If youre doing this with a small security team and a mix of GRC and IR folks, how are you framing these reports so they land as real SOC 2 artifacts with auditors? Any hints?

saw the framing going around lately that as agents move from answering questions to taking actions, the risk shifts closer to ransomware-style recovery than typical prompt filtering, and that matched something we actually ran into. an agent chained a tool call in a way that modified way more records than it should have, and the recovery question felt identical to a ransomware post-mortem: how fast can we reconstruct what happened and confirm it won't happen again.

at the time we were using Lakera for runtime detection, which caught the anomalous call pattern in the logs and gave us visibility into what triggered it.

for the recovery and containment piece, we moved to Alice: WonderFence for runtime blocking, hard caps so no single action can modify more than N records without a second factor, and WonderCheck to rerun that specific scenario in CI/CD going forward so future model updates get checked against it automatically.

anyone else drawing this line between detection and actual chain-of-action recovery? feels like a different problem than what most runtime tools were built for.

Infostealer response usually starts with passwords, cookies, and session revocation.

That leaves another category of credentials behind: API keys, OAuth tokens, PATs, service-account credentials, and secrets pulled from .env files, shell history, developer tools, caches, and local application data.

Some of those credentials can remain valid long after the infected endpoint has been rebuilt and the user’s password has been changed.

We released Token Exposure Monitoring in Lunar Cyber today, and it pushed me to write about the response problem behind the feature: once you know machine credentials were taken, what exactly should the incident-response playbook be?

The post looks at how to identify the exposed credential, understand what it can access, validate whether it is still usable, and decide what needs to be rotated.

Interested to hear how others are handling this in practice, especially on developer workstations.

a terrible thing happened tha forced us to admit the phishing email training we'd been using for decades is quite outdated now. The whole checklist, bad spelling, clunky grammar, weird greeting, obvious urgency, was teaching people that clean, well-written emails are safe.we couldnt be more wrong, esp in this day and age. the attackers can write with the same tools we use and will polish their grammar to a t effortlessly and industry reports indicate that most phishing emails are partially machine written at this point.

so we swapped our phishing sim templates to AI-written ones and the click rate went up on the same people we'd already put through awareness training. And they were doing exactly what we taught checking for the tells, finding none and trusting it. Now I’m rebuilding the program around the assumption that the email will look perfect. That means teaching process over proofreading, verify any request for money, credentials or an MFA approval through a second channel no matter how legitimate it reads and leaning on controls that don't depend on a human catching it.

​

​Hey everyone,

​As LLMs get integrated deeper into daily coding, document parsing, and personal automation workflows, data security and access control are becoming critical topics. Many of us pipe sensitive project context, API keys, and personal notes through AI tools continuously.

​I’ve recently shifted a lot of my developer/workflow setup over to Proton’s ecosystem (Mail, Drive, Pass) due to zero-access encryption and Swiss privacy protections. Keeping local session exports, prompt templates, and API configuration backups behind zero-knowledge storage has been a great peace-of-mind upgrade.

​For those running heavy AI automations or managing sensitive prompt data, what security hygiene measures or encrypted storage tools are you using to protect your context files and keys?

The Hugging Face breach wasn't an AI problem. It was an access problem.

In BlackHat USA 2026, OpenAI research model breaching a sandbox environment was a hot topic. There were several discussions if the breach was real or not. OpenAI presentation and follow-up put the speculation to rest.

OpenAI model escaped its containment, chained compromised credentials, and achieved remote code execution against Hugging Face infrastructure. The evaluation showed how an autonomous system could access databases, exploit template-injection weaknesses, and move laterally across an environment.

There was nothing magical about it.

The model found a weakness in the sandbox and exploited it. The credentials it obtained were long-lived. The access paths were persistent. And the trust boundary it crossed existed more as an assumption than as an enforceable control.

That is the cloud-access problem StratoCloud was built to solve.

Zero standing privileges

StratoCloud issues ephemeral, just-in-time credentials for people, workloads, and AI agents. No long-lived keys remain in configuration files, repositories, or environments waiting to be exposed. When access expires, it is automatically removed.

Real-time, context-aware access

Every StratoCloud access decision incorporates live identity, security, and operational signals. Access is not granted simply because a user or workload is inside the network perimeter. It is granted only when the current context supports it: for the specific action, resource, and duration requested.

Continuous governance

Compliance cannot be a point-in-time exercise. StratoCloud continuously evaluates policies written in plain English or mapped to frameworks such as SOC 2, ISO 27001, PCI DSS, and CIS. When controls drift, teams can identify and respond to the issue immediately.

Audit readiness by default

Every credential issued, action performed, and policy decision evaluated is logged and streamed to your SIEM in real time. When an investigation or post-incident review begins, the evidence is already available.

The Hugging Face evaluation underscores an important reality: as AI agents become capable of acting autonomously across cloud environments, aggressive credential rotation is no longer sufficient.

Cloud access must be scoped, time-bound, context-aware, continuously governed, and observable by default.

Check us out at strato-cloud.io

Keyword list taken from https://www.zoevera.com/resume/ats-resume-tips-cybersecurity

These are the most commonly scanned keywords in cybersecurity job postings. Check how many appear in your resume.

Domains & Practices

SOC (Security Operations Centre), Penetration testing / pen test, Vulnerability management, Threat intelligence, Incident response (IR), Digital forensics (DFIR), Red team / blue team / purple team, Zero Trust architecture

Tools & Platforms

SIEM (Splunk, Microsoft Sentinel, QRadar), EDR (CrowdStrike, SentinelOne), Nessus / Qualys / Rapid7, Burp Suite / Metasploit / Kali Linux, Wireshark / Snort / Suricata, CyberArk / BeyondTrust (PAM), SOAR platforms, Azure Defender / AWS Security Hub

Frameworks & Certifications

CISSP / CISM / CISA, CEH / OSCP / PNPT, CompTIA Security+ / CySA+, ISO 27001 / NIST CSF, MITRE ATT&CK framework, SC/DV security clearance, GDPR / DPA 2018, PCI DSS / HIPAA / SOC 2

https://blog.google/security/new-android-network-security-protections/

Google came out with this article today. I'm wondering if iOS supports similar technology, and if not, what can be done in the interim to mitigate against the threats raised by Google?

I'm evaluating AI detection and response tools for our SOC, and I'm trying to understand if they can realistically close coverage gaps we've been struggling with. We run a mixed environment with about 5,000 endpoints and multiple cloud providers.

Our current coverage issues:

Unclaimed assets: About 15% of our alerts come from assets that aren't properly mapped to an owner. Our current SIEM can't correlate asset ownership, so these alerts either get dropped or sit in a queue until someone randomly picks them up.

Low-severity backlog: We consistently miss low-severity alerts that later turn out to be early indicators of larger issues. For example, last quarter we had a series of informational alerts over 3 weeks that, when correlated, pointed to an insider threat. We only caught it during a manual retrospective.

Cross-environment patterns: Our current rules are per-environment, so we can't easily spot patterns that span across our on-prem and cloud workloads.

What I'm trying to figure out:

Can modern AI detection tools actually correlate across these silos without weeks of custom tuning?

How do they handle asset ownership context?

I need to set realistic expectations for my team before we commit to a POV.

I've sat through probably eight SOC vendor demos in the last two months, and every single one claims to be "agentic" now. The pitch is always the same: it triages and closes p1/p2 alerts on its own.

But they never say what happens when it's wrong. Like whether it hallucinates on our specific kind of alerts, not just the ones they tested. Or whether an analyst override actually goes anywhere, or just gets logged and forgotten. And when I ask for real accuracy numbers, I never get a straight answer.

So we ran a short pilot with one platform last quarter, mostly on our tier 1 triage queue. It handled the alert volume fine, keeping up was actually the easy part. The hard part was getting the team to trust the verdicts enough to act on them without having to rerun the whole investigation by hand.

We were doing the work twice. I'm still trying to figure out if this is on the vendor for shipping something that isn't mature or transparent enough, or on us for not trusting a tool we can't fully audit. Am I the only one struggling with this

What's your experience been with AI SOC?

17 years as a full-stack dev and security admin. Ran a digital agency, shipped a pile of client apps, always building someone else’s dream. Being a SaaS founder myself? Never crossed my mind.

Then AI happened. Suddenly everyone’s shipping apps in a weekend, fast, exciting, and about as secure as a screen door on a submarine. And I kept thinking: I’ve watched this movie, I know how it ends, someone’s .env is already on GitHub.

Here’s what always bugged me: real security is priced for big companies. A proper pentest? Thousands. Enterprise WAF? Hundreds a month. The average site owner takes one look and just… ships and prays. I did it too. Got burned enough to remember every scar.

So I built Defen.so, security a normal human can afford: scan your code and site, catch leaked keys, block attacks, watch uptime and SSL, all in one. Plus a phone app that rings like a call when something breaks, because nobody’s reading a 3am email.

Turns out building the thing was the easy part. Selling it? Absolute mystery. Send help.

Free tier, open source, roast it here: https://defen.so

Genuine question for fellow builders, what do you actually use for security, or are we all just vibing and hoping?

I gave Claude Code access to a project folder and asked it to read .env.

It tried ls, find, cat, and the MCP filesystem tool. All four blocked,

and every attempt is in a hash-chained log I can verify offline.

Deny-by-default on tool calls, kernel sandbox on subprocesses, outbound

requests checked before they're made.

Runs entirely on your Mac. No account, no cloud. macOS only for now.

It does not stop prompt injection, and can't protect anything outside

the MCP boundary — both documented in the threat model.

Free: github.com/Adarsh14734/aegis/releases/tag/v0.6.0

Long-time FortiGate shop, 30-odd sites, mixed hardware ages. Refresh is coming up and the AI security requirement is forcing a bigger conversation than a normal hardware swap.

The Fortinet path as I understand it: keep the Fabric, lean on FortiSASE for remote users, use the newer AI governance and inline inspection capabilities, keep everything in FortiManager/FortiAnalyzer. The big advantage is my team already knows it and we are not retraining anyone.

The Cato path is a full architecture change. Their PoPs, their edge devices, cloud-native single-pass everything, and the AI controls are native to the same policy engine rather than a module.

Where I am undecided: inspection performance on AI traffic, because on-box inspection is bounded by the box, which is fine at HQ but less fine at a branch running a five-year-old unit; feature parity between the on-prem and the SASE side, since historically these have not been identical and I do not want AI policy that only applies to remote users; and the operational cost of the switch versus the value of the newer capability.

For anyone who has run FortiSASE with AI controls seriously, or bailed to Cato: what actually decided it for you? Trying to separate "this is genuinely better" from "this is different and shiny."