What AI Doubles in Cyber Skills, and What It Does Not
Defenders now need to understand models, data pipelines and new attack surfaces alongside the classic work. Some of the job has grown and some has not.
On this page
Security work has not been replaced by AI work. The professional asked to protect an AI feature rarely starts from nothing, because most of the job is still networks, identities, logs and response. The honest answer to what has changed is that part of the work has gained a second layer, and part has not changed at all.
The skills that still carry the work
An AI feature is first of all a web service. It has an endpoint that receives requests, a service account holding credentials, a database it reads, and a network path to a model provider. Each of those can be misconfigured in the ordinary ways, and the assessment method used for any web application still applies to everything that is ordinary web application.
Identity matters more here, not less. An assistant acts on behalf of someone, through credentials that someone granted. Questions about who is calling, what that caller may reach and how long the access lasts are the same questions asked about service accounts and single sign-on, and the answers need the same rigor. Incident response carries over as well. What gets logged has to change, but the steps for containing an account or revoking a token stay largely the same. Routine work such as reviewing access lists, tracking patches and reading logs looks dull in a job description, and it is exactly the habit that AI features depend on when something goes wrong.
The new layer
The new layer has three parts. Each is easier to name than to master.
The first is model behavior. A language model takes natural language as both data and instruction, and it has no fully reliable way to separate the two. Someone who understands that a model produces plausible continuations of its input, and that it was trained to follow instructions, can predict where it will misbehave. That understanding is a skill, and most classic security training does not include it.
The second is data controls. Data reaches a model through the prompt, through retrieved documents, through fine-tuning sets and through logs. Each route has its own owner, retention rules and exposure. The question of what data a system can see, and who can change it, has always been asked of databases. It now has to be asked of every place text enters the pipeline.
The third is application security for AI features. A tool that lets a model send email or query a database turns a text generator into something that acts. Output handling, tool permissions and confirmation steps before a consequential action all become security controls, and the code that enforces them sits outside the model.
A fourth area stretches an old idea. Software dependencies have long been treated as a supply chain, and model files, embedding services and third-party plugins now belong in the same picture. Each arrives from outside, each can carry more than its documentation says, and each needs the provenance checks and version pinning that a code library already receives.
Where classic habits need adjusting
Some habits need a change of shape rather than replacement. Treating input as untrusted is still the rule, but the input now includes documents and web pages that the application fetched on purpose. Least privilege still applies, but it must cover tools as well as accounts. Detection engineering still matters, but the events worth detecting include prompts, retrieved passages and tool calls, which most monitoring setups do not record today.
The reason these changes matter is that a model is a component whose behavior depends on text it reads, and that text is not fully under anyone's control. A model cannot be specified the way a parser is specified. Controls therefore have to sit around it, enforced by ordinary code and ordinary identity systems that do not depend on the model deciding well.
A sensible order for learning the new layer
A workable order runs from the ground up. Begin with how a request moves through an application, including where it is authenticated and where it is logged. Then learn the basic behavior of language models: tokens, context windows, and the fact that output is sampled rather than looked up. Next, practice threat modeling a simple assistant on paper. After that, learn to test an AI feature against a written set of expectations, which is the foundation of evaluation. Finally, build a small lab that you control and run the whole sequence through it.
The order matters because each step gives the next one something to attach to. Testing a feature you have not modeled tends to produce a long list of findings with no basis for ranking them. Modeling a feature you have never seen working tends to produce a diagram that misses what the feature actually does.
Practice the split on a feature you know
Choose one AI feature used at work, or a public tool you can test in a sandbox. Write three lists: what the feature reads, what it writes or changes, and what it can call. Then mark each item as either covered by a classic skill you already have or as new. Most people find that the first two lists are mostly familiar, and the third is where the new skills belong.
Pick the single item marked new that would cause the most harm if it went wrong, and write one sentence describing the control that would stop it. If that sentence depends on the model behaving well, the sentence is not yet describing a control. That gap is the part of the job most worth developing first.
