Security is a habit, not a tool

We have been spending time on the offensive side lately - how attacks are actually built, including the ones that now have a model behind them. Much of it through TryHackMe, which is the most painless way we have found to learn this by doing rather than by reading.

What follows is the working list. The first half is for everyone, including the people in your company who will never read a security policy. The second half is for the people who build things. No sponsorships, nothing to sell - just the list we would give a friend.

If you are not technical, these six cover most of it

• Read the URL, character by character. Almost every convincing fake gives itself away in the address: a swapped letter, an extra word, a real brand sitting in a subdomain of somewhere else. The domain you want is the bit immediately before the first single slash, and nothing to the left of it is a promise.
• Hover before you click. Shortened links hide their destination by design. checkshorturl.com will expand one for you without visiting it.
• Search the sender. The company name plus "scam" takes ten seconds and resolves a surprising number of cases.
• Treat urgency as the signal. "Act now", "your account will be closed today", "the invoice is overdue" - manufactured time pressure is the one thing nearly every attack has in common, because thinking is what defeats it.
• Turn on two-factor authentication everywhere. An app-based code or a hardware key, not SMS where you have the choice. This single step defeats the overwhelming majority of password-based attacks.
• When unsure, ask. Paste the message into an assistant and ask whether it looks like phishing. It is good at this, and it costs nothing to check.

What changed when the attackers got AI

This is the part that has shifted most in the last two years, and it is worth stating plainly.

The old advice was to look for bad grammar and awkward phrasing. That advice is dead. A phishing email is now written in fluent Latvian, English or Russian, in your industry's vocabulary, referencing a real project, for approximately no cost. The tell you were trained to look for is gone.

Voice is going the same way. A short clip from a conference talk or a podcast is enough material to clone a voice well enough for a phone call, and "the CEO rang and asked me to move it today" is now a thing that happens to ordinary companies rather than a film plot.

So the habits that still work are the ones that do not depend on spotting a fake:

• Verify out of band. If a message asks you to move money or change bank details, you confirm it on a channel the message did not arrive on, using a number you already had.
• Agree in advance that nobody senior will ever ask for an urgent payment by message. Say it out loud, to everyone, so that refusing is the expected behaviour rather than an awkward one.
• Make it safe to be wrong. The reason breaches get expensive is the four hours between someone realising they clicked and someone being willing to admit it.

If you build software

• Zero trust as the default posture. No implicit trust from being inside a network. Authenticate and authorise per request, and give every service the narrowest permissions it can do its job with.
• Endpoint detection and response. EDR, or managed EDR if you do not have someone watching alerts - an unread alert is not a control.
• Static and dynamic analysis, plus dependency scanning, in CI. SAST, DAST and SCA running on every pull request, not quarterly. Most real vulnerabilities arrive through a dependency somebody added a year ago.
• Centralised logging, mapped to a known framework. SIEM plus MITRE ATT&CK turns "we have logs" into "we can answer what happened".
• Watch the cloud configuration itself. Cloud posture management plus mutual TLS between services. Far more incidents come from a misconfigured bucket or an over-permissive role than from anything exotic.
• Know what is in what you ship. An SBOM and signed updates. When the next widely used library turns out to be compromised, the only question that matters is whether you can tell in minutes if you are affected.
• Exercise it. Red team to find out, purple team to make sure the finding turns into a fix. An untested incident plan is a document, not a capability.

And one genuinely new category

If any part of your product uses a language model, you have an attack surface that did not exist in your last threat model: prompt injection. Anything the model reads - a web page, a PDF, a support ticket, a product review, an email - can contain instructions aimed at the model rather than at the user.

We treat it as the same class of problem as SQL injection, and the mitigations rhyme. Content the model reads is data, never instructions. Permissions belong to the user, not to the model, and are checked on the way out. Anything with a real consequence - sending, paying, deleting, publishing - gets a human confirmation that names what is about to happen. And the output of a model is treated as untrusted input to whatever consumes it next.

The failure mode here is not a crash. It is a system that does exactly what it was told, by someone who should not have been able to tell it anything.

What we build in, so it is not a habit anyone has to remember

The reason we called this post what we called it is that habits fail under deadline pressure. The parts that survive are the ones built into the pipeline, where skipping them is harder than doing them.

On projects we run, that means at minimum:

• Secrets never in the repository, and a build that fails if one appears.
• Dependency and vulnerability scanning on every pull request, blocking the merge rather than filing a ticket.
• Least privilege by default for every service account, reviewed when someone asks for more rather than granted and forgotten.
• Logs that are useful without being a liability - enough to reconstruct an incident, not so much that the log file is itself a data breach waiting to happen.
• Updates that are boring and frequent, because the alternative is a single terrifying upgrade every two years that nobody wants to be responsible for.

None of that is advanced. All of it is the difference between security being something a team has, and security being something a team keeps meaning to get around to.

And for what it is worth, the best home security system is still a dog. Just do not use the dog's name as your password.