Every few years the security profession gets told it’s about to be automated away. Scanners were going to replace pentesters, SIEMs were going to replace analysts, SOAR was going to replace responders. None of it happened, but each wave reshaped the job, and the people who came out ahead were the ones who worked out early which skills had become table stakes and which had become obsolete.
The AI wave changes both sides of the board at once. Attackers have the same models you do. The systems you protect now contain components whose behavior is a probability distribution rather than a function. And the tools in your hands can compress a week of work into an afternoon, provided you know how to drive them and how to check them.
This is not a product list. It’s the set of skills, habits, and mental models that separate the engineers gaining leverage from the ones quietly getting buried.
1. Agentic tooling as a first-class workflow
Being “good at AI” does not mean pasting a stack trace into a chat window. It means integrating agents into the parts of the job that are high-volume and low-judgment, and structuring the work so the agent can operate with enough context to be useful.
Concretely, the engineers getting real leverage are doing things like:
- Attack-surface enumeration from source. Point a coding agent at a monorepo with a written threat model and have it produce a table of every network listener, every authz check, every place user input reaches a shell, SQL, or template engine, with file and line references. Then diff that against the architecture diagram the team thinks is accurate.
- Detection engineering at volume. Give the agent a sample of raw telemetry plus an ATT&CK technique ID and have it draft the Sigma rule, the corresponding KQL/SPL/OSQuery translation, the unit-test log lines that should and shouldn’t fire, and the tuning notes. You review; you don’t type.
- Policy-as-code generation. OPA/Rego, Cedar, Kyverno, Sentinel, IAM policies with condition keys. Models are good at these because they’re small, well-documented, and heavily represented in training data. Have the agent generate the policy and a conftest/OPA test suite that exercises the deny paths.
- Document triage. A 400-page vendor SOC 2 report or a new NIST SP draft becomes a five-minute exercise: extract the controls that touch your data flows, list the exceptions, flag anything that contradicts the vendor’s security questionnaire answers.
The infrastructure for this is boring and important: a directory of context files describing your environment (ARCHITECTURE.md, TRUST_BOUNDARIES.md, LOGGING_SOURCES.md), reusable prompt templates checked into git, and MCP or equivalent tool servers that give the agent read access to your ticketing, code, and telemetry. Treat that scaffolding like the shell aliases and dotfiles you used to curate. It compounds the same way.
2. Verification as a non-negotiable step
Everything a model emits is a claim. The failure mode of AI-assisted security work is not that the model is usually wrong; it’s that it’s usually right, so the reviewer stops checking, and the 5% that’s wrong ships with the same confidence as the rest.
Build verification into the pipeline rather than relying on discipline:
- Detection rules don’t merge without replay against a labeled corpus. Keep true-positive and benign samples per rule and run them in CI. A rule with no test is a hypothesis, not a control.
- Vulnerability fixes don’t close without a reproduction. Have the agent write the PoC first (against a sandbox), confirm it triggers, apply the patch, confirm it doesn’t. If the fix was generated by a model, be especially alert to relocation: the injection moved from the query to the ORDER BY clause, the SSRF moved from the URL to the redirect target.
- Generated code goes through the same SAST/SCA/secrets scanning as human code, and you should assume the model reached for a plausible-looking but nonexistent package name at least once. Dependency confusion via hallucinated package names is a real supply-chain vector; pin, verify, and use a private registry with allow-listing.
- Cited facts get checked at the source. A model summarizing CVE-2026-XXXXX may be blending it with a neighbor. Pull the NVD/GHSA JSON and read the affected version ranges yourself.
A useful heuristic: for any artifact bound for production, write down the test that would prove it wrong. If you can’t articulate one, you don’t understand the artifact well enough to deploy it.
3. Threat modeling systems that contain a model
You almost certainly own AI components now, whether or not anyone told you: a support bot with access to the CRM, an internal assistant over Confluence and Jira, a coding agent with git push rights, a classification step in a data pipeline. These fail in ways OWASP-for-web doesn’t capture. The core concepts:
Prompt injection is a confused-deputy problem, not an input-validation problem. The model cannot reliably distinguish instructions from data, and every byte it ingests—tool results, retrieved documents, web pages, email bodies, calendar descriptions, filenames—is a potential instruction channel. You will not regex your way out. The controls that actually work are architectural:
- Least privilege on tools: an agent that summarizes email does not need
send. An agent that reads a repo does not need a network egress tool. - Separate the planner from the executor when actions are consequential, and gate irreversible actions (payments, deletes, external sends) on explicit human confirmation with the full action visible.
- Constrain outputs structurally (JSON schema, enum-only decisions, allow-listed tool arguments) so a hijacked model has a small action space.
- Treat retrieved content as tainted. Render it, don’t execute it; strip or neutralize markdown links and images in model output that could exfiltrate via URL parameters.
Tool permissions are the attack surface. Enumerate every tool an agent can call, the credentials it uses, and the blast radius if a single call is adversarially chosen. Read-email plus HTTP-fetch is an exfil primitive. Read-repo plus write-issue is a persistence primitive (poison a ticket the next agent reads). Map these combinations explicitly.
Retrieval leaks by construction. Whatever goes into the vector index can come out to anyone who can query it, regardless of the source system’s ACLs. Enforce authorization at retrieval time with the requesting user’s identity, not at indexing time with the service account’s. Test this by querying as a low-privilege user for content that only high-privilege users should see.
Model supply chain is a supply chain. Weights, adapters, fine-tuning datasets, system prompts, and third-party tool servers need provenance, integrity checks, and change control. A pickle-serialized model file is arbitrary code execution; prefer safetensors and verify hashes. A third-party MCP server is a remote code path with whatever permissions you granted it; review it like you’d review a dependency with network and filesystem access.
Non-determinism breaks binary pass/fail. A guardrail that blocked the jailbreak 200 times in testing will let it through in production at some rate. Evaluate controls with sample sizes and confidence intervals, log every model decision with enough context to reconstruct it, and put deterministic enforcement (allow-lists, rate limits, authz checks, DLP on egress) around the probabilistic layer rather than inside it.
You don’t need to train models. You do need to be the person who can draw the data-flow diagram, mark every point where untrusted text reaches the model, and explain how each one becomes an insider.
4. Fundamentals, because the surface layer is now free
Anything that was primarily recall or procedure has been commoditized. Knowing nmap flags, the OWASP Top 10, or how to write a basic YARA rule from memory no longer differentiates anyone.
What remains valuable is the layer the model reasons about poorly or hallucinates confidently:
- How the kernel actually enforces isolation (namespaces, cgroups, seccomp, LSMs) and where container escapes come from.
- What TLS guarantees and what it doesn’t; why certificate pinning breaks and why mTLS identity is only as good as the CA hierarchy behind it.
- How OAuth/OIDC token flows move through your stack, which tokens are bearer, where they’re logged, and which refresh paths lack binding.
- Why this heap overflow is exploitable under this allocator and that one isn’t; what mitigations (CFI, PAC, MTE, shadow stacks) actually change about the exploit chain.
- How your CI/CD trust chain works: who can modify pipeline definitions, what secrets are exposed at which stage, whether OIDC federation to the cloud is scoped to branch and repo.
Engineers with this depth get far more from AI tools because they can tell when the tool is wrong, ask the follow-up that matters, and push into territory the model handles badly. Engineers without it receive fluent output they can’t evaluate. That gap is widening.
5. Owning software, not just scripts
The bar has moved from “can you write a Python script” to “can you own a service.” AI makes producing code nearly free; it does not make producing maintainable, tested, observable code free, and security teams using agents to build tooling are discovering they now have a real software portfolio.
Minimum viable discipline for security engineering code:
- Everything in git, with code review even when the author is an agent and the reviewer is you.
- Tests that exercise the security-relevant paths, run in CI, with coverage on the deny/fail-closed branches specifically.
- Structured logging and metrics from day one. A detection pipeline you can’t observe is one you can’t trust.
- Dependency pinning, SBOM generation, and the same SCA you impose on product teams.
- Fail-closed defaults and explicit handling of the “model returned garbage” case in anything that calls an LLM.
Engineers who apply the same rigor to their own tooling that they demand from product engineering are the ones whose automation still works in six months.
6. A defensible, technical position on internal AI use
You’ll write the AI usage policy, or inherit one. Make it concrete enough to be enforceable and technical enough to survive contact with engineers:
- Data classification mapped to tool tiers. Which models and endpoints are approved for public, internal, confidential, and regulated data, and how that’s enforced (egress proxy, SSO-gated enterprise tenants, DLP on prompts).
- Agent identity and audit. Every agent action attributable to a human principal and a session, logged with the tool call, arguments, and result. If you can’t reconstruct what an agent did during an incident, it shouldn’t have write access.
- Code contribution rules. Agent-authored commits carry a trailer or signature; branch protection requires human review; no agent has direct push to protected branches or deploy credentials.
- Tool server governance. An allow-list of MCP/tool servers, reviewed like third-party integrations, with scoped credentials and egress restrictions.
The credible stance is neither blanket prohibition nor vendor trust. It’s proportionate controls per data class and blast radius, with logging good enough that you can answer “what did the agent do” in five minutes. Follow it visibly yourself.
7. Adversary assumptions recalibrated
The threat landscape hasn’t been transformed overnight, but several attacker costs have collapsed:
- Targeted phishing at scale. Per-recipient pretexts generated from LinkedIn, GitHub, and breach data, in native-quality language, at zero marginal cost. Any control relying on “attackers won’t bother personalizing for us” is weaker.
- Voice and video impersonation. Good enough to pass a casual verification call. Out-of-band verification for wire changes, MFA resets, and access grants needs a second, non-biometric factor.
- Exploit turnaround. Time from public patch to working exploit is shrinking as patch-diffing and PoC development get agent assistance. Re-examine your patch SLAs for internet-facing services with that in mind.
- Adaptive automation. Reconnaissance, credential stuffing, and lateral movement that adjusts to what it finds rather than following a fixed playbook. Static honeytokens and predictable decoys are less effective; behavioral detections that key on intent rather than specific commands hold up better.
The response is mostly about updating priors on attacker effort, then re-running your existing threat models with the new numbers. Very little of it requires new products.
8. Judgment, and the ability to transmit it
When findings, alerts, and recommendations can be generated faster than anyone can read them, the scarce resource is the person who can look at the pile and say: these three matter, that one is noise, and here is the one thing to do this week.
That judgment comes from understanding the business, the architecture, the adversary, and the real consequences of being wrong. Then you have to transmit it: to engineers who will fix things, to leaders who will fund things, to auditors who will check things, and increasingly to agents that will act on your written instructions. Precise, prioritized, defensible writing is now load-bearing.
Packing the kit
- Build agent workflows for enumeration, detection engineering, policy-as-code, and document triage, with checked-in context files and prompt templates.
- Put verification in the pipeline: replay corpora for detections, reproductions for fixes, SAST/SCA on generated code, source checks on cited facts.
- Threat-model AI systems as confused deputies: tool least-privilege, retrieval-time authz, tainted-content handling, supply-chain integrity, statistical evaluation of guardrails.
- Invest in fundamentals the model handles poorly: kernel isolation, TLS and identity flows, memory safety and mitigations, CI/CD trust chains.
- Run your security tooling as real software: git, tests, CI, observability, fail-closed defaults.
- Write an AI-usage policy specific enough to enforce: data tiers, agent audit logging, code contribution rules, tool-server allow-lists.
- Recalibrate attacker cost assumptions and re-run your threat models.
- Protect time for judgment and clear writing. That’s the part that doesn’t automate.
The job hasn’t been automated away. It’s been concentrated: less routine, more decisive. For engineers equipped for that shift, this is a very good time to be in security.