Overview

Recently I’ve seen a lot of talk about exciting opportunities for AI security engineers: prompt injection, Model Context Protocol (MCP) tool poisoning, RAG poisoning, guardrails, automated red teaming, model extraction and interpretability. Many of these discussions and posts have focused on what people like to work on as opposed to the business requirements.

I want to do a reality check on what businesses need compared with what people want to work on. The job is to prevent loss and strengthen security (simplified), so that is where I start. This post covers the areas I find most important for AI security engineering today, each tied to what it protects a business from. It draws on a year of public incidents, attacker reports and hiring data.

So, in this post I will dive into my reflections on the wider AI security engineering landscape, holistically. My main takeaway is that the ways to attack are new, and the failures they exploit are the same ones we have had on our lists for years. I mean things like credentials left where an agent can read them, permissions that are too wide, no separation between staging and production, and backups inside the blast radius.

In this post:

My experiences

I started coding around the age of 12, which is about 30 years ago now, and started exploring security around 16, some 26 years ago. That was an interest long before it was a career. I was a kid exploring the internet in the era of online forums you had to reach from your dial-up modem, and around the turn of the millennium I was a moderator of one of the largest security forums online at the time. Security was always fun, and it was a gray hat phase for me. I loved securing things, but to secure something we first had to figure out how it could be exploited, so I had one foot in each camp. When capture the flag challenges became a thing I absolutely loved them: a safe environment where you get to exploit real systems. All of it taught me how attackers think, and that has helped me throughout my professional career, because every time we need to think about defense, I start by asking how I would get in.

From around 2018 I stepped further into leadership and was no longer only a hands-on engineer, and the compliance side of security came with that. I have worked a lot with SOC 2 Type II, ISO 27001 and GDPR in the years since, and the EU AI Act is now on the same list. I wrote about the mindset back then in Embracing the Security Development Lifecycle on Azure and Establish your organizational compliance readiness, and most of it still holds. Today my work is a solid blend of engineering leadership and hands-on building, and AI is what gave me the hands-on half back.

The attacker’s view matters as much now as it did then. Attackers are using AI agents, so I think we have to embrace agentic offensive security ourselves and learn how an AI-driven attacker works before we decide how to defend against one. That threat is growing fast, and I come back to it in Think like the attacker’s agent further down.

I write about working with coding agents in my agentic AI engineering series. The one opinion from it that matters most for this post is that a rule in a markdown file is a request and only something that can deny is a control, which I argue in why instructions aren’t enough for coding agents.

Same failures, but new ways to attack

So, on with this post. Here’s what really got me thinking hard about the security landscape today, and how I think about the job.

To set the scene, I’m lining up some of the known incidents and research findings I’ve come across. This helps me paint the picture of why the rest of this article is important for anyone working with AI, especially if you’ve got access to sensitive systems or data, and if you’re interested in an AI security engineering type of job.

  • An AI lab’s evaluation agents escaped their sandbox and broke into another company’s production infrastructure. OpenAI and Hugging Face, July 2026. During an internal cyber capability evaluation, OpenAI’s models got out through a previously unknown vulnerability in a package registry proxy, the sandbox’s only allowed network path, and went after the benchmark’s answers at Hugging Face. Hugging Face’s technical timeline counts about 17,600 attacker actions between 9 and 13 July, up to a production secret holding 136 keys and cluster-admin on 2 internal clusters, and says the only customer content accessed was 5 datasets. The zero-days were new, and what let the agent keep going was familiar, by Hugging Face’s own account: a template injection in dataset processing, no admission policy against privileged pods, a single credential shared across clusters, and an alert that never paged the on-call team.
  • A production database and its backups, deleted in 9 seconds. PocketOS, April 2026. A coding agent on a staging task found a Railway CLI token in an unrelated file and deleted the production database and its volume-level backups with one API call. The backups lived inside the volume that was deleted, and the data only came back when Railway stepped in and restored it. The model misbehaved, and the damage came from a token that was left where the agent could read it and worked across every environment, and from the backup design.
  • A production database erased during a code freeze. Replit, July 2025. An agent erased a production database while an explicit code freeze was in place. Nothing separated the environment the agent worked in from the one that held customer data, and that separation is what Replit’s CEO promised to add afterwards.
  • Internal company data that a single email could exfiltrate. Microsoft 365 Copilot, June 2025, known as EchoLeak and tracked as CVE-2025-32711. One crafted email could make Copilot send internal data out, per Aim Labs’ write-up and Microsoft’s advisory. Microsoft fixed it on its side and lists it as not exploited. The injection technique was novel, and the exposure came from an agent that held private data, read an attacker’s email and had a way to send data out. That combination is what Simon Willison calls the lethal trifecta, and taking away any one of the three stops the attack.
  • A deployed agent that could pivot into the customer’s cloud project. Google Vertex AI, March 2026. Unit 42’s Double Agents research showed that the service agent behind a deployed AI agent had default permissions wide enough to reach into the customer’s project and beyond. Google’s fix was documentation and a recommendation to bring your own service account. OWASP’s exploit round-up for the first quarter of 2026 puts it down to the excessive default permissions the agent inherited.
  • Tens of thousands of agents exposed to the internet, and a marketplace carrying hundreds of malicious skills. OpenClaw, February 2026. Researchers found admin interfaces on the public internet, a one-click remote code execution bug, and an unreviewed marketplace where 341 of 2,857 skills were malicious, all running with the user’s full permissions. Every one of those was a known problem before anyone put a model in the loop. Default configurations were the first item in the NSA and CISA top 10 misconfigurations I wrote about in 2023, and they still are.
  • SSH keys, cloud credentials and API tokens harvested from developer machines. Shai-Hulud, since September 2025. A self-propagating npm supply chain worm, documented by ReversingLabs and answered by GitHub’s changes to npm publishing. A Shai-Hulud-style worm in February 2026 went a step further and planted a rogue MCP server whose tool descriptions tell the coding agent to read the SSH keys and cloud credentials itself. The fix has nothing AI-specific in it: lifecycle scripts off, tokens short-lived, credentials rotated, and the agent’s configuration reviewed like code.
  • Human approval gates bypassed, more consistently than any other failure. Microsoft AI Red Team, June 2026. After a year of red teaming deployed agents, they reported that human-in-the-loop bypass was the failure mode they saw exploited most consistently. A gate the model can argue its way past, or that a tired human clicks through, does not hold. It is the reason I keep the hard lines on irreversible actions with me rather than with the agent.

The pattern I take from this is that the model is the new untrusted component in an old architecture. Everything we already know about untrusted components applies: least privilege, separate identities, separate environments, deny by default, confirmation before irreversible actions, backups outside the blast radius, logs that cannot be edited. What is new for me is having to know where the model sits in the data flow and which of those controls it can talk its way around, so that I build the ones it cannot.

Think like the attacker’s agent

I mentioned earlier that I start every defense by asking how I would get in. Over the last year, the people getting in started using AI agents to do it, and this is what that looked like in real intrusions.

AI-driven attacks in 2026, as seen with the open-source framework ARTEX: under 3 hours from first targeting to privileged cloud access, more than 200 organizations targeted by one group, 27 cloud permission probes in 23 seconds, and about 815 deployments still exposed in November. A timeline shows ARTEX going from open-source release in July to real intrusions in late August, a takedown in early October and global campaigns later that month. Two lists contrast what the attacks look like in logs with the old weaknesses they still rely on.

Open-source offensive AI frameworks have multiplied over the last 2 years. These are some of the most popular, by GitHub stars as I write this:

  • Strix, about 74,000 stars. Autonomous agents that test a running application and validate each finding with a proof of concept.
  • Shannon, about 52,000 stars. A white-box pentester for web applications and APIs that reads the source code first and then exploits the running application.
  • PentAGI, about 34,000 stars. A multi-agent system that runs penetration tests autonomously.
  • PentestGPT, about 16,000 stars. The framework from the USENIX Security 2024 paper, which now runs autonomous pipelines on Claude Code or Codex.
  • HexStrike, about 13,500 stars. An MCP server that exposes more than 150 security tools to any model.
  • CAI, about 10,000 stars. A research framework from Alias Robotics, archived in August 2026.
  • Cairn, about 5,000 stars. Worker agents that share findings on a common board, first tested on autonomous penetration testing.
  • hackingBuddyGPT, about 1,300 stars. A research framework from TU Wien for privilege escalation, web and Active Directory testing.
  • ARTEX, which has no link. Its developer took the repository down in October 2026 because attackers were using it in real intrusions, which makes it the best documented case of one of these tools being turned on businesses. More on it below.

All of them are built around someone else’s model, and most share one shape: a planner that turns a goal into steps, workers that run the ordinary tools, nmap, sqlmap, a browser, a cloud CLI, and a loop that keeps going until the goal is met or the budget runs out. The model is usually rented and the tooling underneath is decades old.

Three data points show where this went:

  • XBOW, June 2025. It reached the top of HackerOne’s US leaderboard with nearly 1,060 reports, each reviewed by a human before submission.
  • HexStrike, August 2025. It had been public for a few weeks when Citrix published 3 NetScaler CVEs, and Check Point watched criminal forums discussing it against those flaws within 12 hours, claiming exploitation time down from days to under 10 minutes. That claim is theirs and nobody has verified it, though Check Point did see lists of seemingly vulnerable hosts offered for sale.
  • ARTEX, July 2026. Released by the author of a popular asset discovery scanner, it was inside real intrusions by late August. In October the developer took the project down because of that abuse, after it had been used against South Korean financial institutions among others. Forks and rebrands keep it in circulation.

ARTEX is the best documented of the three, from five different vantage points:

  • Google’s Threat Intelligence Group found ARTEX, HexStrike, Cairn and PentAGI in incident response engagements.
  • Microsoft attributed the ConnectWise Cloud Backup supply chain compromise to Storm-0940, which used ARTEX to try signing in to more than 2,250 tenants with stolen OAuth application credentials. In several of the group’s ARTEX-driven attacks, the time from first targeting to privileged cloud access was under 3 hours.
  • CrowdStrike tracked a separate campaign in which VAPOR PANDA, a China-nexus group, used it against more than 200 organizations from 17 October, with a single controller going after targets in at least 14 countries in 11 days. It confirmed post-exploitation activity at 9 organizations.
  • Check Point read the databases of misconfigured criminal instances and found operators setting a goal, in one case for 292 targets, and then checking in on progress.
  • Censys counted around 815 distinct deployments still exposed on the internet in November.

Two things follow for the defender.

The first is that these agents are loud in a specific way. Google’s incident data shows ARTEX generating 240 log events to get partial command execution on one web server, probing AWS permissions at 27 events in 23 seconds, and pushing an application’s notification system into sending test emails to more than 1,300 internal users. A human operator does not look like that. Baselines and burst detection on identity, management APIs and outbound destinations are the controls that fit this attacker. The attackers make the old mistakes too: Check Point’s data came from consoles with exposed databases, and the controller in CrowdStrike’s campaign at times exposed its tooling, target files and agent transcripts.

The second is that you should run one of these yourself. Run it against a copy of your own stack, in a lab, with written authorization, and read the transcript afterwards. I have not run every tool on the list above, but I have used a few of them in isolated environments to get a taste of modern AI-driven penetration testing.

An agentic pentest shows you your attack surface the way an agent sees it: every default credential chain, every verbose error, every API without a rate limit. It also shows you what the attack looks like in your logs, which is the detection you build next.

Treat the tool as the dependency it is. CAI, one of the more serious research frameworks, was archived in August 2026 with a note that an archived offensive framework is unmaintained attack tooling, and Censys found ARTEX consoles online by the hundreds, some with open directories full of implants. Pin a version, run it in a network where the only way out is the model’s API, and give it credentials you would be comfortable losing.

AI threats require AI defense

The frontier labs saw the same shift from the inside. In November 2025 Anthropic published its investigation of a Chinese state-sponsored group that used Claude Code with MCP tooling to run intrusions against about 30 organizations. The AI did an estimated 80 to 90 percent of the hands-on work. The operators made perhaps 4 to 6 critical decisions per campaign and let the agent make thousands of requests at peak.

They got past the safeguards by splitting the operation into small tasks that each looked legitimate, and by telling the model it worked for an authorized penetration testing firm. A small number of intrusions succeeded. The agent also hallucinated credentials and claimed to have stolen data that was public, which the report calls an obstacle to fully autonomous attacks.

For a defender this means the attacker’s cost per target has dropped and the number of attempts will go up. I do not think more analysts can match that.

The defensive side moved over the same period:

In November 2026 Anthropic shipped Mythos 5.2 and published an internal evaluation in which the model rediscovered 89.6 percent of 1,829 published CVEs from pre-fix snapshots, up from 78.3 percent for the previous version, with the curve still rising at every effort level you pay for. It is a vendor benchmark on known bugs, and I read it with that in mind. What I take from it is the cost axis. Finding vulnerabilities has become cheap and fast for anyone with access, attacker or defender.

Two things keep me from calling this solved.

The first is the remediation gap. Detection now scales and fixing does not, and the backlog of findings these tools produce lands on the same engineers who were already behind.

The second is that every one of these tools is dual-use by construction, which is why the strongest models sit behind verification programs:

  • Mythos 5.2 goes to vetted defenders through Anthropic’s Cyber Verification Program, with 30-day data retention for safety monitoring by default.
  • It costs 8 dollars per million input tokens and 40 per million output, and double that in fast mode.
  • Claude Security, which now uses it, is the product route for Claude Enterprise customers.

I think access to a frontier model, or to a security product built on one, is becoming necessary for serious defensive work, and the bill for it belongs in the security budget next to the people cost.

This is how I use AI on the defensive side today:

  • AI reviews code before a human does, and a different model verifies what the first one wrote.
  • AI triages logs and alerts before a person looks, for example with the Azure Copilot Observability Agent.
  • AI proposes patches, and for some changes, such as dependency upgrades, it applies them too. Either way, the pull request gets reviewed.

The human stays where the irreversible decision is, and I put as much effort into making that gate real as into anything the model does.

The shifting landscape

Behind those incidents and campaigns, three things changed between 2025 and now, and they changed together.

Prompt injection is still unsolved, and the vendors say so

Nobody has fixed prompt injection, and the people closest to the problem say so in public:

I take them at their word, and I design as if any content an agent reads could carry instructions.

The research direction that matters is enforcement in code rather than in the model. Three pieces of work are worth reading:

  • CaMeL, from Google DeepMind and ETH Zurich, keeps untrusted data from steering control flow. It pays for provable security with a drop in task completion and a policy file somebody has to maintain.
  • Constitutional Classifiers, from Anthropic, with a follow-up published at ICLR this year, are among the strongest published defenses against universal jailbreaks. They wrap the model instead of trusting it.
  • Crescendo, from Microsoft in 2024, is the reason multi-turn attacks are on every list. A classifier that scores one message at a time cannot see an attack that lives across 10 of them.

Injection left the lab

In 2025 most prompt injection write-ups were demos. In 2026 the telemetry arrived, with injection payloads observed in the wild on websites, and injection attempts reached AI workflows that triage GitHub issues:

  • Palo Alto’s Unit 42 published 12 real-world indirect injection cases in March, including a prompt with the command to “delete your database” and one that attempts to send 5,000 dollars to an attacker-controlled account. Its conclusion from the telemetry is that indirect prompt injection “is no longer merely theoretical but is being actively weaponized”.
  • Zscaler documented 2 real-world campaigns that hide instructions for AI agents in web pages. One uses JSON-LD metadata and off-screen CSS to get an agent on a development task to pay 3 dollars for a fake API key, and in Zscaler’s own sandbox test, with no spending limits set, 4 of 26 models executed a payment.
  • Security researcher Adnan Khan reported in February that another actor took his prompt injection proof of concept for Cline’s AI issue triager, used it to attack Cline, obtained the publishing credentials and published an unauthorized [email protected] to npm. Cline’s post-mortem confirms that a third party used a still-active token to publish it, and says the payload was benign.
  • Datadog reported in March that 2 GitHub issues carrying prompt injection payloads hit the Claude-based triage workflow on its datadog-agent repository, and Claude ignored both.

The tool layer got its own attack demonstrations and vulnerability disclosures, and one malicious server found in the wild. I run coding agents with MCP servers myself, so this is the part I read most closely. An agent reads a tool description as trusted context, and the MCP specification itself says clients must consider tool annotations untrusted unless they come from trusted servers, so a read-only hint on a tool is only a hint:

The marketplaces and package registries followed, with OpenClaw and the Shai-Hulud worm. Both are in the incident list above. In both cases the developer’s machine, with the agent on it, was the target.

The frameworks caught up

The risk lists and taxonomies now cover agents:

  • OWASP’s Top 10 for LLM Applications 2025 was the baseline.
  • OWASP’s separate Top 10 for Agentic Applications followed in December 2025: goal hijack, tool misuse, identity and privilege abuse, agentic supply chain, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.
  • The 2026 edition of the LLM list came in August 2026. Excessive Agency went from sixth to third. OWASP names three root causes for it: excessive functionality, excessive permissions and excessive autonomy.
  • Microsoft’s AI Red Team revised its taxonomy of agent failure modes in June 2026, after a year of red teaming deployed systems. It added 7 failure modes, including agentic supply chain compromise and session context contamination.

The move of Excessive Agency is the point of this post, because it is a list of old failures ranked by the people who track the new attacks. A practical note on the 2026 list: the IDs were renumbered, so LLM03 meant Supply Chain last year and means Excessive Agency now. Write the edition next to the ID, LLM03:2026, or a controls matrix will quietly point at the wrong risk.

The enforcement layer is getting a standard too. The OWASP Agent Control Standard describes a guardian that intercepts the agent at hook points, before a tool call, a memory write or a sub-agent invocation, and returns allow, deny or modify, with the trace emitted over OpenTelemetry. It is the argument from why instructions aren’t enough for coding agents written down as a schema. It is also at version 0.1, and my reading, which CSA’s research note shares, is to design your hooks so they map onto it and to pilot it before relying on it as a control.

Regulation and audit standards moved too:

  • NIST is layering a Cyber AI Profile on top of CSF 2.0 and drafting SP 800-53 overlays for generative assistants, single agents and multi-agent systems.
  • The EU’s Digital Omnibus on AI became law in July 2026. It pushed the high-risk obligations under Annex III from August 2026 to December 2027, and the product-embedded ones under Annex I to August 2028. The transparency obligations under Article 50 and the general-purpose model obligations largely stayed on their original dates.
  • ISO/IEC 42006:2025 sets the requirements for the bodies that certify against ISO/IEC 42001. Accredited AI management system certificates exist, so an unaccredited one deserves a question.

If you build a high-risk system on this stack in the EU, the deadline moved and the record-keeping duty stayed the same: the system has to log what it does, automatically, for as long as it runs. I have worked with audit frameworks since 2018, and I expect ISO 42001 to be the next one many of us face. The evidence it wants for the AI parts is the same evidence that was missing in the incidents in this post.

One skill all of this requires is knowing what kind of thing you are holding:

  • Law: the EU AI Act.
  • Certifiable standard: ISO/IEC 42001.
  • Guidance: NIST’s profiles and Singapore’s agentic AI governance framework.
  • Community rankings: the OWASP lists.
  • Knowledge base: MITRE ATLAS, a catalog of observed attacker behavior that added agent techniques through 2026.
  • Threat modeling method: CSA’s MAESTRO, for multi-agent designs.

A board hears all of them as compliance, and part of the job is to correct that. I covered the older frameworks in Frameworks to strategically improve your cybersecurity, and the new AI layers sit on top of them rather than replacing them.

What about job opportunities?

A lot of the talk about this role comes with a promise of job security, so this is the part I checked hardest. Most of the postings data is from the United States. I am in the EU, so I also looked for numbers closer to home, and what exists there is survey data. Postings count openings and surveys count what security teams say, so I keep the two apart below and in the picture.

Job market summary for AI security engineering from 2026 data, in two separate columns. United States job postings: AI security engineer postings up 268 percent while all cybersecurity postings fell 26 percent, 83 percent of the AI and ML roles in a sample of job descriptions at senior level or above, and the skills job descriptions ask for. Surveys of security teams: paired bars comparing Europe and global answers to the same four questions, such as 56 against 58 percent understaffed and 71 against 64 percent never having run an AI incident response exercise, plus three separate survey findings.

United States. This is where the role is counted as a job title, in CyberSN’s postings data for the first 9 months of 2026 and Dexity’s analysis of 273 security engineering job descriptions from April 2026:

  • AI security engineer postings grew about 268 percent year over year, to around 2,400.
  • All cybersecurity postings fell about 26 percent in the same period, to 235,786, the lowest of the 4 years CyberSN has tracked.
  • That puts AI security engineer roles at about 1 percent of the total.
  • Of the AI and ML roles in Dexity’s sample, 83 percent were senior level or above. Entry level was 2 percent.
  • The skills asked for most were classic security: cloud security in 62 percent of the job descriptions, application security in 59 percent and SIEM in 55 percent. AI or ML skills were required in 19 percent.

Europe and the world, same survey. I could not find a dataset that counts AI security engineer postings across the EU. What exists is survey data, and one survey asked the same questions in Europe and worldwide, so these are the only figures here that compare like with like. ISACA’s State of Cybersecurity 2026, fielded in May, had 1,888 respondents, 494 of them in Europe, and ISACA published the global results separately. Europe is part of the global figure, and with fewer than 500 European respondents a gap of a few points is within the margin of error:

  • 56 percent in Europe say their cybersecurity team is understaffed, against 58 percent globally.
  • 71 percent in Europe have never run an AI-related incident response exercise, against 64 percent globally.
  • 72 percent in Europe say the job is more stressful than 5 years ago, against 68 percent globally.
  • 54 percent in Europe expect a cyberattack within 12 months, against 45 percent globally.

Other 2026 findings. These come from different questions, so they add context and should not be compared with each other:

  • Europe: 54 percent of professionals say they need to build their AI skills within 6 months to keep their job or advance, and 79 percent say within a year. This is from ISACA’s European AI study of 681 professionals in February, where 35 percent also could not tell whether they had been hit by an AI-powered attack.
  • Global: 57 percent of respondents name soft skills as a gap, led by critical thinking and communication, and 45 percent name LLM security operations, up 12 points in a year. Both figures are from the same ISACA survey from May.
  • Global: 68 percent of organizations report skills gaps related to AI risks, and 56 percent have reduced security roles because of AI. This is from Barracuda’s skills gap report, published in October, a vendor survey of 2,000 decision-makers whose sample includes the Nordics, the DACH countries, Benelux and France.

My reading is that the regions point the same way. Overall security hiring is flat or shrinking, and the demand sits with experienced people. Two kinds of skill are sought after at the same time: AI security skills, which are a fast-growing gap, and soft skills such as critical thinking and communication, which are the largest one. That is a fast-growing role from a small base and no guarantee of employment. I think the faster route in is from the security side, because an AI engineer does not pick up identity, threat modeling and regulated risk by accident.

What a successful AI security engineer does

This is my ranking, based on the incidents and the hiring data above.

  1. Decides the blast radius before the agent runs. Who does it run as, what can that identity reach, can it write, and what happens if the model is wrong about what it is doing. Separate identities per agent, scoped and short-lived tokens, separate environments, backups the agent cannot reach. For deployed agents on the Microsoft stack that now means Entra Agent ID, with the on-behalf-of flow when the agent acts for a user, and managed identities or certificates preferred over client secrets. The scoping discipline is the same one I described for repository-level tokens in Azure Container Registry years ago; the principal has just changed.
  2. Threat models the whole system. STRIDE still works for everything around the model. MITRE ATLAS and the two OWASP lists cover the model-shaped parts.
  3. Treats instructions as hints and builds enforcement. Rules files, system prompts and tool annotations are useful and none of them are controls. Hooks that deny, allow-lists, read-only by identity rather than by promise, schemas on outputs, policy in code. I made the full argument in why instructions aren’t enough for coding agents. The OWASP Agent Control Standard is where that layer is heading, so build the hooks in a shape that maps onto it.
  4. Owns the agent supply chain. MCP servers, skills, plugins, packages and project files are code. Pin them, review tool descriptions, re-review when they change, scan marketplaces, and assume the developer’s machine is the target.
  5. Runs adversarial tests in CI. A versioned adversarial set, an LLM judge, and a merge gate on regression against your own baseline. There is no industry-standard jailbreak threshold; pick one and defend it. It is the same move as putting security code analysis and OWASP ZAP into GitHub Actions, with a different test set. Once or twice a year, point an open-source offensive agent at a lab copy of the stack, with written authorization, and turn its transcript into detections.
  6. Logs every prompt, tool call and output somewhere immutable and can replay an incident end to end. The EU AI Act requires event logs for high-risk systems and ISO 42001 has a control for them, and it is cheaper to build as observability on day one. Two older posts of mine are still the pattern: redacting sensitive information before it reaches telemetry, and watching sensitive Key Vault operations with Sentinel.
  7. Uses AI on the defensive side for code review, triage and log analysis, with a human on every irreversible action, and knows exactly where the remediation gap is in their own backlog.
  8. Explains it twice. To the board in risk and timelines, to engineers in controls and pull requests. Compliance literacy is part of the job now. The SC-100 study guide is still a decent map of the architecture side of that conversation. It includes knowing which of the frameworks is a law, which is a standard, which is guidance and which is a community list, and saying so when someone treats them as interchangeable.
  9. Aligns the learning roadmap with the incidents. The topics that get people excited are the right ones. I would put identity, blast radius and supply chain ahead of jailbreak harnesses, because that is the order in which the incidents happened.

The two traits under all of that are reading primary sources, because so much in this post moved in the last 12 months, and humility, because nobody has solved the core problem and the job is to make a successful injection boring.

Final thoughts

AI security engineering has become a core discipline because agents are now on both sides. Attackers use them to move faster through the weaknesses we have always had, and the rest of us use them to build, review and operate systems. Someone has to decide what those agents can reach and be able to show afterwards what they did, and that is engineering work built on security fundamentals.

I am curious what your list looks like, and which incident changed your mind about something. Tell me on LinkedIn.