Saturday, July 25, 2026

What is a Vector Database?

Vector Databases: Where They Actually Earn Their Keep

You can bolt a vector approach onto your relational database as you implement AI use cases in your organizational environments.

With a new database type showing up every few years, it has become common for half of any conference session on that new type to be spent redefining the term for a new audience. Right now vector databases are having their time in the sun, and everybody seems to need one for their RAG pilot or their AI-assisted service in the enterprise. Below the level of the slides and the conference talks, though, vector databases are not terribly complicated. An embedding model turns input data — text, images, support tickets — into a vector of numbers. Those vectors get stored. At query time, you embed the query the same way and search the stored vectors for the ones closest in meaning.

What it actually is

So first off, let me define it. A vector database is a database where you store vectors in a high-dimensional space — think 50, 100, 1,000 dimensions or more — and where you can query for the vectors most similar to a given vector in that space. There are broadly two strategies for getting data into that space: single-shot approaches, where an entire item is mapped to one vector, and chunking approaches, where the data is split into pieces and each piece is embedded separately.

In terms of suitability, vector databases fit retrieval problems where many items in a dataset are all somewhat like one given item. They are a poor fit for problems where you need to find the single row matching an exact set of criteria. That second category is what relational databases have always been good at. Postgres is very well suited to finding one specific piece of data given criteria that match on every field — think where user_id = 4471. That is in sharp contrast to what a vector database does, which is to hand you back the twenty items most similar to a given item.

Both kinds of system sit on top of storage engineered for a high volume of lookups, so in that sense they are cousins. The difference is in how the lookup happens. A relational database evaluates a set of criteria against the fields of each candidate row to determine a match. A vector database compares a query vector against the stored vectors — all of them, or more often a subset — using a distance metric, and returns the closest ones. Which metric you use depends on the nature of the data, but cosine similarity and Euclidean distance are the usual suspects.

Most vector databases use approximate nearest neighbor (ANN) indexes, such as HNSW or IVF, to make the search efficient. The primary trade-off with these indexes is precision against performance: the index may return vectors that are slightly less similar than the true nearest neighbors in exchange for returning them much faster. At very large scale — hundreds of millions or billions of vectors — even a small amount of additional retrieval time makes a real difference, so giving up a little accuracy is often an acceptable price for a real-time interactive application.

Where the engineering complexity actually lives

I think the biggest misperception about the engineering required for vector databases is that the hard part is the storage. It isn't. It's the indexing. There are a number of approaches, each with its own trade-offs, and a great deal of engineering goes into wringing performance out of them.

HNSW (Hierarchical Navigable Small World). Builds a multi-layer graph in which each vector is connected to its neighbors. A search starts in the coarse upper layers and descends into progressively finer ones. It is very fast and, for many applications, very accurate — which is why it is the default index in a lot of vector databases handling real-time interactive workloads.

IVF (Inverted File Index). Organizes all the vectors into partitions — buckets or clusters — centered on a set of centroids. At query time, you identify the clusters of interest and only traverse the vectors inside them. You give up some precision for a given recall target in exchange for speed. At very large scale (100M to 1B+ vectors), narrowing to a subset before running the similarity search is frequently the only remaining lever you have. IVF variants differ in how they structure partitions and how they select centroids, which is what lets the approach cover a lot of different use cases.

Product quantization. Compresses the stored vectors to reduce memory footprint and to cut the number of operations needed for each distance computation. It is very often paired with IVF — IVF-PQ — as the retrieval strategy for huge datasets.

Flat, brute-force scan. The simplest method of all: no index, just compare against everything. Worth remembering that brute force is exact — it never returns a wrong answer; it just gets slow. That makes it the right call more often than people assume, for small collections or anywhere exact results genuinely matter more than latency.

None of these is better than the others in any absolute sense. Each represents an engineering trade-off between latency, recall, and memory for a specific use case. Saying HNSW is the best index for every problem is about as sound as saying every workload belongs on the fastest disk tier.

Where retrieval quality actually comes from

Here's the core of the problem, and I'll defend it: the index is not what's failing your RAG system. The chunking and embedding strategy is.

The quality of the index depends entirely on the quality of what went into it — chunks of a document, embedded into a vector space by an embedding model. At retrieval time, the same model has to embed the query so the two can be compared. If the model that indexed the corpus and the model that embeds the queries are not the same model, you are comparing coordinates from two different spaces that happen to have the same number of dimensions. The similarity scores that come back will look perfectly reasonable and mean absolutely nothing. Swapping embedding models mid-project causes a great deal of pain for exactly this reason.

Two things I've seen bite teams repeatedly:

Naive token splitting underperforms semantic splitting. Cutting every N tokens regardless of structure produces chunks that straddle two unrelated ideas. Split on paragraphs, headings, or logical sections instead.
Embed consistently. Use the same model for your corpus and your queries. Embedding models are defined in terms of a coordinate space, and two models with the same dimensionality are not defined in the same coordinate space. Swapping one for the other is switching to an entirely different space, and retrieval breaks completely — silently.

It is also very useful to store metadata alongside the vectors: source, date, tags, owner, department. That metadata is what lets you filter candidates out before the similarity search runs, or filter results after it returns. A lot of teams realize too late that retrieval is the part that matters, and that a nice demo can hide an enormous number of problems.

Security, or why retrieval carries a false sense of safety

This is the part of the architecture everybody wants to skip, because storing derived numbers feels safer than storing sensitive text. It isn't. As I alluded to above, it is often possible to reconstruct or infer meaningful information about the original input from the embedding itself, particularly when the model is known.

So treat the vector store with the same rigor you would apply to any production database holding regulated data. That means access controls, tenant isolation, encryption at rest and in transit, and deliberate logging discipline around both query vectors and retrieved results — the queries themselves are a sensitive signal, not just the documents. Enforce metadata filtering before retrieval rather than bolting it on afterward. And in a regulated environment, keeping the whole retrieval layer inside your own VPC is usually the difference between a straightforward compliance conversation and a painful one.

Where this shows up in practice

The dominant use case at the moment is supporting a generation model: embed a large corpus, store the vectors, retrieve the relevant chunks for each query, and pass them to the model as additional context. But it doesn't stop at semantic search — the same mechanics power recommendation, anomaly detection, and deduplication. Here is how this tends to land in three domains I get asked about often enough to be worth spelling out.

Higher education. For a university's AI advising assistant to be useful to students and staff, it has to retrieve across financial aid policy, degree requirements, and course catalogs from every department. Financial aid policy changes year over year and by cohort, and it varies with in-state or out-of-state status, scholarships, and professional programs. So chunk that content by policy section and effective date rather than by PDF page break, or you will confidently serve a 2019 refund policy in answer to a 2026 question. The access control point from the previous section is not theoretical here either: a student must not have a path, even an indirect one, to another student’s advising notes or FERPA-protected records simply because their embeddings landed near each other in the vector space. Filtering by student ID and role before the similarity search runs is what keeps this a retrieval system rather than an incident report.

Finance. Research desks and trading floors accumulate documents continuously — vendor research, internal risk memos, filings — over long periods, with vendors added and dropped along the way. Two failure modes show up here reliably. The first is the model swap: a collection is built with one embedding model, someone later substitutes a comparable one, and answer quality quietly collapses while the similarity scores continue to look flawless. The second is staleness. Without collection-level metadata — when a document entered the corpus, how many revisions it has been through, whether it has been superseded — an analyst will eventually get handed a three-year-old note with no indication that it no longer reflects the house view. Filtering on that metadata before retrieval is the fix. And logging discipline matters twice over in this domain, because query vectors over trading strategy documents and client portfolio data are themselves sensitive.

Healthcare. Consider semantic search over clinical notes and discharge summaries for a clinician-facing assistant. Clinical narrative is exactly the kind of narrow, structured, sensitive text where reconstruction risk against embeddings is highest, so PHI-bearing vectors belong behind the same authentication and audit controls as the EHR itself — not a lighter-weight index sitting alongside it. On the retrieval side, chunking by clinical encounter and tagging each note with department and note type (history and physical, progress note, consult) is what keeps a nurse's query about a medication history from surfacing that patient's psychiatric notes. That is as much a chunking and metadata design decision as it is a policy one.

The Takeaway

A vector database is more than a search index bolted on top of your stack. It is part of your data layer, and it deserves the same rigor you would give any production system holding data your organization is accountable for. The indexing algorithm is the interesting part, but the chunking strategy is the part that decides whether retrieval is any good, and the access controls on the retrieval layer matter every bit as much as the ones on the rest of your data layer. Get the interesting part right and skip the other two, and you will have built something fast, confident, and wrong.

Dr. Sam Kurien

The Quietest Thing an Attacker Does After Root

Privilege escalation gets all the attention. It's the dramatic beat in every write-up — the moment the shell prompt flips from $ to # and the attacker owns the box. But in my experience, escalation is rarely the point. It's the ticket. What the attacker does with that ticket in the next ninety seconds tells you far more about their intent, and it's usually the thing that leaves the evidence you'll actually use later.

So let me pick the one action I find most instructive to reason about: installing a persistence mechanism. Specifically, a malicious systemd service on Linux. It's unglamorous, it's common, and — this is the part I want to sit with — it's a control the defender can win, if they understand what they're really watching.

What the attacker gains

The honest answer is time. Everything else follows from that.

An exploit is fragile. It depends on a vulnerable version, a reachable service, a particular condition holding true. Patch the service and the door closes. This is exactly what I saw in this week's lab work chaining CVE-2025-32433 — the exploit is a beautiful thing until the target gets updated, and then it's a museum piece. An attacker who has done any real work to get to root is not going to leave their continued access hostage to a CVE that could be remediated on Tuesday.

Persistence decouples access from the vulnerability. A systemd service that calls back on a schedule survives reboots, survives the patch, and survives the analyst who thinks closing the original hole ended the incident. That last one matters more than people admit. I have watched remediation efforts declare victory on the entry vector while the persistence quietly sat one directory over, waiting. The attacker's goal isn't a shell today; it's a shell next month, on their terms, after everyone has stopped looking.

Systemd in particular is an attractive home because it's legitimate infrastructure. A rogue .service unit dropped into /etc/systemd/system/ with an innocuous name blends into a directory full of things administrators are conditioned to trust. Enable it with systemctl enable, and the OS itself becomes the thing that maintains the attacker's foothold. That's the uncomfortable elegance of it — you're not fighting malware anymore, you're fighting the service manager doing its job.

What it leaves behind

Here's my core claim, and I'll defend it: persistence is loud if you know where to listen, and the attacker's need for reliability is what makes it loud.

Reliability requires artifacts. A callback that has to survive a reboot must be registered somewhere durable. That durability is the tell. You cannot have persistence that is both reboot-surviving and evidence-free, because the mechanism that survives the reboot is, by definition, written down somewhere the system reads on boot.

For a malicious systemd service, that "somewhere" is a short list:

A new or modified unit file, typically under /etc/systemd/system/ or /usr/lib/systemd/system/, with a creation or modification timestamp that rarely matches any change window you can account for.
The payload itself — an executable or script, often parked in a world-writable path like /tmp, /var/tmp, or /dev/shm, or masquerading in /usr/local/bin.
Journald entries showing the unit being enabled and started, which is the service manager narrating the attacker's actions in its own logs.
The behavioral signature at runtime: a process spawned by systemd (PID 1 lineage) that promptly opens an outbound socket to a host that has no business being contacted from that server.

None of these is subtle once you've decided to look. The problem is almost never that the evidence is absent. The problem is that nobody correlated the file with the process with the connection.

How a defender detects and investigates

If I could give a defender one piece of advice here, it would be this: stop watching for "a bad file" and start watching for "a change to how this host schedules and runs code." That reframe is what makes the detection durable against an attacker who has read the same hardening guides you have.

Concretely, in order of what I'd reach for first:

File integrity monitoring on the systemd unit directories is table stakes, but on its own it only tells you a file appeared. Pair it with auditd rules that watch those same directories and record execve calls, so you catch not just the unit file being written but the payload actually running. FIM tells you the trap was set; auditd tells you it sprang.

Then correlate on lineage and behavior. A process whose parent traces back to systemd, launched from/tmp, opening an outbound connection, is a specific and huntable pattern. I care much more about that causal chain — scheduler spawns unusual binary, binary calls home — than about any single indicator in isolation. It's the combination that turns a maybe into a finding without waiting on reverse engineering.

For the investigation itself, the questions I'd want answered are the boring, useful ones. When was the unit file created, and by which subject’s session? Correlate that timestamp back to the authentication and process records around it — the same logon-session pivot I'd use for account-creation cases applies here. Has the service fired more than once? Journald and execve records give you every invocation, which bounds how long the persistence has actually been live and therefore how far back your scope has to reach. And critically: does the entry vector's remediation actually touch this? If not, you haven't closed the incident. You've closed a door in a house with an open window.

The takeaway

Privilege escalation is the headline, but persistence is where the investigation is usually won or lost. The attacker installs it because they need reliability, and that same need for reliability forces them to write something durable to disk and register it with the system — which is precisely the evidence a prepared defender is watching for. The mechanism that keeps them in is the mechanism that gives them away.

Watch the scheduler, not just the file. Correlate the artifact to the execution to the connection. And never let anyone declare an incident closed on the strength of a patch alone.

Saturday, July 18, 2026

Privilege, Not Passwords: Where the Real Risk Lives

I wrote this for a class post and thought it was worth capturing here as well, both to share and for my own future documentation of where I landed on this.

I've been following a debate that keeps resurfacing — in our own classroom, in vendor briefings, and in boardrooms alike: which is the bigger security problem, weak passwords or weak privilege management? Most people settle firmly into one of two camps. Having spent more than one season of my career building and contributing to an identity management product, I'd like to try bridging the gap — though I'll confess up front that I've already picked a side. Privilege is the bigger governance and management problem, and it deserves the stronger focus. Let me explain.

Password vulnerability is a real problem, but the initial breach of an organization's systems through a login is, at this point, close to inevitable. Most large breaches begin with adversary-in-the-middle (AitM) phishing that bypasses MFA, or with infostealer malware quietly harvesting credentials by the thousands. And service accounts, by their nature, cannot use MFA at all. So under an assume-breach mindset, the decisive question is not whether an account will be compromised, but what that account can then access. A typical user account can be contained as an incident. An over-privileged identity is something else entirely: an attacker can escalate from it, disable security tooling, move laterally across the network, and establish the command-and-control foothold that turns a phishing click into a ransomware event. The privilege granted to the initially compromised identity determines the blast radius of the incident.

Meanwhile, the password problem is slowly solving itself, for the most part. NIST's recently finalized SP 800-63B-4 (National Institute of Standards and Technology [NIST], 2025) decisively shifts password guidance toward length, breached-credential screening, and phishing-resistant authentication. I've written before about my enthusiasm for moving toward passwordless login using passkeys and methods such as FIDO2 — eliminating the shared secret that attackers phish, spray, and stuff. But notice what a passwordless world leaves behind. Entitlements will still pile up on individual accounts. Accounts belonging to former employees will still be abandoned rather than deprovisioned. Admin rights needed for a two-week project will still be found, years later, quietly attached to someone's identity. A password policy, once set correctly, largely holds its value. A privilege model erodes daily unless it is actively managed and governed.

That is why I consider identity management and zero trust not to be two separate security solutions, but two components of a complete, layered defense. Zscaler seems to have solved a good deal of this (I have nothing to do with Zscaler, and I am not promoting them here). In a zero trust architecture, no user, device, or network location is implicitly trusted, and every request must be verified (Rose et al., 2020) — meaning that when another control fails, identity is the layer that bears the brunt of the damage. In practice, I am a strong believer in combining Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). RBAC is the right starting point: map users to the roles their jobs actually require, and audit regularly to ensure every entitlement is accounted for. But roles are static by nature. ABAC adds the dynamic layer — factoring in the posture of the user's device, the location they're connecting from, and the classification of the data they're trying to reach. Combined, the two produce an access model that is both auditable and adaptive: what a user can access changes with circumstances, rather than sitting as a standing entitlement waiting to be abused.

One note I feel strongly about: the road to passwordless runs through strong passwords. Until the transition is complete, the credentials we still depend on must be hardened — going passwordless doesn't excuse weak passwords in the meantime; it depends on surviving the meantime.

A stolen credential gets an intruder into the lobby. Unmanaged privilege is what escorts that identity down to the server room or the boardroom, where everything that matters is kept. So harden the entrance — then govern everything beyond it.

References

National Institute of Standards and Technology. (2025). Digital identity guidelines: Authentication and authenticator management (Special Publication 800-63B-4). https://doi.org/10.6028/NIST.SP.800-63B-4

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Your University's AI Strategy Shouldn't Look Like Anyone Else's

I've been deep in the architecture of my next book — an AI playbook for higher education — and I keep bumping into a problem that most of the "AI will transform the university" content quietly ignores: which university?

Because here's the thing nobody at the conference keynote wants to say out loud. A flagship R1 with a medical school, a regional state comprehensive, a 900-student faith-based college, and a system office are not four sizes of the same institution. They're four different organisms wearing the same word, "university," and handing them the same AI strategy is like handing a powerlifter, a marathoner, and a guy recovering from knee surgery the same workout plan. Technically, it's all exercise.

So one of the chapters I'm building is devoted entirely to this, and the more I work on it, the more I think it's the load-bearing wall of the whole book. The premise: institutional type isn't a demographic footnote. It determines your core AI problem — the thing that will actually eat you if you ignore it.

At an R1, the core problem is coordination. AI is already everywhere on that campus — the engineering college has three pilots, the med school signed something nobody in central IT has seen, and forty faculty have quietly wired models into their research workflows. The flagship doesn't need an AI adoption strategy; it needs an AI governance strategy, and a federated one at that, because the colleges of medicine, engineering, and law will run their own portfolios no matter what the provost's council decides. Central's real job is setting the floor — data protection, disclosure, human decision rights — and auditing against it. Not approving projects. That ship sailed before the committee formed.

At a regional comprehensive, the problem flips. It's capacity. These are the institutions that need AI's efficiency gains the most — advising caseloads north of 300:1, a financial aid office running on caffeine and heroics — and they have the least staff to implement anything. The cruel joke of this moment is that the institutions with the strongest per-dollar case for AI are the ones least equipped to deploy it. (This, incidentally, is the thesis of the whole book: higher ed needs AI most at exactly the moment it's least ready for it.)

At a small private, the problem is readiness. The data spine — the SIS, the CRM, the warehouse — is often held together with spreadsheets and institutional memory named Deborah. The upside is that a small private's cabinet can move in one board cycle, no faculty senate marathon required. The downside is identical: it can err in one board cycle. Speed without a data foundation just gets you to the wrong place faster.

And at a system office, the problem is authority: what gets decided centrally, what stays on campus, and who pays. Anyone who's watched a system-wide ERP project knows this fight. AI just runs it at higher velocity.

Two wrinkles from the research so far that deserve their own paragraphs, because almost nobody in the sector is talking about them.

First: if you're a public institution, your AI policy isn't entirely yours to write. A growing number of states have issued executive orders or legislation governing AI use in public agencies, and public universities are frequently in scope. Your regional comprehensive may already have obligations flowing downhill from the governor's office that your cabinet has never read.

Second, and this is the one that made me sit back from the keyboard: sunshine laws reach algorithms. A public university's AI-influenced admissions or financial aid decisions are potentially discoverable — public records requests, litigation — in ways a private institution's never will be. If a model is nudging who gets admitted or how aid is packaged at a state school, assume that someday a reporter or a plaintiff's attorney will get to look under the hood. That should change how you write vendor contracts and how you build audit trails, starting now, not after the request lands.

The chapter ends with a diagnostic — place your institution on the grid, then every subsequent chapter of the book closes with a "how this plays for you" note keyed to your archetype. Because a playbook that pretends the whole sector runs the same offense isn't a playbook. It's a poster.

More as the book develops. If you lead technology at one of these four kinds of institutions and your AI reality doesn't match my grid, I genuinely want to hear about it — the grid gets better when it gets argued with. I think it would be a good idea to run a summary of all my chapters here and get genuine discussion going to reflect on and validate my ideas.

Dr. Sam Kurien

Wednesday, March 25, 2026

DarkSword and Zero Trust Reckoning

Threat Intelligence & Mobile Security

DarkSword and the Zero Trust Reckoning

The Collapse of iOS Inviolability — and Why Software Hygiene Is Now a Survival Metric for Institutions

For the better part of a decade, the default posture of any IT leader recommending a mobile device strategy was predictable: hand the executive an iPhone and call it a day. The logic was almost bulletproof. Apple's vertically integrated stack — hardware, OS, and App Store gatekeeping — gave the walled garden metaphor genuine teeth. While Android's fragmented patch ecosystem left enterprise security teams running perpetual triage, iOS was the closer-to-settled question.

I've used that framing in vendor conversations. I've built a mobile policy around it. And now, with the emergence of DarkSword, I find myself revisiting every assumption underneath it.

This is not alarmism. This is what the intelligence looks like from the ground — and what it demands of leaders who sit at the intersection of institutional trust and operational technology.

⚠ Threat Classification

DarkSword is a sophisticated zero-click exploitation framework documented by Google's Threat Analysis Group (TAG), Lookout, and iVerify. It operates via watering-hole attacks — compromised legitimate-looking web properties — to achieve remote code execution (RCE) through the WebKit engine without any intentional user interaction. It does not require a malicious app download. It does not require clicking a phishing link. It requires only that a device browse to an infected site. [See TAG advisory and corresponding CVE disclosures for technical attribution]

The Architecture of Compromise

What distinguishes DarkSword from the commodity malware cluttering most threat briefings is architectural intentionality. This toolkit was not built to linger. It was built for surgical, deniable exfiltration — a design philosophy more consistent with state-sponsored tradecraft than with the opportunistic criminal ecosystem.

The exploit chain targets WebKit — the rendering engine that powers every browser on iOS without exception, a direct consequence of Apple's platform policy requiring all third-party browsers to use WebKit. By exploiting a series of memory-corruption vulnerabilities in the WebKit JIT compiler, DarkSword achieves privileged code execution, escapes the application sandbox, and moves laterally into core system processes. From that position, the data exposure is comprehensive:

iCloud Authentication Tokens

Token capture enables access to cloud backups without triggering standard 2FA workflows. This is not a brute-force attack — it is a session hijack that appears to be a legitimate authenticated session from Apple's perspective.

End-to-End Encrypted Message Content

Encryption protects data in transit. DarkSword accesses data at the endpoint — after decryption — rendering transport-layer security architecturally irrelevant to this attack vector. iMessage, Signal, WhatsApp: the message content is readable at the device layer before any encryption is applied or after it is removed.

Keychain Access

For institutional users, this is the catastrophic tier. Corporate SSO credentials, VPN certificates, privileged access tokens, and — for any cryptocurrency-adjacent users — private keys. A compromised Keychain is a compromised identity, potentially enterprise-wide.

The initial geographic targeting — Saudi Arabia, Turkey, Malaysia, and Ukraine — is consistent with intelligence-service interest patterns. But that window has closed. The toolkit has surfaced on GitHub. We have entered what I would call the democratization phase of cyber-espionage: sophisticated zero-day weaponry, previously accessible only to nation-state actors with eight-figure operational budgets, is now available to script-tier threat actors and regional criminal cartels.

This is the threat multiplier that should concern every institutional technology leader. The original adversary was disciplined and selective. The downstream actors running forked GitHub deployments will not be.

The One-Fifth Vulnerability Gap

Apple has moved with unusual speed. Patches were issued in iOS 26.3 and the subsequent iOS 26.3.1(a), specifically addressing the WebKit JIT vulnerabilities in the exploit chain. Rapid Security Response (RSR) patches were also pushed for select configurations. From a vendor posture standpoint, Apple's response was close to the industry ceiling of what we can reasonably ask for.

~20%of the iOS install base is still running unpatched versions —
trailing iOS 18.4 through 18.7 — as of current estimates

That gap is not a technology failure. It is a human-systems failure — and, in an institutional context, a governance failure.

Consider what that 20% means in practice. Automated vulnerability scanners — the same category of tool that pen testers use — can identify unpatched WebKit targets at scale. A device running iOS 18.x does not need to be specifically targeted; it simply needs to be found. In a world of exploit automation, being three minor versions behind is not a risk posture — it is an open enrollment in the breach pipeline.

The Hardened Institutional Posture

The following is not a "best practices" checklist. It is the minimum viable defensive architecture for any leader responsible for sensitive institutional data — financial records, student information, executive communications, privileged credentials. The bar has moved. Adjust accordingly.

Eliminate the Update Lag — Immediately and Institutionally

The 48-to-72-hour window between patch release and device update is the primary operational window that exploit actors bank on. On the individual level, enable:

Settings → General → Software Update → Automatic Updates

Toggle both "iOS Updates" and "Security Responses & System Files" to ON. The latter enables Apple's Rapid Security Response mechanism, which pushes critical patches outside the standard update cycle.

On the institutional level: if your MDM (Jamf, Intune, Kandji) does not have an enforced OS version policy with an update compliance threshold, that gap needs to close in your next governance cycle — not next quarter. Define an acceptable lag window (72 hours for critical patches is a defensible standard) and enforce it through device enrollment policy.

Deploy Lockdown Mode for High-Risk Personnel and Environments

Standard iOS hardening is insufficient for DarkSword-class threats because the attack surface — WebKit JIT compilation — is not addressable through configuration alone. Apple's Lockdown Mode structurally disables the JIT compiler pathways and reduces the JavaScript attack surface upon which the exploit chain depends.

Settings → Privacy & Security → Lockdown Mode

Lockdown Mode carries real usability tradeoffs: certain web technologies are disabled, some file attachments won't open, and complex web apps degrade in performance. This is not a fleet-wide recommendation. It is the appropriate posture for executives, finance personnel, IT administrators, and anyone who regularly accesses privileged systems from mobile devices — particularly when traveling or connecting outside your perimeter controls.

Treat Mobile Browsing as a Hostile Environment

DarkSword's use of watering hole attacks — lookalike portals impersonating government contractor sites, enterprise SaaS login pages, and consumer tools like Snapchat — challenges the comfortable assumption that users can identify unsafe sites by appearance or reputation. DarkSword doesn't need you to download a file. It just needs you to view a page. That single fact should reframe how your entire organization thinks about mobile browsing.

The smishing vector deserves specific attention. A well-crafted SMS instructing a user to "verify your account" at what appears to be a legitimate government portal or enterprise login page is all DarkSword needs as a delivery mechanism. Train your users on one absolute rule: if a link arrives via SMS, social media DM, or personal email and it asks you to log into anything, do not click it. Type the address manually into the browser or navigate through a trusted password manager that provides domain verification.

On the institutional side, sensitive web navigation should happen through corporate-managed browser profiles with DNS filtering and Safe Browsing enforcement active. On mobile, this discipline is harder to enforce than on managed desktops, which is precisely why it must be a trained behavior and a user awareness priority — not an assumed one.

Treat Hardware Deprecation as a Security Policy Decision

This is the conversation institutional technology leaders consistently defer because it carries budget implications. DarkSword forces the issue. Devices that cannot run iOS 26 do not have access to the hardware-level exploit mitigations built into recent A-series silicon — specifically, Pointer Authentication Codes (PAC) and the memory-tagging improvements in more recent SoC generations that make modern exploits structurally harder to write.

To be concrete: an iPhone 8, iPhone X, or anything older cannot run the security architecture required to resist this class of exploit. These devices are not merely feature-limited — they are mathematically easier to exploit. The cryptographic and memory-isolation primitives simply aren't present in the hardware. An iPhone maxing out at iOS 15 or 16 is not a legacy device. It is a structurally undefendable endpoint.

If your organization has device refresh policies that allow five-plus-year-old mobile hardware to access institutional systems, that policy is now a liability exposure, not a cost-saving measure. Frame it that way in your next budget conversation.

Conduct an Emergency Institutional Audit — Today

This is the step most organizations skip, and the one with the most immediate risk-reduction value. Through your MDM console, pull a current OS version compliance report for every enrolled mobile device. Identify every device running iOS 18.x or earlier. Flag them. Communicate directly with those users. Do not wait for the next scheduled IT communication cycle.

If your mobile fleet is partially or entirely unmanaged — BYOD with no MDM enrollment — you need to initiate a more fundamental governance conversation. Start by quantifying the exposure you currently cannot see.

Monitor for Enclave Anomalies — Know the Behavioral Signatures

DarkSword is engineered to be stealthy — it does not announce itself with popup alerts or obvious system crashes. But even surgical exfiltration leaves traces. Active data transmission is power-intensive, and exfiltration operations that run while a device is idle create observable behavioral artifacts. Knowing what to look for is part of a mature defensive posture.

Train your security-aware users — and particularly your high-risk personnel — to treat the following as potential indicators of a compromised environment that warrant immediate device isolation and incident response:

Unexplained battery drain or device overheating while idle. Background exfiltration consumes CPU and radio resources. A device that runs warm or drains noticeably faster when not in active use is worth investigating.
Unsolicited prompts for iCloud password or Keychain access. A legitimate app or OS update will not ask for Keychain credentials out of context. An unexpected prompt — especially one that appears unprompted while browsing — should be treated as hostile.
Unknown profiles in Settings → General → VPN & Device Management. This is the first place to look on any suspected device. A configuration profile installed without user knowledge is a reliable indicator of device compromise. Check this regularly on any device handling sensitive institutional data.

If any combination of the above appears, the correct response is not to dismiss it and monitor further — it is to remove the device from institutional network access, escalate to your security team, and treat it as a confirmed incident until forensic analysis says otherwise.

DarkSword is not a singular event to be patched and forgotten. It is a leading indicator of a structural shift in the mobile threat landscape — one that has been visible to security researchers for years and is now arriving as operational reality for institutional technology leaders.

The Zero Trust architecture principle — never trust, always verify, assume breach — was designed for exactly this threat profile. We have applied it reasonably well to network perimeters and identity management. We have applied it inadequately to mobile endpoints, largely because the "walled garden" narrative gave us permission to treat iOS as a trusted device by default.

That permission has been revoked.

Apple will continue writing patches. The adversary ecosystem will continue developing exploit chains. The variable that determines institutional outcomes in that arms race is not vendor response time — it is the culture of security discipline you build inside your organization. Update cycles enforced. Hardware policies rationalized. User behavior is shaped by training that reflects actual threat patterns rather than the last decade's phishing examples.

The 20% who aren't updating aren't negligent. They are people operating in an environment where security discipline has not been made structurally easy, institutionally expected, or consequently enforced. That is a leadership problem. Which means it is, for those of us in technology leadership roles, our problem to solve.

Don't be the institution that finds out, the hard way, that it was in the vulnerable 20%.

Quick-Reference: DarkSword Defense Checklist

Enable Automatic Updates, including Security Responses & System Files
Enable Lockdown Mode for executives, admins, and finance personnel
Never click login links from SMS, DMs, or personal email — type URLs manually
If on an iPhone 8, X, or older — plan an immediate hardware upgrade
Pull MDM compliance report; flag and contact all iOS 18.x or earlier devices
Audit Settings → General → VPN & Device Management for unknown profiles
Report idle overheating, battery drain, or unexpected Keychain prompts to IT immediately

Source Note: The DarkSword threat intelligence referenced in this article is attributed to Google's Threat Analysis Group (TAG), Lookout, and iVerify. Readers in institutional security roles are encouraged to refer directly to the original CVE disclosures and TAG advisory documents for full technical attribution. As with all active threat intelligence, the landscape evolves rapidly — verify current patch status against Apple's official security release notes at support.apple.com/en-us/111900 or the equivalent current advisory page.

Sunday, March 22, 2026

Heracles and the FHE Hardware Race — Computing on Data You Never Decrypt

What Intel's new chip means for the future of privacy-preserving computation

I have been tracking fully homomorphic encryption for a while now — mostly as a theoretical boundary condition in my privacy-enhancing technologies research. The math has always been elegant. The performance has always been the problem. When a cryptographic operation takes tens of thousands of times longer than its plaintext equivalent, it lives in academic papers, not production systems.

That calculus is starting to shift. And the signal worth paying attention to right now is a chip called Heracles.

The Problem FHE Has Always Had

Let me frame the core issue for practitioners who haven't delved deeply into this.

Fully homomorphic encryption is, at its conceptual heart, a way to perform arbitrary computations on encrypted data without ever decrypting it. The server doing the computation never sees the plaintext. The result is returned encrypted, and only the party holding the key can read it. For anyone building systems that handle sensitive data — medical records, financial transactions, genomic information, private AI queries — this is the Holy Grail of privacy architecture. You get the computing power of the cloud without handing your data to the cloud in the clear.

The catch has always been performance. FHE is computationally brutal. The encrypted data grows by orders of magnitude compared to the original plaintext. The operations required — polynomial transforms, a noise-cancelling process called bootstrapping, and some genuinely odd-named operations like "twiddling" and "automorphism" — are deeply inefficient on general-purpose CPUs. A CPU can do it, but slowly, burning roughly 10,000 more clock cycles for integer operations than it would on unencrypted data. GPUs excel at parallel computation but sacrifice the precision FHE demands. Nobody has yet built hardware that's actually right-shaped for this workload.

Until now, possibly.

What Intel Just Demonstrated

Last month at the IEEE International Solid-State Circuits Conference in San Francisco, Intel demonstrated

Heracles — a purpose-built FHE accelerator that has been under development for 5 years as part of a DARPA program. The headline numbers are striking enough to take seriously.

Compared to a top-of-the-line Intel Xeon server CPU, Heracles achieved speedups ranging from 1,074 to 5,547 times across seven key FHE operations. On the specific benchmark Intel ran publicly — a private voter ballot verification query against an encrypted database — the Xeon took 15 milliseconds. Heracles did it in 14 microseconds. For a single query, that difference is imperceptible. At 100 million queries, you are looking at more than 17 days of CPU work versus 23 minutes on Heracles.

The demo itself is worth understanding because it illustrates exactly why FHE matters for real institutional use cases. A voter wants to confirm her ballot was recorded correctly. The government holds an encrypted database of voters and votes. Using FHE, the voter encrypts her own ID and ballot choice on her end and sends the encrypted query to the server. The server determines whether it matches the encrypted database using the encrypted query — without ever decrypting either. It returns an encrypted result. The voter decrypts it on her side. At no point does the government's computation infrastructure see either the voter's identity or her ballot in plaintext.

That is a meaningful security architecture. And until very recently, it was practically unusable at scale.

What Makes Heracles Different

Heracles is not a tweak to existing silicon. It is a ground-up rethinking of what an FHE workload actually needs.

At its physical core, the chip is built on Intel's most advanced 3-nanometer FinFET process — the same technology Intel uses for its best products — and measures roughly 200 square millimeters, about 20 times larger than competing FHE research chips. It is flanked in a liquid-cooled package by two 24-gigabyte high-bandwidth memory chips, a configuration you normally see only in AI training GPUs. That memory decision is telling: the data explosion problem in FHE is as much about bandwidth as it is about compute, and Intel has treated it accordingly, pairing 819 GB-per-second memory connections with 9.6 terabytes-per-second on-chip data movement.

The compute architecture centers on 64 SIMD cores — called tile-pairs — arranged in an 8x8 grid, connected by a 2D mesh network with 512-byte buses. These cores are purpose-built to run the polynomial arithmetic and transform operations required by FHE, performing them in parallel rather than serially. The chip runs three synchronized instruction streams simultaneously: one managing data into and off the processor, one managing internal data movement, and one running the arithmetic. This is the kind of design discipline that comes from five years of focused engineering on a single problem.

One architectural bet made early in the Heracles project deserves attention. The team chose to work in 32-bit arithmetic chunks rather than 64-bit, even though FHE requires much larger numbers. This seems counterintuitive — FHE demands precision on very large integers — but by breaking those large numbers into 32-bit pieces that can be computed independently, they gained significant parallelism. The 32-bit circuits are physically smaller, fit more of them on the die, and can run simultaneously. It was a risky design call that appears to have paid off.

The Competitive Landscape

Intel is not alone in this race, and the ecosystem developing around FHE hardware is worth watching closely.

Duality Technology, an FHE software firm whose CTO, Kurt Rohloff, described the Heracles results as "very good work," was part of a competing accelerator team in the same DARPA program. Duality's position is instructive: they are focused less on new hardware and more on software products for the kinds of encrypted queries Intel demonstrated. Rohloff's view is that at current scales, software is sufficient — specialized hardware becomes necessary as workloads shift toward deeper machine learning operations such as neural networks, LLMs, and semantic search.

Niobium Microsystems, a chip startup spun out of another DARPA competitor, is positioning itself as "the world's first commercially viable FHE accelerator." It recently announced a deal worth approximately $6.9 million with Seoul-based chip design firm Semifive to develop its FHE accelerator for fabrication on Samsung's 8-nanometer process. Intel has not yet announced commercial availability plans for Heracles, which gives Niobium an interesting window.

Other players — Fabric Cryptography, Cornami, and Optalysys — are building their own approaches. The most technically distinct is Optalysys, whose CEO Nick New argues that Heracles represents roughly the ceiling of what a fully digital approach can achieve. Optalysys is using photonic chips to perform FHE's compute-intensive transform steps using the physics of light rather than digital logic. Their photonic chip is on its seventh generation, and they are working toward a 3D-integrated commercial product — photonic chip for the transforms, custom silicon for the rest — potentially ready in two to three years. If that works, it would push performance well beyond what any digital accelerator can achieve.

What This Means for AI and Sensitive Data Workloads

Here is where this gets immediately relevant to the work I do at the intersection of AI governance and privacy architecture.

The scenarios that FHE hardware makes practical for the first time are exactly the ones that have been architecturally stuck. Federated learning, where contributors cannot trust the aggregation layer. Inference on private user data where neither the query nor the model weights should be visible to the infrastructure. Encrypted database search where even the server processing the query cannot see what was asked or what was found.

Duality's demonstration of an FHE-encrypted transformer model — a smaller-scale version of BERT — points toward the trajectory. Today it works on compact models. As hardware improves, the model size that FHE can accommodate in a reasonable time scales up with it. The end state, which feels meaningfully closer than it did twelve months ago, is AI inference that is provably private: the model provider cannot see your query, and you cannot extract the model weights. That is a different trust model than anything we have today with cloud AI APIs.

John Barrus at Niobium put it plainly: "There are a lot of smaller models that, even with FHE's data expansion, will run just fine on accelerated hardware." I believe him. And as someone who has spent the past year deep in agentic AI risk research, I find the prospect of AI agents operating on encrypted data without ever seeing plaintext personally significant. It changes what is possible in high-sensitivity deployment environments.

My Read on Where This Is Heading

Sanu Mathew, who leads security circuits research at Intel, described Heracles as "like the first microprocessor — the start of a whole journey." That framing is either marketing or genuine conviction, and in this case, I think it is the latter.

FHE has been a "maybe someday" technology for long enough that healthy skepticism is warranted. But the confluence of DARPA investment, Intel's 3nm engineering resources, multiple serious startups with real capital, and a photonics approach that could push past digital limits — this is not the same landscape as five years ago. The hardware is catching up to the math.

For practitioners building privacy architectures today, I would hold the following positions. Confidential computing with TEEs remains the most immediately deployable option for protecting data in use — its operational maturity and cloud provider support are in place, and the performance overhead is manageable. FHE hardware is the one to watch for workloads where you cannot trust the compute environment, even with hardware attestation, where the encryption must hold even against a fully compromised host. That scenario is rarer but more demanding, and it now has a credible hardware roadmap.

The combination of TEE-based confidential computing for near-term deployments and FHE hardware for the most trust-hostile environments represents, in my view, the serious privacy architecture stack for the next decade. Both are moving faster than most security teams realize.

Keep watching this space.

Confidential Computing and the Shrinking Trust Perimeter

Why hardware-enforced isolation is moving from research curiosity to operational baseline

As a CIO, I am consistently frustrated by the gap between cloud providers’ promises and their actual guarantees. Migrating workloads to the cloud, especially those involving sensitive records or financial data, requires extending trust to infrastructure I neither own nor can fully audit. Provider administrators, hypervisors, and co-tenants all contribute to the threat surface, whether or not it is explicitly acknowledged.

Confidential computing is the most robust architectural solution I have encountered for this challenge. It does not require increased trust in the platform through policy or contracts. Instead, it makes platform trust unnecessary for specific high-sensitivity workloads, which is a significant distinction.

Rethinking the Threat Model from the Hardware Up

Traditional cloud security relies on a layered trust model: hardware is trusted, the hypervisor is mostly trusted, the operating system is somewhat trusted, and controls are applied on top of that. Confidential computing eliminates these layers.

With Trusted Execution Environments (TEEs), your data is decrypted only within a hardware-enforced securWith Trusted Execution Environments (TEEs), data is decrypted exclusively within a hardware-enforced secure enclave. The hypervisor, even if accessible to cloud administrators, cannot access this

data. Neither a compromised operating system nor other tenants can reach it. The security boundary is enforced at the hardware level, not through software policy.n. Before releasing keys or sensitive datasets to an enclave, a client can ask the enclave to verify which code is running and on which hardware. The enclave returns a signed attestation report — covering its code measurements and platform configuration — verifiable against the chip manufacturer's trust anchor. If the proof doesn't check out, no data flows. Trust becomes an enforceable predicate rather than a soft assumption.

This is especially relevant given NIST and CISA’s focus on zero-trust maturity. Remote attestation shifts the model from "trust but verify" to "verify, then trust—only for this workload, on this hardware, running this exact binary." This is a defensible position for a board audit committee.

Where I See the Real Institutional Use Cases

Sensitive data analytics without leaving your compliance posture behind

At Denver Seminary and in most higher education and nonprofit organizations I work with, the most critical data also faces the greatest regulatory constraints: student records under FERPA, donor financials, HR data, and research involving human subjects. Traditionally, this data remains on-premises, often resulting in reliance on costly, outdated infrastructure that limits analytical capabilities.

Confidential computing provides a balanced solution. Data is encrypted at the source, transmitted to the cloud, and decrypted only within a TEE. The cloud operator and hypervisor see only ciphertext. An authorized analytical process inside the enclave accesses plaintext, performs computations, and returns only permitted results. This architectural approach makes migrating sensitive workloads to the cloud a manageable risk rather than a compliance risk.

Federated AI without blind trust in the platform

Given my postdoctoral research at Harvard on agentic AI risks, I have closely followed federated learning. The concept—multiple parties contributing private data to a shared model without exposing their datasets—is compelling. However, platform trust remains a challenge. Who operates the aggregation layer, and what prevents them from inspecting contributions?

TEEs address this issue directly. Multiple institutions, such as hospitals, universities, and government agencies, can contribute to a shared training run within an enclave. Neither the platform operator nor other contributors can access individual data. This results in a richer model and improved data governance. Model weights can also be protected during inference, which is critical for institutions with proprietary model investments.

Confidential databases — a practical step most teams can take now

This is the use case I find most immediately actionable for teams not prepared to redesign their entire data architecture. Database engines operating within TEEs can process queries on encrypted data—performing filters, joins, and aggregations on decrypted values inside the enclave—without exposing those values to the operating system, DBA console, or cloud management plane. Sensitive columns remain encrypted except within the secure computation boundary.lly homomorphic encryption or private information retrieval in the most demanding scenarios. But for the vast majority of institutional database workloads — payroll, benefits, student records, donor data — it meaningfully closes the insider threat gap without requiring a wholesale re-architecture.

Honest About the Limitations

I want to be careful not to oversell this. TEEs are a significant. It is important not to overstate the benefits. TEEs represent a significant advancement, but they are not a comprehensive solution and have real limitations. The transitions carry cost, encrypted memory adds latency, and attestation rounds add startup time. For latency-sensitive workloads, this requires careful profiling. In my experience, most batch analytics and background AI inference workloads absorb it reasonably well. Interactive query workloads require more thought.

Hardware dependence is another constraint. TEEs require specific CPU features such as Intel TDX, AMD SEV-SNP, or ARM TrustZone. Not all cloud regions support these features, and edge or IoT environments present additional challenges. During my Harvard coursework, I observed that lightweight cryptographic primitives required by constrained devices do not align well with the current TEE model.

The residual attack surface is another important consideration. Side-channel attacks, such as Spectre-class timing and cache attacks, remain a concern for TEE implementations. Hardware supply chain integrity is also unresolved. While TEEs significantly reduce privileged insider risk, they do not eliminate all attack vectors. Treating TEEs as impenetrable is as risky as disregarding them entirely.

Where This Fits in: Confidential computing is part of a broader set of privacy-enhancing technologies, including secure multiparty computation (MPC), homomorphic encryption, differential privacy, zero-knowledge proofs, and synthetic data. Each addresses overlapping challenges with distinct trade-offs. The UN’s guidance on privacy-preserving statistical methods emphasizes that no single technique is universally superior. A single technique dominates.

TEEs offer operational practicality that most alternatives lack. Homomorphic encryption is mathematically robust but computationally intensive. MPC requires complex protocol design and multiple non-colluding parties. In contrast, TEEs require only modest changes to existing applications, effectively enclosing workloads within a hardware boundary rather than redesigning cryptographic foundations. This is particularly valuable for institutions with established codebases and limited engineering resources.

A Practitioner's Starting Point

If advising a peer CIO interested in piloting this technology, I would recommend the following sequence: a microservice is ideal — small attack surface, clear data sensitivity, easy to instrument. Move just that into a confidential VM or confidential container offering from your cloud provider. AWS, Azure, and Google Cloud all expose TEE capabilities through familiar VM and Kubernetes abstractions at this point; the barrier to entry is lower than most teams assume.

Integrate attestation from the outset. The attestation process, in which the application’s startup sequence requests proof of the enclave’s identity before releasing keys, provides the core security guarantee. Without attestation, a TEE does not deliver its intended protection.

Next, evaluate performance, operational overhead, and incident response complexity. Build institutional knowledge before expanding the deployment scope.

For those involved in AI governance, sensitive data analytics, or cross-institutional data sharing—which encompasses many critical technology challenges in higher education, healthcare, and government—confidential computing is becoming a baseline expectation rather than a niche research topic. The key architectural question is not whether to adopt it, but how it fits within your threat model and which workload to prioritize.

Only the code you chose, running in an attested hardware enclave, should ever see your data in the clear. That is a principle worth building toward.