🚨Standard Chartered CISO's Approach to Designing Judgment Out of Security

JFrog Artifactory minted admin tokens on default configs three days after the patch, PaperCut's first emergency fix was bypassed within a day, and $600,000 in AI model credits went out on a stolen key nobody noticed for three weeks. Eight stories this week, and almost every one turned on a credential already sitting somewhere reachable. Cezary Piekarski, Group CISO at Standard Chartered, on why prompt filtering is repeating the buffer overflow mistake and what survives at machine scale instead.

Author

Ashish Rajan
September 02, 2026

Hello from the Cloud-verse!

This week's Cloud Security Newsletter topic: Design the Judgment Out of Your Security Controls (continue reading) 

This image was generated by AI. It's still experimental, so it might not be a perfect match!

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter!

Eight stories cleared the bar this week and none of them was a headline breach in the traditional sense. What they share is smaller and more uncomfortable: in almost every case, the thing the attacker needed was already sitting somewhere the security model had not accounted for. JFrog instances without an explicitly configured join key were handed a "phantom" one that attackers could forge against. Manchester Airports Group's customer-engagement API credentials were readable in the page source. METR's model-provider API key was on a researcher's personal EC2 box behind authentication that failed open, and nobody noticed three weeks of theft because the credits were free and free resources have no billing alarm.

Against that, this week's conversation is with Cezary Piekarski, Group Chief Information Security Officer at Standard Chartered Group, hosted by Ashish Rajan. Cezary runs security for an institution operating across 50-plus markets, and his position is that detection-led security stopped being viable at that scale years before AI entered the conversation. His prescription is blunt: eliminate the corner cases that require a human to make a call, because "judgment tends to be wrong."[Listen to the episode]

⚡ TL;DR for Busy Readers

  • 🚨 JFrog Artifactory CVE-2026-82329: admin tokens minted on default configs, exploited three days after patch. Go to 7.161.20 and rotate every token it issued.

  • 🚨 Both PaperCut zero-days in CISA KEV, federal deadline September 14. The first patch was bypassed within a day, so check the build, not the ticket.

  • 21,899 Exchange servers still exposed to a capture-replay auth bypass. Exploit code is public and MFA is not in the path.

  • McKesson and Manchester Airports Group: both lost data through the SaaS tier, one by vishing into Salesforce and Snowflake, one by an API key in the page source.

  • Cezary Piekarski's control test: if a control needs someone to judge whether an event is benign, it is the wrong control.

📰 THIS WEEK'S TOP SECURITY HEADLINES

Each story includes why it matters and what to do next — no vendor fluff.

1. CISA adds both PaperCut zero-days to KEV as the vendor's first patch gets broken

Primary source: CISA KEV alert 
Reporting: BleepingComputer, SecurityWeek 
Analysis: Huntress, Rapid7, PaperCut advisory

What Happened

CISA added CVE-2026-81578 (an authentication bypass letting unauthenticated requests reach administrative configuration functions) and CVE-2026-82078 (unsafe dynamic class loading in the database connection utilities) to the KEV catalog on August 31, with a federal remediation deadline of September 14. PaperCut published its bulletin on August 27 and shipped a first emergency patch for NG/MF versions 25 and 26 on August 28. watchTowr found multiple bypasses of that fix plus an additional authentication bypass, and PaperCut released a second emergency patch later the same day. Huntress saw the first exploitation attempts on August 26 and has confirmed attacks against at least two customers. As of August 30 the vendor advisory still described an official combined release as in progress.

Why It Matters

The vendor's fix was defeated inside a day, which means the remediation status in your vulnerability management system is unreliable for anyone who patched on August 28 and provisional for everyone else until the official build lands. Print management is also a category most cloud security programs file under facilities IT, so PaperCut frequently sits outside the asset inventory that drives a KEV-triggered emergency change window. One observed actor is abusing the auth bypass to hijack PaperCut's external user-lookup and dump database tables through Derby, which converts a print server into a directory data source. Roughly 1,000 instances are internet-exposed.

Action for defenders: Check the running build rather than the ticket, re-read the vendor advisory for the official combined release, and replay the published IoCs against logs going back to August 26.

2.  JFrog Artifactory auth bypass weaponized to mint admin tokens three days after patch

Primary source: The Hacker News 
Reporting: SecurityWeek, The Register 
Analysis: Dark Reading

What Happened

CVE-2026-82329 (CVSS 9.8) is an authentication weakness in JFrog Access, the component that issues and validates Artifactory credentials. watchTowr's finding is that instances without an additional join key configured receive a "phantom" join key attackers can forge against to mint administrator-level credentials, with no authentication and no user interaction needed under default configuration. JFrog patched in Artifactory 7.161.20 on August 28. watchTowr's Yordan Ganchev reported weaponization beginning September 1, used to generate admin tokens and enumerate users, groups, credential sets, and federated access topologies. Self-managed deployments are affected; the JFrog SaaS platform is not.

Why It Matters

The vulnerable state is the default state, so the exposed population is every self-hosted instance nobody deliberately hardened. What the attackers do first is telling: they enumerate the federated access topology, mapping which other systems trust this registry before touching anything. Artifactory admin sits upstream of build pipelines and production artifacts, so the blast radius is whatever your deployment automation will pull.

Action for defenders: Patch internet-exposed self-managed Artifactory to 7.161.20 today, then treat every access token, federated trust, and service credential that instance ever issued as suspect and rotate. Restoring the pre-patch credential state restores the attacker's access with it.

🛠 If you only do one thing this week: Pull the list of every non-human credential your artifact registry, CI system, and AI orchestration hosts have issued in the last 90 days, and check which of them have an expiry, a scope, and a spend or rate ceiling attached. Three of this week's eight stories turn on a credential that had none of the three.

☁️ 3.  Langflow RCE exploited to harvest cloud credentials from the AI application layer

Primary source: SecurityWeek 
Reporting: BleepingComputer, Dark Reading 
Analysis: ZDI advisory ZDI-26-034

What Happened
VulnCheck reported active exploitation of CVE-2026-0768 (CVSS 9.8), an unauthenticated RCE in the code validator of Langflow's custom component editor. A user-supplied string reaches Python execution without validation, giving arbitrary code execution as root. The flaw went through ZDI in July 2025 and was publicly disclosed as a zero-day in January 2026; every release through 1.4.2 is affected. VulnCheck observed the current wave from August 29 — environment-variable queries, secret-key reads, and SSH access attempts, mostly originating from Russia. Before 2026, one Langflow vulnerability was known to be exploited in the wild. Eleven more have been targeted since.

Why It Matters
Nothing here is a payload drop. The post-exploitation activity is a credential sweep: Langflow's secret_key, environment variables holding API keys and cloud credentials, SSH keys, .env files. An AI orchestration host is an aggregation point for exactly the secrets that grant access to everything downstream of it, and it usually gets stood up by a platform or data team without passing through the application onboarding process that would have caught the exposure.

Action for defenders
Inventory Langflow by network exposure rather than by ownership record, confirm version against 1.4.2, and rotate any cloud or model-provider credential that has ever been present in a Langflow environment.

🏥 4. Roughly 21,900 Exchange servers still exposed to a mailbox-takeover auth bypass with public exploit code

Primary source: BleepingComputer 
Reporting: NCSC-NL advisory 
Analysis: Microsoft MSRC, Shadowserver dashboard

What Happened

CVE-2026-62911, reported by DEVCORE's Orange Tsai and patched in the August 2026 Patch Tuesday, is an authentication bypass by capture-replay affecting Exchange Server 2016, 2019, and Subscription Edition. Microsoft's advisory states an attacker "would be able to take over the mailboxes of all Exchange users." Shadowserver counted 21,899 IP addresses with an unpatched Exchange fingerprint on September 1, concentrated in the United States (6,200) and Germany (5,100). Germany's BSI put the figure at roughly 85% of German on-premises Exchange servers. NCSC-NL reports exploit code is already circulating. Microsoft has not confirmed in-the-wild exploitation.

Why It Matters

The attack replays captured authentication traffic, so every control your program built around credential strength sits outside the path being abused.

Action for defenders
Query external attack surface data for Exchange fingerprints you did not know you owned, confirm the August update is present, and put a hard date against the October 2026 end of the Extended Security Updates program for any 2016 or 2019 server still standing.

🛡️ 5.  Anthropic warns that stolen Claude session cookies are bypassing MFA and draining accounts

Primary source: SecurityWeek 
Reporting: BleepingComputer, Security Affairs

What Happened

Anthropic emailed affected Claude customers to warn that commodity infostealer malware on their own machines had let attackers hijack authenticated sessions and consume usage. The named families are Vidar, Lumma, StealC, RedLine, and Acreed on Windows, plus Atomic Stealer on a smaller number of macOS devices. Anthropic assesses that a threat actor was selecting Claude sessions out of broader harvested infostealer data. The company signed out compromised sessions, removed saved payment methods so accounts could not be charged, and refunded charges it identified as unauthorized. The signal it gave users was a usage limit that refills and then drains while the owner is not using the product.

Why It Matters

The stolen artifact is a post-authentication session cookie, which means multi-factor authentication is not in the attack path and neither is any conditional access policy that evaluates only at sign-in. The detection signal Anthropic handed users was consumption anomaly, and that is not a signal most enterprise SaaS monitoring collects for AI tools. Any organization where employees reach AI services from unmanaged endpoints carries this exposure with no telemetry to see it.

Action for defenders: 
Confirm your AI service subscriptions are enrolled in SSO with short session lifetimes rather than long-lived browser sessions, and add per-account consumption baselines to your SaaS anomaly detection.

6.   METR discloses a stolen API key, three weeks of undetected use, and roughly $600,000 in model credits burned

Primary source: METR security update 
Reporting: The Register, The Hacker News 
Analysis: Infosecurity Magazine

What happened: METR published a post-incident writeup covering two 2026 incidents. In March, a researcher ran agents on a personal EC2 instance made public behind Google authentication; the application held an API key for METR's public-models account, and a fail-open flaw silently disabled authentication, leaving the system exposed for several days. METR assesses the attacker found the instance by mining certificate transparency logs for recently registered sites carrying LLM and agent keywords. The attacker prompted the agent to reveal its API key, added an SSH key for persistence, and consumed credits worth approximately $600,000 over three weeks. In May, attackers systematically probed METR's public infrastructure using agents to automate discovery, and a read-only SQL query mechanism exposed through the public transcript viewer carried a bug that could have reached unpublished evaluation data. An independent researcher disclosed it and was paid a bounty.

Why it matters:  Three failure modes here generalize cleanly. Certificate transparency logs are now a targeting feed for finding freshly deployed AI applications, which kills the assumption that a new internal tool is obscure. A fail-open authentication default in an agent-built application produces a silent public exposure rather than a visible error. And the reason nobody caught three weeks of theft is that the credits were free, so there was no spend ceiling and no billing signal to trip. The detection depended on a control that did not exist because the resource had no price. METR's remediation was architectural: an isolated public production environment separated from internal infrastructure.

Action for defenders: Enumerate model-provider API keys living outside your managed infrastructure, and check that every key you issue carries a spend or rate ceiling — including keys covered by free or granted credits.

7.  McKesson confirms exfiltration as ShinyHunters claims 284 million records and a $55M demand

What happened: McKesson, which distributes roughly a third of prescription medicines to North American hospitals and pharmacies, disclosed in an SEC filing that it discovered a cybersecurity incident on August 25. It later confirmed data was exfiltrated from a subset of customers in its Oncology & Multispecialty and Medical-Surgical business units, said the incident involved third-party applications, and stated it did not disconnect systems in response. ShinyHunters added McKesson to its leak site around the same time, claiming 284 million records and demanding approximately $55 million with a September 1 negotiation deadline. The group told BleepingComputer it gained access through voice phishing against multiple McKesson employees, then moved into Salesforce and Snowflake and pulled roughly a terabyte over four days. Every figure and the access path are attacker claims; McKesson has confirmed exfiltration but not scope, count, or attribution, and BleepingComputer reports ShinyHunters clarified that 284 million is a raw record count rather than unique individuals.

Why it matters: If the attacker's account holds, no software vulnerability appears anywhere in the chain. A phone call produced credentials, and those credentials were sufficient for bulk export from two separate SaaS and warehouse platforms. That makes the controlling variable your query and export limits on the analytics tier. A terabyte over four days is a volume that data-warehouse egress monitoring can catch and mailbox-centric SaaS monitoring cannot.

Action for defenders: Check that your Snowflake and Salesforce tenants enforce network policies and export volume thresholds on human user sessions rather than only on service accounts, and confirm helpdesk identity verification covers voice-channel credential and MFA reset requests.

8.  Manchester Airports Group breach traced to SaaS API credentials exposed in client-side JavaScript

Primary source: BleepingComputer 
Reporting: MAG disclosure coverage, SecurityWeek 
Analysis: Security Affairs

What happened: Manchester Airports Group, the UK's largest airport operator, disclosed on August 27 that a third party stole customer data tied to car park, lounge, and Fast Track bookings and in-airport Wi-Fi registrations at Manchester, London Stansted, and East Midlands. The extortion group FulcrumSec claimed responsibility, told BleepingComputer it took approximately 86 GB including a 21.5 GB Manchester customer export, and said it obtained access using airport-specific Iterable API credentials exposed in client-side JavaScript. BleepingComputer validated one traveller's record against known purchase history and found the sampled data ran broader than MAG's initial disclosure, covering booking references, prices, parking dates and times, historical spending, IP addresses, approximate locations, and device information. No payment card data appeared in the samples. MAG declined to address the specific claims. the volume, the record counts, and the access path are FulcrumSec claims; the ~8.7 million customer figure comes from a MAG spokesperson quoted in secondary reporting.

Why it matters: A customer-engagement platform API key shipped to the browser is a class of exposure no cloud posture tool inspects, because the credential is not in your cloud account. It is in your front-end bundle. The data combination matters more than the headline count: a full UK postcode narrows to roughly 15 addresses, and pairing that with vehicle registration, terminal, and a confirmed future travel date produces a phishing pretext the target can verify as genuine.

Action for defenders: Grep your production front-end bundles for third-party SaaS API keys and tokens, and confirm every marketing or engagement platform integration runs through a server-side proxy with scoped, rotatable credentials.

🎯 Cloud Security Topic of the Week:

Prompt filtering is stack protection, and we already know how that ended

Cezary Piekarski's central argument this week is a historical one. He is old enough to remember "smashing the stack for fun, fun and profit" and the buffer overflow era that followed, and he watched the industry spend years trying to protect the stack and filter input so a program could not overwrite the memory segments steering execution.

"And this attempt was actually futile in majority of the programming languages. And we kept improving those mechanisms and we keep- kept failing." — Cezary Piekarski

What ended the buffer overflow era was not a better filter.

"the problem faded away when we moved towards a slightly different approach to the way we design CPUs and we, we introduced the memory management in the CPU" — Cezary Piekarski

His claim is that LLM security is currently at the stack-protection stage of the same curve. The industry is investing in classifiers, in input sanitization, and in artificially separating the instruction channel from the data channel inside a prompt.

"There is lots of efforts to think about how you artificially try to distinguish the instruction piece from the data piece in prompt, but I also see all of those attempts as largely futile at this stage." — Cezary Piekarski

"it, it might be that there is something much more deeper into the way LLMs operate that we're required to change for them to be secure." — Cezary Piekarski

For a practitioner, the useful consequence is not fatalism about prompt filters. It is a budgeting decision. If input filtering is a holding action rather than a solution, then the controls worth over-investing in are the ones that limit what a compromised model context can reach: scoped credentials, egress restrictions, and the blast radius around the agent rather than the prompt going into it. Cezary's own framing of the unknown-unknowns problem makes the same point from the governance side.

"you need to be very clear about the limitations of your controls, but also about the limitations that you might not be cognizant of. So, so those are unknown unknowns in the process." — Cezary Piekarski[Listen to the full episode →]

Definitions and Core Concepts 📚

Before diving into our insights, let's clarify some key terms:

  • Security as a business enabler — a cliché unless backed by two things: an engagement and operating model that embeds security people into business or engineering structures, and a security culture built on priorities shared with the business.

  • Time to adapt — a measure of "your malleability of the organization," how fast the organization can pivot. Cezary cites it as an existing measurable that programs already talk about.

  • Deception (as a control) — traps and breadcrumbs placed in the environment. Only effective when designed into infrastructure and applications so it is "believable, to be genuine," and adaptable to specific adversary TTPs.

  • UEBA — behavioral detection built on the assumption that unusual activity is malicious and usual activity is benign. Cezary treats that assumption as the technology's core defect.

  • Training data poisoning — attacks that "leverage training data poisoning to influence the output of LLMs." Cezary expects brand infringement and social engineering categories to emerge from it.

  • Phantom join key (from this week's news, not the episode) — in JFrog Access, a join key automatically assigned to instances with no additional join key configured, which attackers can forge against to mint admin credentials.

  • Capture-replay authentication bypass (from this week's news) — the CVE-2026-62911 technique: capture authentication traffic, replay it, impersonate the user. Credential strength controls are not in the path.

  • Fail-open authentication (from this week's news) — an authentication layer that grants access when it errors rather than denying it. The root cause of METR's March exposure.

This week's issue is sponsored by Varonis

What’s the blast radius of your AI agent?

Your cloud provider may secure the AI platform but you still decide what your agents can access, what permissions they have, and what actions they can take.

On September 2, I’m hosting an online panel with the security research team at Varonis on to break down real AI agent attack scenarios and what security teams should be doing about them.

💡Our Insights from this Practitioner 🔍

1. "Business enabler" stays a cliché until the operating model changes

Cezary opens by refusing the phrase on its own terms.

"Yeah, it is, it is probably, like, the most, most overused cliche phrase in, in the security industry. And, and I think it re- it remains, uh, a cliche, uh, until, until you do at least two important things, and those two important things are: the first one is is a proper engagement and operating model" — Cezary Piekarski

The two things are structural, not attitudinal. First, an engagement model that physically places security people inside the business: a security person embedded in the engineering squad, connected upward through a chapter or equivalent construct, or a BISO organization mapped to businesses and geographies in a more traditionally structured company. Second, a culture built on shared priorities.

"So as far from being a department of no as, as possible." — Cezary Piekarski

He is careful not to make the culture point mushy. Roles differ, disagreements happen, and he notes they "can get heated if people are very passionate about their jobs." The shared goal is what makes the disagreement productive rather than terminal.

 2. Detection-first security stopped scaling before AI arrived

Asked whether AI changes the traditional reactive detection-and-response model, Cezary's answer is that the change already happened and AI is only accelerating it.

"when you really think about the scale, if you operate at y- 50 plus markets and you have relatively extensive technology footprint, it means that you probably ingest a tune of 50 terabytes of observable data a day plus, right?" — Cezary Piekarski

"which means that the manual triage and the very detective focused, uh, approach is, is not right for you no matter whether you have AI or, or not, right?" — Cezary Piekarski

The prescriptive half of this is the most transferable line in the episode.

"obviously eliminate this type of corner cases because this, uh, includes jud- judgment, and judgment tends to be wrong. So try to make it as, as preventative, as defined, as binary within the guardrails as possible." — Cezary Piekarski

Read that as a test you can apply to any control in your stack. If it requires a person to decide whether an event is benign, it is a weaker control than one that makes the event impossible. He extends the same logic to response: there is "not really much alternative to having a fully automated, uh, response and containment capabilities," and the organizational work is defining the boundaries within which a machine may contain, including the business trade-offs, because "some of those decisions are not, uh, cost-free."

3. UEBA's premise is wrong, and the fix is in the application

Cezary names the failure precisely.

"what usually happens is that people fall into the trap of unusual means means malicious, usual means benign, right?" — Cezary Piekarski

Ashish pressed him on whether humans are patterned enough for the technique to work at all, with an analogy that will land with anyone who has tuned one of these systems.

"I may be drinking the same coffee in the same cafe for, I don't know, three months in a row, but one day I just got over the coffee and I decided to go to another shop." — Ashish Rajan

Cezary agrees the human-pattern critique is real, and adds a structural one:

"when you have the obser- ob- observation window that is wide enough, everything becomes the same color, right?" — Cezary Piekarski

But he treats both as secondary to a practical problem: the systems covered by behavioral tooling frequently do not have the telemetry to support the conclusion, or the telemetry is too generic to draw one. His alternative is to fix the application rather than instrument around it.

"it's, it's better to do the right segregation of duties within the application implement a proper authentication authorization model, uh, and ensure the application is just well designed to be secure instead of trying to make it deliberately unsecure and then overlay some sort of behavioral detection engine on top of it to try to detect outliers." — Cezary Piekarski

He is explicit that AI does not rescue the technique. It "is only em- emphasizing and reinforcing th- this problem at the, at the machine scale."

4. Deception is due a revival, and agentic attackers are the reason

Cezary is dismissive of how deception has historically been bought: after the security program is built, with surplus budget, breadcrumbs scattered and hope applied. Done that way it sometimes works, and he says so. Done properly it requires two design conditions. Deception has to be built into the infrastructure and applications so it reads as genuine, and the platform has to pivot to the TTPs actually in use.

"there might be a revival of deception platforms but clearly they need to be done in a very different way. They need to be designed into the ecosystem to be believable, and they need to be flexible enough to adjust to the TTPs and all specific campaigns that you are seeing out there." — Cezary Piekarski

His reason for expecting the revival is the interesting part, and it is a genuinely useful asymmetry:

"we are already seeing that some of the agentic attack scenarios broadly understood, uh, they have a tendency of walking into this trap, right?" — Cezary Piekarski

"Because they don't have this, this instinct of, uh, of, of experienced red teamer or an attacker, which is like something fishy here, right?" — Cezary Piekarski

An experienced human operator gets suspicious when access comes too easily. An agent optimizing toward a goal does not.

5. AI is already reliable on known vulnerability classes

Cezary declines to treat this as an open question.

"It's, uh, empirically confirmed that, that frontier models or, and not frontier models are, uh, are robust in identifying known classes of, uh, of vulnerabilities." — Cezary Piekarski

The example he reaches for is the one that should worry anyone running a patch cadence:

"situations in which you have a sort of be- before patch and post-patch binary, and you diff those two and, and you derive vulnerability that was addressed by patch." — Cezary Piekarski

Patch-diffing is not new. What is new is the cost of doing it, and the number of people who can now do it without the reverse engineering background that used to gate the technique.

6. Prompt filtering is stack protection, repeating

Covered above as the Topic of the Week. The compressed version: the buffer overflow class did not fall to better input filtering, it fell to an architectural change in how CPUs handle memory, and Cezary expects the LLM equivalent to require a similarly deep change rather than a better classifier. Ashish put the same uncertainty from the defender's side.

"We have a category called prompt injection, but we don't know if we have seen all versions of it." — Ashish Rajan

7. The under-discussed attack is the one everyone is discussing

Asked which AI attacks deserve more attention, Cezary picks prompt injection, the one with the most attention already, because the attention rests on a false premise.

"there is this, I think a certain naiveté in a f- in, in, in the way people think about it is that, that by creating a better and better filters you can, you can protect, uh, the model from, uh, from this category of attacks. I, I don't think that this is actually what happens." — Cezary Piekarski

He points to format-shifted variants that walk past filters: encoding tricks beyond ASCII and base64, and images used as an injection channel. The structural reason he expects filters to keep losing is the breadth of the input surface, "the richness of the communication channels that are available to interact with, uh, with, uh, large language models and with the harnesses."

His second answer has a longer fuse.

"I think that there will be lots of data poisoning attacks especially when, when more established LLMs will be out there, and you're gonna see see categories of attacks in this space related to brand infringement to social engineering and to other broader categories of attacks that will leverage training data poisoning to influence the, the output of LLMs." — Cezary Piekarski

8. Board communication is a three-part sequence, and most CISOs run only the third part

Cezary has been briefing boards for years, first in consulting and then in industry roles, and his model is sequential.

"you need to use a mix of generic education that is not really risk-focused. It's more about simply how technology works." — Cezary Piekarski

Step one is education with no risk framing attached, deliberately staged with dissent in the room: "diverse points of view being brought to the table with people who disagree with you also speaking." Step two is a small one-to-one space for the follow-up questions people will not ask in a committee. Only then does risk enter.

"And only when you have those two in place you can talk about risk." — Cezary Piekarski

And the failure mode, which most readers will recognize:

"there is a CISO coming to the board and saying, "Oh, you know, the number of incidents this, and the number of incidents that, and buffer overflow here and other buffer overflow there," right? It never works because people don't have the taxonomy and context but also they simply don't have the wealth of diverse perspectives that help them to judge whether, your SLA for vulnerability remediation makes sense or not." — Cezary Piekarski

9. Security data versus privacy is a "fake dilemma"

Ashish raised the tension he keeps hitting with US and UK financial institutions: AI wants more data, privacy obligations want less. Cezary rejects the framing.

"I think to some extent this is fake dilemma." — Cezary Piekarski

His reasoning is that security work does not actually depend on the personal data:

"what is really important from the security point of view is, is rather the, the metadata the surroundings, the observability that you can bring to understand what is happening rather than the specifics of the individuals, uh, or groups that, that you protect." — Cezary Piekarski

He has made genuine scope-of-oversight trade-offs in prior roles and does not pretend the conflict never arises. He calls it "a very rare situation and very rare problem," and says that in the significant majority of cases the security requirement and the privacy obligation can both be met.

Practical takeaways

  1. Apply Cezary's judgment test to your top ten controls this quarter. For each, ask whether it requires a human to decide if an event is benign. The ones that do are candidates for redesign toward a binary guardrail.

  2. If you run behavioral detection, audit the telemetry underneath it before tuning the model. Generic telemetry produces confident conclusions from insufficient evidence.

  3. Treat scoped credentials and egress limits around AI agents as the durable investment, and input filtering as a holding action with a shelf life.

  4. Before your next board session, count how much of your last three presentations was risk metrics and how much was technology education with no risk framing attached.

Podcast Episode

Question for you? (Reply to this email)

🤔 Which of your controls still needs a human to decide whether an event is benign, and what would it take to make that one binary?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast