# The AI Intruder Was Fast. Segmentation Still Won.

> An automated intruder chained two Zammad flaws and reached root in seconds at DIVD. The useful lesson is how segmentation, logs, and a fast containment decision kept speed from becoming unlimited reach.

- **Author:** Kubilay Tunca
- **Published:** 2026-10-04
- **Category:** For Developers
- **Tags:** AI Agents, Incident Response, Network Security, Vulnerability Management
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/ai-intruder-fast-segmentation-still-won

---

On 21 September 2026, an intruder entered the Dutch Institute for Vulnerability Disclosure through its support-ticket system. The path ran through two previously undisclosed Zammad flaws. One gave the attacker code execution as the application user. The other raised that local access to root. DIVD says the chain completed in seconds.

The speed is the striking part of the story. The useful part is what happened next. DIVD detected suspicious activity the following day, blocked access to every system in its data centre, brought in an external incident-response team, and found that network segmentation had kept the intruder from moving farther into its environment. Data still left the support system. Volunteers' DIVD email addresses and possibly contact details were exposed. Containment limited a real breach; it did not erase it.

DIVD assessed the operation as agent-driven because the scripts recorded an automated sequence of actions and included comments justifying those actions. The organisation described the activity as fast, sloppy, and unusually verbose. That account supports an AI-agent explanation, while leaving two important questions open as of 4 October: who assigned the task, and what wider objective they had.

That uncertainty should temper the headline, not the response. An automated intruder can compress the interval between first access and root access. It cannot make a segmented network disappear. This incident gives engineering teams a concrete model: when the attacker moves at software speed, defensive boundaries must work before a human reads the first alert.

## What happened between 21 September and 1 October

DIVD is a volunteer-heavy Dutch nonprofit that finds vulnerabilities, coordinates reports, scans for exposed systems, and warns their owners. Its support system therefore holds unusually sensitive conversations. A ticket may include an organisation's vulnerable address, details of an unpublished flaw, follow-up questions from a researcher, or an extract from a credential dump with passwords masked. A helpdesk in this setting is part of the security operation, not merely a place for password-reset requests.

[DIVD's incident timeline](https://csirt.divd.nl/cases/DIVD-2026-00014/) places the first malicious access on 21 September. On 22 September, the team noticed suspicious activity, blocked access to systems in its data centre, and began forensic work with Merlon Security. It reported a vulnerability to Zammad on 24 September, notified the Dutch Data Protection Authority and the National Cyber Security Centre, briefed partners and affected parties, and discussed the case with police.

By 30 September, investigators had reconstructed the entry chain. DIVD says the attackers combined CVE-2026-102489, a session flaw that led to remote code execution as the local `zammad` account, with CVE-2026-102490, a local privilege-escalation flaw that raised that account to root. Root is the highest ordinary level of authority on a Linux host. From there, the intruder reached other services and removed some data before the response team stopped further movement.

Independent accounts match that central sequence. [Help Net Security reported on 1 October](https://www.helpnetsecurity.com/2026/10/01/divd-agentic-ai-attack-breach/) that the two flaws were chained through session access, code execution, and local privilege escalation. [The Register separately reported](https://www.theregister.com/security/2026/10/01/ai-agents-hacked-the-hackers-stealing-email-addresses-from-security-research-org/5300652) the same path, the 22 September containment action, and the disclosure of volunteer email addresses and possible contact details.

The data picture remained incomplete on 4 October. [DIVD's live investigation page](https://csirt.divd.nl/cases/DIVD-2026-00014/overview_data_investigation/) confirms that volunteer email addresses and possibly contact details were exfiltrated. It also tells organisations and researchers who exchanged messages with the CSIRT mailbox to assume that some of that correspondence may have been taken. The ticket system showed signs of compromise, and the attacker had difficulty extracting information, so investigators were still determining how much left the environment.

That wording matters. “The ticket system was compromised” and “every ticket was stolen” are different claims. DIVD supports the first and has not established the second. Its public table also listed several systems and data sets as still under investigation, including project-support tools, source repositories, internal communications, vulnerability details, and masked credential extracts. Accounting and banking systems were handled by an external party, with no signs of compromise reported at that point.

The case was still open when this article was written. Later findings may change the known data scope or the affected version details. A responsible response uses today's evidence without pretending that an active investigation has already produced its final report.

## The “AI attack” label explains tempo, not authority

DIVD did more than infer automation from a fast command sequence. On 26 September it described comments embedded in the attacker's scripts where the system appeared to justify its own actions and explain why they were acceptable. On 29 September, the organisation said it could see the agent choosing each next step on its own, quickly and with sloppy logic. The extra commentary helped investigators reverse-engineer the activity.

Those observations are strong evidence of an agent in the operational loop. They do not show that a model invented the campaign, selected DIVD as a target without human direction, or acted without any operator. DIVD says it has no known public threat-actor match and cannot yet establish whether the organisation was deliberately targeted for its sensitive research data. The operator, assignment, model, and surrounding command system remain unknown in the public record.

This distinction keeps the threat model useful. A coding agent or offensive automation system can inspect results, choose another action, and repeat without waiting for a person to copy a command. That shortens the pause between stages. The authority still comes from the compromised account, the vulnerable application, the root escalation path, reachable services, available credentials, and permitted network routes.

Imagine a warehouse robot that finds an unlocked cage, picks up the master key inside, and then tries every nearby door. Its speed changes the response window. The unlocked cage and the master key explain its reach. Buying a “robot detector” while leaving both conditions in place would miss the mechanism.

The same reasoning applies here. CVE-2026-102489 supplied execution in the application's local context. CVE-2026-102490 allegedly supplied root on the host. Connections and credentials available from that host defined what came next. Segmentation removed some routes. The response team removed more by blocking the data-centre systems. Each stage gained or lost authority through an ordinary control point.

This is good news for defenders, though it is not comforting news. Existing controls still matter. Their timing matters more. A firewall rule that an administrator plans to add after reviewing an alert is slower than an automated sequence. A rule already enforced in the network can reject the next connection immediately. A credential that will be rotated at the end of the quarter stays useful to an intruder. A short-lived credential scoped to one service starts with less value.

The agent label should therefore change the required response time and the assumed amount of activity between alerts. It should not distract a team from applications, identities, host privileges, and network paths. Those remain the places where an automated plan becomes an actual effect.

## Two flaws formed one authority ladder

The Zammad chain is easier to understand as an authority ladder than as two severity scores. At the bottom sits an unauthenticated remote visitor. The first flaw moved that visitor into a session and then into code execution as the `zammad` operating-system user. The second moved a local user from that limited account to root. Root could then read files, inspect processes, reach credentials available on the host, and attempt connections that the network allowed.

Each rung matters because each could have stopped the chain. A current application release could remove the remote entry condition. A hardened service account and host could reduce what application-level execution exposes. A fixed local escalation flaw could keep the application user from taking the whole machine. Segmentation could keep a rooted host away from unrelated systems. Egress controls could restrict where collected data leaves. Detection and containment could close the remaining routes.

Version guidance changed while the incident unfolded, which makes dated language essential. [DIVD's vulnerability case](https://csirt.divd.nl/cases/DIVD-2026-00015/) said on 1 October that CVE-2026-102489 affected versions 6.3.0 through 6.5.4. It also said the vulnerable code existed in versions 7.0.0 through 7.1.3 but was not exploitable there because of environmental conditions. DIVD listed CVE-2026-102490 across versions 1.5.0 through 7.1.0-alpha and advised users to upgrade to Zammad 7 or take the service offline.

Zammad's own account added a dispute and then a partial update. In [a vendor statement posted to its community forum on 1 October](https://community.zammad.org/t/take-care-local-privilege-escalation-cve-2026-102490-is-reported-as-being-actively-exploited/21297/2), the company said it had previously analysed the first issue, that exploitation applied to Zammad 6.5 and older because of their runtime, and that 7.0 and later were not affected in practice. Zammad said it had hardened the relevant code in 7.2.0. At first it said it had not received technical details for the local escalation claim. Later that day, it updated the thread to say the details had arrived and that the issue required prior access to the server.

The Dutch NCSC also separated the two conditions. [Its advisory NCSC-2026-0396](https://advisories.ncsc.nl/2026/ncsc-2026-0396.html) urged administrators to install available updates for CVE-2026-102489 and preserve application and network logs before doing so. It said CVE-2026-102490 had not yet been repaired at the time of that advisory and advised customers to monitor vendor communication for a fix.

On 2 October, the US Cybersecurity and Infrastructure Security Agency added both flaws to its [Known Exploited Vulnerabilities catalogue](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). CISA described the session flaw as leading to code execution as the Zammad user and the second as improper privilege management that can raise that user to root. Its entry requires federal agencies to apply vendor mitigations, perform forensic triage, or discontinue use when mitigation is unavailable. CISA listed 5 October as the due date and marked ransomware use as unknown.

These sources agree on the incident chain and disagree, or have disagreed, on parts of disclosure timing and version scope. The safe operational reading on 4 October is narrow: update to the vendor's current stable release, Zammad 7.2.0; preserve logs before changing the system; watch the vendor advisory channel for the privilege-escalation resolution; and treat an exposed older instance as an incident question, not a patching chore. If a confirmed fix is unavailable for a flaw that matters in your environment, remove the service from exposure or take it offline until you can restore a defensible boundary.

A version string alone cannot answer whether compromise occurred before the update. The old system had an internet-facing route and held security-sensitive tickets. Once a flaw is known to have been exploited, the useful question becomes twofold: is the vulnerable condition gone, and what evidence shows whether anyone used it while it existed?

## Segmentation bought something patches could not

Patches remove known vulnerable code. Segmentation limits the next reachable destination after one component fails. DIVD needed both, but only one was already able to constrain the unknown flaws on 21 September.

The organisation says proper network segmentation helped stop the attackers from going deeper. Public statements do not reveal its internal topology, so we should avoid inventing a perfect diagram. The supported conclusion is simpler: root access on the Zammad host did not translate into unrestricted access to every DIVD system. Some boundaries survived the loss of that host.

That is the job of segmentation. A support server needs specific paths: perhaps a database, an identity provider, outbound mail, monitoring, update sources, and administrative access from a controlled network. It rarely needs open access to source-control administration, finance systems, volunteer directories, vulnerability archives, workstation networks, and every other server. A rule set that permits only named flows turns “root on one host” into a contained emergency rather than an automatic estate-wide identity.

Teams often describe a network as segmented because it has subnets or cloud security groups. Address separation is only the drawing. Enforcement lives in the routes and rules between them. If every application subnet may initiate connections to every other private address, the colours on the architecture diagram offer little resistance. A useful boundary denies an unexpected path even when the originating machine presents a valid internal address.

The control also has to survive stolen application credentials. Suppose the Zammad host legitimately sends mail and queries a directory. A broad directory credential available in an environment file may let root on that host search every employee and change accounts. A read-only credential restricted to required attributes gives the same application less power. Network and identity scope should reinforce each other; either one may fail first.

Outbound traffic deserves equal attention. Data exfiltration needs a route out, though that route may be an ordinary web request, domain-name query, cloud-storage upload, or connection through another trusted service. A support platform may need to fetch attachments or deliver notifications, so “block the internet” is often unrealistic. A practical policy names the destinations and protocols the workload needs, records the rest, and rejects connections that have no owner.

Machine speed meets pre-committed policy at that point. An agent can choose another destination in milliseconds. It cannot persuade a stateful firewall to permit a route that the rule set denies unless it also compromises the control plane. The decision happens outside the model and outside the rooted application host. That independence is the valuable property.

Segmentation did not prevent the DIVD data loss that occurred through reachable systems. It reduced the set of systems the intruder could reach before containment. That is a modest claim with large consequences. Security architecture rarely guarantees that one component will never fail. It decides how many other components must fail with it.

## Logs became useful because the intruder left a receipt

The DIVD account contains an odd advantage: the automated activity apparently overexplained itself. Comments in scripts helped investigators understand why one action followed another. That is convenient evidence, not a dependable detection strategy. The next operator can remove comments, choose a quieter model, or wrap the agent in conventional tooling.

The durable lesson is to keep records an intruder cannot revise from the machine it controls. A rooted host can alter local log files, stop agents, change timestamps, and delete shell history. Remote application logs, network-flow records, identity events, DNS queries, proxy decisions, and cloud-control-plane audit trails preserve different views. An attacker has to defeat every independent recorder to erase the path completely.

Preservation order matters during an active flaw. Installing an update changes files, restarts processes, rotates temporary data, and may overwrite the artefacts that distinguish exploitation from ordinary activity. Both the Dutch NCSC and CISA paired remediation with forensic work in their October guidance. That pairing recognises a hard truth: a clean current binary cannot testify about yesterday.

A useful incident receipt joins four kinds of evidence. Application records show sessions, ticket access, administrative changes, and requests. Host evidence shows processes, persistence, files, users, and privilege changes. Network records show lateral movement and data leaving the environment. Identity records show which accounts, tokens, and service principals were used elsewhere. No single source tells the whole story.

Retention also has to exceed the discovery gap. DIVD detected activity within a day, which gave its team a rich window. Many organisations discover an intrusion weeks later. Seven days of network logs may be cheap until day eight. Choose retention from the longest plausible detection interval and the sensitivity of the system, then test that the archived data can actually be retrieved.

The agent's narration made this case easier to reverse-engineer. Independent telemetry made it possible to establish scope. Treat verbose attacker notes as a windfall. Build the investigation around evidence you own.

## The stolen addresses create a second incident path

Volunteer email addresses can look minor beside root access and zero-days. Their practical risk is impersonation. DIVD publicly warned that someone could pose as a volunteer more easily and asked recipients to verify unusual messages through `communications@divd.nl`.

Context makes an address more valuable. A message that uses a real DIVD name, refers to an actual support exchange, and arrives during a public incident can sound credible. A recipient may be primed to open a replacement report, review a “corrected” indicator file, reset a portal password, or move a conversation to another channel. The stolen data does not need to include a password if it helps an attacker borrow trust.

Researchers and organisations that exchanged mail with DIVD's CSIRT should therefore treat follow-up messages as claims to verify. Replying in the same thread is weaker than it seems if the mailbox, ticket history, or correspondent data was exposed. Use a contact route obtained independently from DIVD's official site, and confirm any request that asks for credentials, files, software execution, payment, or a change of channel.

Internal teams should brief the people most likely to receive such contact: the security desk, IT support, vulnerability-management staff, researchers, and communications teams. Give them a plain test. A message mentioning the incident is not proof that it came from DIVD. Verify the sender and the requested action through the published contact route before doing anything with authority.

The same pattern applies when your own support platform is breached. Resetting the server closes one technical path. Customers, employees, and partners may continue receiving credible messages built from stolen conversations. Incident scope includes the social authority carried by the data, not only the number of database rows.

This is one reason transparent disclosure helps. DIVD gave recipients a verification channel while the investigation was still incomplete. People could act on a known risk without waiting for a final count. Precision made the warning useful: the organisation named what it knew, what remained uncertain, and which behaviour should change.

## What Zammad operators should do now

A team running Zammad needs an ordered response rather than a hurried update followed by silence. The sequence below reflects the public guidance available on 4 October 2026. Adapt it with your incident-response lead, vendor support, legal obligations, and local architecture.

1. **Identify every instance and its exposure.** Record the running Zammad version, operating-system image, deployment type, public addresses, reverse proxies, administrative routes, connected databases, file stores, identity systems, mail services, and outbound network paths. Include forgotten test and migration systems. An unlisted instance cannot enter the response.

2. **Restrict the route before changing evidence.** If an affected or uncertain instance is reachable from the internet, remove public access, place it behind a narrow allowlist, or take it offline. Preserve the ability to investigate; avoid repeatedly rebooting or experimenting on the original host. A containment rule should have an owner, timestamp, and verification from outside the network.

3. **Preserve application, host, identity, and network records.** Export logs and relevant snapshots to storage the Zammad host cannot alter. Keep hashes and collection notes so later analysis can distinguish an original artefact from a working copy. The Dutch NCSC specifically advised saving application and network logs before installing updates.

4. **Move to Zammad 7.2.0 or the newer fixed release named by the vendor.** Zammad called 7.2.0 the current stable release on 1 October and said it included hardening for CVE-2026-102489. Check the vendor's security-advisory channel at the moment you act, because the CVE-2026-102490 investigation was still moving. If no adequate mitigation exists for your deployment, keep the service away from hostile access or discontinue it temporarily.

5. **Investigate the pre-update window.** Use DIVD's published indicators and log-check material as one input, not as a certificate of cleanliness. Look for unexpected sessions, code execution under the application account, privilege changes, new users or keys, persistence, access to ticket exports, unusual archive creation, lateral connections, and outbound transfers. A clean signature scan cannot rule out activity that used a different artefact.

6. **Rotate trust that the host could reach.** Inventory database passwords, mail credentials, API tokens, OAuth secrets, backup keys, signing material, service-account credentials, SSH keys, and session secrets available to the application or root. Revoke and replace them from a known-clean administration path. A password change on the compromised host can hand the new password to the same intruder.

7. **Rebuild when host trust is lost.** Root access removes confidence in the machine's files and running state. Deploy a known-good image with a reviewed configuration, restore only necessary data, and compare the old and new authority maps. Cleaning visible files on the original host asks the attacker to disclose every change they made.

8. **Prove the new boundary.** Test from an external network that the old route is closed. Test from the rebuilt application segment that unrelated internal systems are unreachable. Confirm that required mail, database, monitoring, and update flows still work. Save the results with the incident record so “fixed” means an observed state rather than a completed ticket.

The order protects two goals that often compete under pressure: stop further access and keep enough evidence to understand what already happened. Skipping containment leaves the door open. Updating before preservation may destroy the best record of who used it.

## What every agent-enabled system should copy from this incident

Most readers will not run Zammad. Many will run systems where software can choose and execute a sequence of actions. The DIVD incident offers a wider design rule: measure a boundary by what it does after one component is fully controlled.

Start with an authority map. Pick the agent runner, support service, continuous-integration worker, or automation host. Assume an intruder has its process account. Then assume root or administrator access. List the files, credentials, sockets, services, control planes, internal destinations, and outbound routes available at each level. The difference between those two lists shows whether host escalation creates meaningful extra reach.

Remove ambient access. A workload should receive the credential for the task it is performing, scoped to the required resource and lifetime. It should not inherit a broad cloud key because that was easier during setup. A build agent that needs to upload one artefact should not hold deletion rights across every release. A support system that needs directory lookup should not administer identities.

Put consequential decisions outside the model and outside the workload it controls. A separate policy service can check whether a proposed destination, command class, data volume, or resource falls within a pre-approved envelope. The agent may request an action. The enforcement point decides whether that action is possible. If both run with the same credentials on the same host, compromise collapses the distinction.

Rate and volume controls matter alongside permission controls. A service may legitimately read tickets, yet have no ordinary reason to export ten thousand of them in five minutes. A deployment agent may create one environment per change, yet never fifty in a minute. Limits on action count, data volume, destination diversity, and credential use can stop a fast loop while allowing routine work.

Give the stop mechanism a shorter path than the agent. DIVD blocked access to its data-centre systems on the day it detected malicious activity. Your equivalent might disable a workload identity, isolate a subnet, revoke an egress policy, pause an agent queue, or remove a tool grant. Rehearse that action. An emergency control hidden behind three approvals and a missing administrator is documentation, not containment.

Keep the recorder independent. Send tool calls, policy decisions, identity events, network flows, and data-volume summaries to append-oriented storage outside the worker's authority. Record denied actions as well as successful ones. A sudden stream of denials may be the first sign that automation is exploring the edge of its permissions.

Finally, test the failure at speed. A tabletop conversation can miss the operational gap between a one-second alert and a twenty-minute containment process. Run a safe exercise in a disposable environment: let a test worker issue a burst of forbidden and permitted requests, verify that the boundary holds, measure how quickly the alert arrives, and time the isolation step. The goal is a receipt showing that the control acts before a person can reason through every event.

This is the same discipline I argue for in *The Secure Harness*: autonomy becomes manageable when its authority, network, evidence, and stop conditions are designed before the task begins. DIVD's experience adds a defender's view. The same harness ideas constrain an agent you operate and an automated intruder using a host you lost.

## Speed changes the clock, not the foundations

The DIVD breach contains a new operational detail and an old architectural truth. The new detail is an apparent AI agent selecting follow-up actions fast enough to move from a stolen session to root in seconds. The old truth is that one compromised service should not become every service.

DIVD still lost data. Volunteers and correspondents now have an impersonation risk, and the organisation was still investigating sensitive systems on 4 October. Calling segmentation a success should never turn into calling the incident harmless. The control earned its value by limiting additional damage while people contained the breach.

That is the standard worth copying. Assume one application will eventually fail. Decide in advance which routes survive that failure, which credentials remain useful, which records remain trustworthy, and which switch stops the workload. Then test those decisions under a clock measured in seconds.

An automated attacker can make the first hour much busier. It cannot cross a boundary that was built to hold without asking the compromised machine for permission. Build that boundary while the network is quiet.

For one practical security explanation each month, join the newsletter. One email per month, and the signup lives on this site.

## Sources

- [DIVD CSIRT: DIVD-2026-00014, When, not if](https://csirt.divd.nl/cases/DIVD-2026-00014/), accessed 2026-10-04
- [DIVD CSIRT: Overview of data investigation](https://csirt.divd.nl/cases/DIVD-2026-00014/overview_data_investigation/), accessed 2026-10-04
- [DIVD CSIRT: Vulnerabilities in Zammad during investigation of case DIVD-2026-00014](https://csirt.divd.nl/cases/DIVD-2026-00015/), accessed 2026-10-04
- [Help Net Security: AI agent used Zammad zero-days to breach Dutch vulnerability disclosure non-profit](https://www.helpnetsecurity.com/2026/10/01/divd-agentic-ai-attack-breach/), accessed 2026-10-04
- [The Register: AI agents hacked the hackers, stealing email addresses from security research org](https://www.theregister.com/security/2026/10/01/ai-agents-hacked-the-hackers-stealing-email-addresses-from-security-research-org/5300652), accessed 2026-10-04
- [Zammad Community: Vendor statement on vulnerability reports in DIVD case DIVD-2026-00015](https://community.zammad.org/t/take-care-local-privilege-escalation-cve-2026-102490-is-reported-as-being-actively-exploited/21297/2), accessed 2026-10-04
- [Dutch NCSC: NCSC-2026-0396, active exploitation of zero-day vulnerabilities in Zammad](https://advisories.ncsc.nl/2026/ncsc-2026-0396.html), accessed 2026-10-04
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), accessed 2026-10-04

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._