Breakout Time

The Problem with “Attackers don’t break in, they log in”

Wed, 02 Sep 2026 00:00:00 GMT

For some reason it has become socially acceptable to say:

“Attackers don’t break in, they log in” — Microsoft CISO, 2019

I take issue with this phrase because it is a misleading half truth. A more accurate version would be:

“Attackers don’t break in, they log in (after purchasing the ability to log in from an attacker who did break in)”

Nobody “just logs in” to your network. Not unless you’re a UNIX terminal and the year is 1988. To log in you need credentials; typically a password, an API token, or a browser session token — at minimum. These have a distinct characteristic of not spontaneously appearing out of thin air. So where do they come from?

Well, attackers can make educated guesses about what your password might be — based on commonly used password structures e.g. surname followed by the last two digits of your date of birth. Or, they can do an exhaustive search of all the possible passwords you could’ve chosen from. Or, they can take a list of known common passwords and try all of those. There are many ways. But the important point is, these methods are as old as computers themselves — arguably related to the very reason why computers were invented in the first place — I digress.

What is new, relatively speaking, is the industrialisation of the cyber crime economy. It comprises supply chains where each participant provides a service to the next — for a fee.

The criminal who “just logged in” purchased credentials from an Initial Access Broker, who was sold the credentials by someone else.

The other person will be indiscriminately harvesting large quantities of credentials by infecting as many hosts as possible with info-stealer malware.

To do this they had to “break in”.

You see, someone had to break in to steal the creds. It may not be the same person who ultimately uses the creds, but someone had to break in nonetheless.

For the sake of completion, the info-stealer malware may well have been licenced or purchased from a Malware-as-a-Service provider, customised and then delivered to your mailbox using a commodity Phishing kit.

As a defender, it generally makes little difference who is doing what in this story. You are still interested in the same things you have always been interested in i.e. detecting initial access, execution, privilege escalation and credential access. What you’re not going to do is abandon this and focus entirely on monitoring for credential abuse in your cloud environments. If all you are looking for is the latter then it’s too late.

The Real Barrier to Machine-Speed Defence

Tue, 25 Aug 2026 00:00:00 GMT

Machine-speed attacks require machine-speed defence. It’s that simple.

Put the best trader in the world up against a high-frequency trading algorithm and ask them to compete on speed. The human loses before they have even registered that the price moved.

Cyber defence has the same problem. You cannot match machine-speed attacks with humans operating at a speed determined by caffeine, office noise, and the number of “important” meetings sitting in their calendar.

Humans are the latency.

Machine-speed defence means taking them out of decisions that involve competing against machines.

And this is where things get awkward.

The obvious answer is to let machines investigate, decide and act.

Except the moment you try to do that, you expose an inconvenient truth. Every generation of SOC analysts has been quietly compensating for a fundamental weakness in the way security gets done. They have been carrying your organisation and nobody realised.

I can say with a high degree of confidence that your security policies are not ready to direct agents.

Let me show you why.

It is 02:00 and your customer database is leaving the building

One of your privileged database administrator accounts has started exporting a large volume of customer data from production to a system it has never touched before.

Your security agent is watching it happen.

It has already done the investigation.

The account is privileged. The destination is unusual. The volume is abnormal. The activity came from an administrative host. Nothing similar has happened in the last six months.

You probably want it stopped.

Except there is a major database migration happening tonight.

Fine.

Check the change record.

There is one.

It is approved.

Unfortunately, the destination in the change record is not the destination your customer data is currently heading towards.

Now what?

Kill the export?

Disable the DBA account?

Isolate the server?

Keep watching?

Ask somebody?

That last answer is what we normally do.

And that is exactly why this is not machine-speed defence.

The machine has already done the security investigation. The thing stopping it now is not telemetry, correlation or reasoning.

It does not know what you want it to do.

Machine-speed defence is really policy enforcement

Agents are goal-driven systems.

That matters more than it sounds.

In security, the goal is not simply “Stop attacks”.

If it were, this would all be much easier. Disable every suspicious account. Isolate every suspicious server. Block anything unusual.

You would have excellent containment metrics and possibly no functioning business. Bravo.

Your organisation has already made choices about which risks it accepts, which systems matter most, which interruptions are tolerable, who is allowed to do what, and when security is allowed to intervene.

We do not usually describe those choices as goals.

But that is effectively what they are.

Security policy encodes the organisation’s goals for managing risk.

Once you remove the human from the decision, this becomes very obvious.

Your machine-speed defensive system is, in effect, a security policy enforcement system.

The investigation tells it what is happening.

Policy tells it what should happen next.

That is the part we are not ready for.

“Check whether it is authorised” is not enough

The obvious instruction is: “Check whether the activity is authorised.”

Great.

What does authorised mean?

Does an approved migration allow any database administrator to export the data?

Does the source database have to match the change?

Does the destination?

Does the DBA need to be explicitly named?

What if the migration runs an hour late?

What if the original destination fails and the infrastructure team switches targets halfway through?

What if that change was approved in Teams but nobody updated the ticket?

A human can cope with this.

Your analyst sees the approved migration, recognises the database team, messages somebody and discovers that the target changed twenty minutes ago because the original one failed.

They close the alert.

Perfectly reasonable.

They probably did not read your privileged-access policy first.

They may not know where it is.

That does not stop them making the decision.

This is where the real problem starts.

Most SOCs run on policy-as-lore

SOC analysts make security decisions every day without consulting formal security policy.

They still somehow know what to do.

They know the infrastructure team uses a tool that looks suspicious but appears every patching weekend.

They know a particular service account looks horrifying in the logs but belongs to an essential overnight process.

They know you technically can isolate a certain production server, but doing so without calling the service owner first would be career-limiting.

Where is that policy?

Some of it is in IAM.

Some is in the CMDB.

Some is in the change system.

Some is in runbooks.

Some comes from old incidents.

Some was explained in a Teams conversation eighteen months ago.

Some exists entirely inside the heads of experienced analysts.

Some of it may be walking out the door.

SOCs do not operate on policy-as-code.

They operate on policy-as-lore.

And, for the most part, it kind of works.

Humans are exceptionally good at taking incomplete records, local knowledge, precedent, conversations and vague rules and turning them into a decision.

We call that experience.

For a machine, it is missing state and missing rules.

That is why a senior analyst can resolve something in five minutes while a new hire new spends forty minutes working out who to ask.

The senior analyst is not just better at reading logs.

They know the lore.

That becomes a serious problem when you want the decision in seconds.

Machine-readable is not decision-complete

There is an obvious response to this.

Make the policy machine-readable.

Good. You should.

But do not confuse representation with decision-making.

Take a perfectly normal policy statement: “Privileged access must only be used for authorised business purposes.”

You can put that in YAML, JSON, Rego or anything else you like.

The machine can parse it perfectly.

It still has no idea what to do.

Who is authorised?

Authorised by whom?

For which systems?

For which actions?

For how long?

Which system proves that authorisation?

What happens when IAM and the change system disagree?

How fresh does that information need to be?

What happens when the required information is unavailable?

And if the policy has been violated, what is the machine actually allowed to do about it?

That is the difference between machine-readable and decision-complete.

A decision-complete policy contains enough information for the machine to reach the operational decision without handing the difficult bits back to a human.

For our database migration example it might need something more like:

An approved migration is currently active.

The source database is within its scope.

The destination is within its scope.

The identity performing the export is authorised for it.

The activity falls within the approved time window.

No current security restriction overrides that approval.

Now the machine has something it can evaluate.

We did not make the AI smarter.

We made the decision explicit.

Policy-as-code solves the representation problem.

Machine-speed defence requires you to solve the decision problem.

The speed comes from making decisions earlier

Go back to the database export.

The alert fires.

Only then does the analyst start finding the information needed to make the decision.

Who owns the database?

Is there a migration?

Who approved it?

Which destination was approved?

Is this DBA authorised?

What happens if we stop the transfer?

Who is allowed to make that call?

The machine can collect the security evidence in seconds and still end up waiting while a human works through those questions.

That is where much of the latency actually lives.

If you want the decision in seconds, you need to settle more of those questions before the incident.

Define what counts as an authorised migration.

Define which system proves it.

Define how closely reality must match the approval.

Define how current that approval needs to be.

Define what happens when information is missing.

Define which actions security is allowed to take without asking anyone.

Then the event happens and the machine evaluates decisions you have already made.

That is where the speed comes from.

Not because AI develops some supernatural understanding of your company.

Because you stop asking a human to resolve the same ambiguity every time something suspicious happens.

Your runbook probably contains more lore

You may think your runbooks already solve this problem. Guess again.

Open one.

You will probably find something like:

1. Determine whether the activity is authorised.
2. Check for an approved change.
3. Assess business impact.
4. Contain if appropriate.

That is entirely reasonable guidance for a human.

It is also nowhere near decision-complete.

What counts as authorised?

Which change states count?

How closely must the observed activity match the ticket?

How do you assess business impact?

When is containment appropriate?

The difficult decisions are still hidden inside normal English.

A runbook tells a human where to apply judgement**.**

It does not remove the judgement.

Making the runbook machine-readable does not resolve the problem either.

You now have a machine-readable instruction saying: “Contain if appropriate.”

Wonderful.

The agent still needs you to decide what appropriate means.

And then the change system goes down…

Our database migration is still running.

The source database matches the approved change. Check.

The administrator matches. Check.

The destination does not. Uh oh!

The agent tries to check whether the change was updated.

The change platform is sadly unavailable.

The agent’s last copy of the ticket is six hours old.

What should it conclude?

There is a dangerous shortcut here.

This:

I cannot confirm this activity is still authorised.

quietly becomes:

This activity is unauthorised.

Those are not the same statement.

If your IAM feed goes down, every administrator does not suddenly become an attacker.

If your change platform stops responding, every maintenance process does not suddenly become malicious.

Once machines start enforcing policy, that distinction matters, a lot.

You need a third outcome:

ALLOW

DENY

ABSTAIN

Abstain is a security control.

The machine is saying: “I do not have enough reliable information to make this particular decision safely.”

It can keep investigating.

It can collect more evidence.

It can escalate.

It may still take low-impact actions that do not depend on the missing information.

What it should not do is manufacture certainty because ServiceNow suddenly stopped returning its calls.

That means freshness itself becomes part of the decision.

How stale can an approval be before you stop trusting it?

How current must privilege information be before a machine disables an account?

How old can asset information be before automatic isolation is allowed?

Your AI vendor cannot answer those questions.

You have to.

Fine. The account is compromised

While the export continues, the agent finds something else.

The DBA account authenticated from a host it has never previously used.

That host triggered a credential-theft detection ten minutes earlier.

It is now probing other production systems.

Let us remove the uncertainty.

Assume the agent is right.

The account is compromised.

Can it disable it?

Maybe.

You still have two separate questions to answer:

1. Has security policy been violated?

2. What are you authorised to do about it?

The machine can know an attack is happening and still not have permission to stop it.

Perhaps terminating the database export halfway through risks corrupting the migration.

Perhaps the administrator account is also supporting an emergency recovery process.

Perhaps this system is so critical that isolation requires approval from the service owner.

Whether those are sensible boundaries is beside the point.

They are your boundaries.

Even when the agent knows it is an attack, it still needs to know whether you have authorised it to act.

Machine-speed defence therefore needs delegated authority.

What may the machine kill?

What may it isolate?

Which identities may it disable?

Under which conditions?

How much uncertainty is acceptable?

When must it abstain?

Which decisions do you deliberately keep for people?

“Human in the loop” is not an answer.

It is often just a polite way of saying we have not worked this out yet.

This is where generic security agents hit the wall

A vendor can give you an extremely capable agent.

It can query your EDR.

Inspect identity history.

Correlate network and endpoint events.

Follow an attack across cloud and on-premise systems.

Reconstruct what happened faster than your analysts.

Excellent.

What it cannot ship in the box is the answer to our database migration.

It does not know that the migration is happening.

It does not know what tonight’s approval actually covers.

It does not know whether a Teams message counts as emergency authorisation.

It does not know how stale your change data may become before the machine must abstain.

It does not know what happens to the business if it kills the export.

And it does not know what authority you have delegated to security.

Those are not missing AI features.

They are properties of your organisation.

The investigation machinery can be generic.

The decision model cannot be.

You can let the agent learn what your analysts normally do.

That may be useful.

But now you are teaching it policy-as-lore by observation, complete with undocumented exceptions, inconsistencies and bad habits.

Or you can make it ask a human whenever things become unclear.

Congratulations.

Your machine-speed defence is now waiting for somebody to reply on Teams at 02:00.

Do not turn lore into bureaucracy-as-code

There is a horrible possible conclusion to all this.

Someone decides the answer is to formally specify every legitimate thing every person and machine in the company is allowed to do.

Please don’t.

You will create bureaucracy-as-code and still fail.

People improvise.

Systems break.

Emergency changes happen.

Attackers do things you did not anticipate.

Some decisions genuinely need judgement.

Keep humans for those.

The goal is not to eliminate runtime judgement.

It is to stop wasting runtime judgement on decisions you make repeatedly.

If analysts always ask whether the same activity is covered by an approved change, expose that information to the agent.

If the same exception is approved every month, decide what the rule actually is.

If every investigation requires someone to ask who owns a system, then fix the system that should already know the answer to the question.

Turn the useful parts of policy-as-lore into decision-complete policy.

Leave the genuinely weird cases to people.

Pull 100 investigations on Monday morning

I would not start by giving an agent permission to isolate production servers.

Start with 100 completed investigations.

For each one, ask:

What did the analyst need to know that the security telemetry did not tell them?

Maybe it came from IAM.

Maybe a change ticket.

Maybe asset ownership.

Maybe Teams.

Maybe the analyst just knew.

Then ask: “Could we have known this before the incident?”

If yes: “Can we express the decision precisely enough for a machine to evaluate it?”

Then: “Is the underlying data fresh enough to rely on?”

And finally: “If the machine reaches the answer, have we authorised it to act?”

Those questions will expose your real machine-speed defence backlog.

Some of it will be telemetry.

Some will be integration.

Some will be data quality.

I.e. engineering work.

However, a lot of it will be decisions that have lived as lore for years because humans were good enough at filling in the gaps.

Sooner or later the drive for machine-speed defence will inevitably expose the underlying issue for all to see.

The real barrier is not machine speed

We already have fast machines.

Detections fire in seconds.

We collect absurd quantities of telemetry.

Agents can investigate faster than humans ever will.

That is not the hard part.

The hard part is getting from: “Something bad appears to be happening.”

to: “Given what we know right now, this is the action we have already decided an agent should take.”

That is a policy-enforcement problem.

The telemetry tells the machine what happened.

The agent reasons about what it means.

But ultimately, policy tells the machine what the organisation wants done about it. See, I told you it was about goal setting, didn’t I?

In conclusion. Policy needs to be machine-readable and it needs to be decision-complete.

It needs to tell the machine what matters, where the facts come from, how fresh they need to be, when uncertainty means abstain, and what authority you have actually delegated.

And before you can do any of that, you have to find the real policy.

Not the PDF. The policy your SOC actually runs on.

The exceptions, precedent, operational knowledge and unwritten rules your analysts use every day.

The policy-as-lore.

Until enough of that becomes decision-complete, humans stay in the critical path.

Not because the machines are too slow.

Because the organisation has not yet told them, precisely enough, what it wants them to do.

Stop Chatting, Start Working: Unlearning Your AI Bad Habits

Sun, 09 Aug 2026 00:00:00 GMT

You open Microsoft Copilot, ChatGPT or Claude. You ask it to summarise a document, rewrite an email, analyse some figures or explain something unfamiliar. It replies. You add more background. The answer improves because the model now has more information about what you are trying to do.

Then somebody gives you access to Claude Code, GitHub Copilot, OpenAI Codex or one of Google’s agentic coding tools.

The interface looks reassuringly familiar. There is a box. You type instructions into it. Results come back.

But the thing behind the box has changed.

An agentic coding tool can open files, search a repository, write code, run commands, inspect errors, execute tests and keep working through intermediate steps without asking you to perform each one yourself.

Suddenly that tedious manual process looks automatable. You can build the little internal tool nobody has had time for. You can turn a recurring spreadsheet ritual into a script. You can wire together APIs, process thousands of files or finally make the website you have been threatening to build for six years.

You also inherit a completely different class of failure.

A bad workplace AI conversation might waste ten minutes. A badly managed coding session can read dozens of files, make changes across a repository, generate mountains of command output and consume a surprising amount of model usage before confidently telling you that everything is finished.

The problem is that the interface still encourages you to behave as though you are chatting with it.

Stop.

Many of the habits that ordinary workplace AI has taught you are actively unhelpful once the AI can do work.

The first habit to unlearn is the instinct to keep every conversation forever.

First, understand what you are actually using

People casually call products such as Claude Code and Codex “coding agents”. That is convenient, but it hides a distinction that becomes important once you start wondering why context behaves the way it does.

At the bottom is the LLM, the Large Language Model: the enormous neural network running somewhere in a data centre on enough hardware to lend credibility to the theory that Nvidia CEO Jensen Huang was sent back from the future with knowledge of an impending GPU shortage.

The model takes some input and produces some output.

Around that you can build an agent: a goal-directed loop that repeatedly asks a model what to do next, gives it access to tools, observes the results and continues until some stopping condition is reached.

Around the agent sits a harness: the ordinary software responsible for making the whole thing useful.

The harness decides what information to give the model. It exposes tools. It executes commands. It reads files. It stores state. It applies permissions and guardrails. It decides what to preserve between model calls and what to discard.

If you are familiar with software test harnesses, the idea is similar. A unit test does not stand up its own fixtures, organise a test run and collate the report. Other software does that around it.

This distinction explains something that is easy to miss when the interface looks like a chat window:

the model is not wandering around your computer carrying a mental representation of your project.

The harness repeatedly assembles the information the model needs and places that information into its context.

And context is where things start getting expensive.

Context is working memory, not a filing cabinet

When you use ChatGPT, Claude or Copilot in an ordinary conversation, it feels as though the AI remembers what you told it.

What is actually happening is less magical.

For each new inference, the application gives the model the relevant conversation and any other information it needs. That may include earlier messages, system instructions, retrieved documents, tool results and summaries of material that no longer fits comfortably into the available context.

The model has not secretly trained itself on your conversation. The application is giving it the information again.

All of that information occupies the model’s context window.

For ordinary workplace chat, this can stay manageable for quite a while.

Suppose you have a reasonably substantial conversation containing about 3,000 words. That might amount to roughly 4,000 tokens.

A token is simply one of the units in which LLM input and output are measured. The conversion between words and tokens varies, but the exact number is not important here.

Now compare that with code.

Imagine a modest project containing 30 source files averaging 150 lines each. If those lines average around eight tokens, the source alone contains roughly:

30 files × 150 lines × 8 tokens = 36,000 tokens

Already about nine times our substantial workplace conversation.

And source code is only part of what an agentic coding session may need.

The harness can also feed the model your instructions, specifications, configuration, search results, documentation, test code, compiler errors, stack traces and shell output.

One failed build can generate thousands of tokens in seconds.

The agent then searches for the cause, reads another five files, calls the model again, edits the code, reruns the tests and feeds the new results back into the process.

You might have typed:

Fix the login bug.

Those four words can initiate tens of thousands of tokens of model activity.

This is why counting prompts tells you almost nothing about how much work an agentic tool is actually doing.

More importantly, it explains why preserving one enormous coding conversation is usually a bad idea.

Stop trying to preserve one immortal conversation

Ordinary AI chat rewards continuity.

You spend half an hour explaining a problem. The conversation gets better as you add information. Starting again feels wasteful because you would have to reconstruct everything the model needs to know.

That trains you to value the conversation itself.

Agentic coding sessions accumulate a different kind of material.

Imagine you are building a small arcade game. First you implement player movement. Then enemies. Then scoring.

During those jobs the agent searches the repository, reads files, encounters failed tests, follows dead ends, tries an approach you reject, fixes bugs in its first attempt and discusses features you ultimately decide not to build.

Eventually you start the next piece of work.

Your session now contains two very different things:

information about the current state of the project;
the entire history of how you arrived there.

The first is useful.

Much of the second is not.

Yesterday’s stack trace does not become more valuable because you keep sending it back to the model. Neither does the abandoned implementation, the solved bug or the discussion about a feature you decided against.

Treat the conversation as working memory, not project storage.

When a coherent piece of work finishes, extract the knowledge that needs to survive.

Then clear the working context.

If clearing the conversation would destroy an important project decision, that decision is stored in the wrong place.

Put project knowledge in the project

You do not need an elaborate knowledge-management system.

Markdown files in the repository are enough.

For a small project:

docs/
decisions.md
specs/
scoring.md
multiplayer.md

Suppose you decide to use SQLite instead of storing application state in JSON files.

Put that decision somewhere durable:

# Save-game storage
Decision: Use SQLite.
Reason: We need structured queries and reliable updates across related records.
Rejected: JSON files, because concurrent updates would require additional locking logic.

Notice what you are preserving.

Not the twenty-minute argument with the model.

The outcome.

The reasoning somebody will need later.

And, where useful, the rejected alternative that somebody will inevitably suggest again six months from now.

The same principle applies to different kinds of project knowledge.

A project-wide architectural decision belongs in a decision record.

The behaviour of a feature belongs in its specification.

A requirement the software can verify belongs in a test.

A standing instruction that changes how an agent should work across the repository belongs in something like CLAUDE.md, AGENTS.md or .github/copilot-instructions.md.

Put information in the narrowest durable place that naturally owns it.

Do not turn your project instruction file into the repository’s attic.

If the database choice is in CLAUDE.md, every agent task may have to carry that information whether it needs it or not. If the scoring rules are buried there too, and then the API design, deployment history and meeting notes, you have simply recreated the immortal chat session as a Markdown file.

Project instruction files are context too.

Keep them focused on instructions the agent repeatedly needs.

Do not let ambiguity quietly become architecture

Workplace chat is unusually tolerant of vague instructions.

You can write:

Make this email more professional.

The model makes some stylistic choices. You read the result and decide whether you like them.

Software is less forgiving because ambiguity becomes behaviour.

Suppose you tell an agent:

Add a dash ability to the game.

That sounds perfectly reasonable until you ask what “dash” actually means.

Does the player become invulnerable?

Can they dash through enemies?

How long is the cooldown?

What happens when they hit a wall?

Can they dash in mid-air?

Can they change direction during the dash?

If those decisions are absent, the model still has to produce something.

So it makes assumptions.

The danger is not merely that one assumption might be wrong.

The assumption becomes code.

Then tests may be written around it. Other features may depend on it. APIs may expose it. Save data may encode it.

A vague requirement has now become project state.

The chain looks like this:

ambiguity → assumption → implementation → dependency → expensive reversal

So resolve important ambiguity before implementation.

You do not have to become clairvoyant and write a perfect specification upfront. You do need to make unanswered decisions visible.

This is where requirements-elicitation workflows become genuinely useful.

Some agentic setups provide Skills or commands designed specifically to interrogate a vague idea before implementation. They ask the annoying questions a competent business analyst, developer or solutions architect would ask.

Good.

Let them be annoying now.

It is cheaper than discovering the missing requirement after the database schema, API and UI all depend on the wrong answer.

Once those questions are resolved, move the result out of the conversation and into the specification.

Then implementation can begin.

Turn specifications into bounded jobs

A specification can still be too large to hand to an agent as one enormous instruction.

Break it into coherent tasks.

Think Jira tickets, except they can just as easily be Markdown files in a tasks/, tickets/ or issues/ directory.

Each task should let the agent answer three questions:

What should change?
What constraints must remain true?
What evidence proves the task is complete?

That third question is the one people most often forget.

“Implement authentication” is a task description.

“Implement authentication, preserve the existing session API, reject expired credentials, pass the authentication test suite and introduce no new linter errors” is a job the agent can actually reason about completing.

Clear boundaries reduce the amount of repository the agent needs to consider and reduce the number of decisions it has to invent.

You are not trying to describe the entire project every time you ask for work.

You are creating the smallest useful envelope around the job.

Keep noisy exploration away from implementation

Agentic coding tools spend a remarkable amount of time finding things.

Ask for one small change and the agent may search the repository, open twelve files, chase a reference into a dead end, read old tests and inspect configuration before discovering the two facts it actually needed.

Imagine that investigation consumes 20,000 tokens but the useful result is:

Authentication is handled in auth/session.py.
The current user is available through request.user.

The implementation task needs those facts.

It does not need the other 19,900 tokens of exploration.

This is one reason subagents can be useful.

Give a separate agent a noisy investigative task and let it return a compact result:

Investigate how authentication works. Return only the components that need modification, the relevant tests and any constraints the implementation must preserve.

The exploration happens in one context.

The findings move into another.

That suggests a broader rule:

match the lifetime of the context to the lifetime of the information.

Repository exploration may only be useful for five minutes.

Implementation context may need to survive for the duration of one ticket.

Architectural decisions may need to survive for years.

Tests may remain useful for the lifetime of the software.

Do not keep all of those things in one bucket simply because a chat interface makes that convenient.

Make the machine prove it worked

With ordinary workplace AI, you are usually the verifier.

Copilot drafts an email. You read it.

Claude summarises a document. You compare the result with the source.

Agentic coding gives you an opportunity to automate part of that verification.

This is where Test-Driven Development suddenly starts looking rather fashionable again.

Suppose our dash feature has four requirements:

The dash has a one-second cooldown.
The player cannot dash through walls.
Existing movement still works.
Automated tests cover the new behaviour.

Now the agent has something better than a vague notion of completion.

It can change the code, run the tests, inspect failures, modify the implementation and run them again.

The important principle is broader than TDD.

Before handing over substantial work, ask:

What observable result would demonstrate that this works?

Then give the agent access to that check wherever possible.

That might mean:

unit tests;
integration tests;
a successful build;
type checking;
linting;
an API request with an expected response;
comparison against a known fixture;
a performance threshold;
generated output that can be inspected automatically.

The mechanism depends on the task. The principle does not.

If the only evidence that the work is complete is the model saying “done”, you have not verified the work.

You have received a status update from the thing whose work you are supposed to be checking.

Separate implementation from review

Suppose an agent spends a substantial session implementing a feature.

During that session it sees every assumption, failed attempt, workaround and correction involved in producing the final code.

Then, at the end, you ask:

Review your work.

That is better than nothing, but it is not much separation between implementation and evaluation.

For complex or important changes, start a clean session.

Give the reviewer:

the specification;
the resulting code changes;
the test results;
any constraints that should have been preserved.

Then ask it to find requirement violations, missing cases, unnecessary changes and questionable assumptions.

The clean reviewer has not followed the implementation process step by step. It sees the result against the requirements rather than inheriting every justification made along the way.

This does not magically make the reviewer unbiased.

It simply removes one source of correlated reasoning between the person — or model — that created something and the process used to evaluate it.

Software engineering discovered a long time ago that separating generation from evaluation tends to be useful.

Agentic coding has not repealed that idea.

Use project instruction files for instructions

Sooner or later you will encounter files such as:

CLAUDE.md
AGENTS.md
.github/copilot-instructions.md

These are project instruction files.

Compatible tools load them to understand how they should work inside the repository.

Useful contents might include:

how to run the tests;
which package manager the project uses;
directories that contain generated files and must not be edited manually;
formatting or naming conventions that apply across the codebase;
important commands an agent needs repeatedly.

Ordinary project knowledge does not belong there merely because the agent reads the file automatically.

A decision to use OAuth rather than local passwords is a project decision.

The instruction “never manually edit files under generated/” changes how the agent should behave on many tasks, so that belongs in the project instruction file.

Again, context has a cost.

A bloated instruction file gets dragged into work that may have nothing to do with most of its contents.

Do not solve context management by creating a giant file that automatically pollutes every new context.

What I would do on day one

Pick a real project you care enough about to finish but can afford to break.

Build a tiny game.

Create a personal website.

Automate some tedious admin.

Write a little utility that saves you ten minutes every week.

Then use the agentic coding tool for one clearly bounded task and actually watch what it does.

Notice which files it reads.

Watch the commands it executes.

Look at how much output a failed build produces.

Notice how much activity can follow from one short instruction.

Create a docs/ directory early.

Give project decisions somewhere durable to live.

Give substantial features specifications.

When a conversation produces information the project needs to remember, move that information into the repository.

Before implementation, resolve the decisions that would otherwise be guessed.

Break larger specifications into bounded jobs.

Give each job observable completion criteria.

Use separate contexts for noisy investigation where it helps.

Run automated checks.

Review important changes from a clean session.

Then clear the old working context and move on.

Only add elaborate Skills, subagents, orchestration frameworks and multi-agent workflows once you have experienced the failures they actually prevent.

Do not begin by constructing an artificial intelligence bureaucracy around a three-file Python project.

Learn the failure modes first.

The habit that actually needs to change

Workplace AI taught us to treat the conversation as the product.

We keep adding context, refining instructions and preserving the thread because the thread is where the useful information lives.

Agentic coding changes that relationship.

The project now exists outside the conversation.

The code exists outside it.

The specifications exist outside it.

The decisions exist outside it.

The tests exist outside it.

The conversation is temporary working space around those things.

Once you understand that, most of the other advice stops looking like a collection of arbitrary best practices.

Of course you clear old sessions.

Of course decisions need a durable home.

Of course tasks need boundaries.

Of course noisy investigations can be isolated.

Of course the agent needs a way to prove its work.

You are no longer trying to maintain the perfect conversation.

You are trying to get work done reliably.

The C2 Trap

Tue, 17 Mar 2026 00:00:00 GMT

Start at the Beginning. Not at the End

“Let’s start at the very beginning. A very good place to start.”

That applies to detection engineering too.

Time and time again I’ve seen security teams prioritise command-and-control (C2) and data exfiltration far too early. These are serious attacker actions. They feel important. They sound advanced. They seem like the kind of thing a good SOC should be doing.

For most teams, this is a mistake.

I do not think most detection programs should start by trying to detect C2 or exfiltration. In fact, I think many teams should not spend much time on them at all until they have built stronger coverage elsewhere.

Why? Because C2 and exfiltration are hard problems.

Pick Your Battles

The first mistake that teams make is to treat C2 and exfiltration as if they are specific behaviours. They are not. They are outcomes.

The attacker’s goal is to establish a reliable outbound path, or to get data out of your network by any means necessary. That can mean HTTPS, DNS, cloud storage, remote admin tools, SaaS platforms, email, collaboration tools, or traffic that appears indistinguishable from ordinary business activity.

The attacker only needs one working method.

The defender has to spot all plausible methods.

That is the trap.

(cliché narrowly avoided, phew)

This is an asymmetry problem. The defender must cover a huge space. In a large enterprise, with high volumes of business traffic, user behaviour, and a multitude of endpoint software producing endless noise, that is not a battle that most teams are going to win.

Yes, some organisations might be able to do this with highly restrictive egress controls, telemetry from a broad spectrum of network protocols, and non-trivial machine-learning-based analytics. But most teams do not have that. Even if they do, C2 and exfil remain some of the hardest detection problems to solve. Why would any sane person choose to start there?!

If someone has miraculously “solved C2” then they are keeping very quiet about it. Given that such a person would almost certainly become an over night millionaire, I think it’s safe to say the game remains firmly afoot.

Focus on High Signal

Attacks do not begin with stealthy outbound traffic. They begin with, well, initial execution, persistence, credential access, lateral movement. Activities that tend to result in relatively stronger detection signals than C2 and exfil.

For example. Before an attacker can establish a stable C2 channel or exfil your customer data, they need to do things like:

execute suspicious binaries or scripts
abuse Office, browsers, or script interpreters
tamper with security tooling

These are much better starting points because there is far less scope for variation. Theoretically there are infinite ways you can do C2, whereas there are a finite number of ways to dump creds from LSASS. Finite and ever-growing, but finite nonetheless.

A good starting detection is one that gives you a strong signal, clear investigative value, and a realistic chance to intervene before the damage is done.

Too Little Too Late

Its not just that C2 and exfil are hard. It is that they are too late.

If your first meaningful alert is C2, the attacker has already executed code and established control. You have bigger problems to worry about.

If your first meaningful alert is exfiltration, the attacker may already have gained access, obtained credentials, moved laterally, reached important systems, collected data, staged it, and started moving it out. You definitely have bigger problems to worry about.

At that point, you will not be asking, “Can we detect this?”

You will be asking, “Why are we only detecting this now?”

That is not a good place to be.

The kill chain matters, because detection is in part a timing problem. The later you detect, the worse things get. With exfiltration, the data loss event may already have happened.

This does not make late detections useless. It makes them weak candidates for your first and best line of defence.

Where Most Teams Should Start

A team with weak coverage of suspicious execution, credential access, and lateral movement should not be spending their efforts trying to infer beaconing activity from marginal network signals across a noisy environment.

A good detection program asks simple questions first:

Where is the signal strongest?
Where are attacker options narrowest?
Where can we investigate with confidence?
Where can we detect earlier?
Where can we still change the outcome?

For most teams, the answer is not C2.

Focus your efforts on areas like:

suspicious execution chains
script interpreter abuse
Office or browser child-process anomalies
abuse of admin tooling
credential access
interactions with LSASS
authentication anomalies
privilege escalation
remote execution
lateral movement primitives
security control tampering

These are not trivial detection problems. However, they are usually better detection problems. They are more tightly bounded and more likely to catch an attacker while they are still forced to do something noisy or unusual.

Jumping straight to C2 means placing your bets on catching the attacker at one of the quietest, most flexible stages in the kill chain.

Someday, Somehow

I am not saying C2 and exfiltration detections are worthless.

They are not.

In restricted environments, crown-jewel enclaves, mature programs, or networks with tight egress control and rich telemetry, they can be useful. In some cases essential.

But they should be regarded as the roof not the foundations.

For most teams, they are a poor starting point. They are not where the early returns are. They are not where the analyst learns fastest. They are not where the defender has the advantage.

Start at the Beginning

C2 and exfiltration are tempting because they sit close to the attacker’s objective. But that is exactly why they are such dangerous starting points. By then the attacker has more options, more cover, and less need to behave in ways you can reliably spot.

Start earlier.

Detect initial execution.
Detect credential access.
Detect lateral movement.

Because if your first alert is “elvis.dit has left the building” then its so long, farewell
auf wiedersehen, goodbye.