Continuous Defense: Start Small. Build Confidence. Accelerate the Scale.

How smaller AI models, trusted agent skills and local infrastructure can change the economics of cybersecurity.

I've spent a lot of my career finding vulnerabilities, running security operations and managing the risks we couldn't get fixed.

We always knew there were more weaknesses in our environments than we could find, investigate or remediate. The constraint wasn't a lack of tools or understanding. It was time, money and engineering capacity.

So we prioritised. We accepted risks. We deferred fixes until the next release.

As I argued in Low Likelihood Is Not a Control, a lot of those decisions depended on assumptions about how much effort an attacker would spend finding and exploiting a weakness.

AI is changing that calculation.

But here's the interesting part. The same economics changing the attacker's advantage are now available to defenders.

And we don't need to deploy enormous AI platforms or send our production environments off to external models to benefit.

We can start small, inside our own infrastructure.

Continuous assurance versus continuous defense

These are related, but I think we need to distinguish them.

Continuous assurance asks: Are our controls working, and can we prove it?

It collects evidence, evaluates configurations, measures control effectiveness and detects drift against our expected security posture.

Continuous defense asks: What weaknesses exist, how could they be exploited together, and what are we doing to reduce that exposure?

It takes us beyond continuously assessing controls into continuously investigating, validating and addressing weaknesses.

The operating loop becomes:

Observe → Discover → Investigate → Validate → Defend → Verify → Learn

This isn't an entirely new security discipline. Continuous monitoring, exposure management, vulnerability assessment and automated response have existed for years.

What changes is how widely, frequently and economically we can apply them.

And the ability to make that investigation specific to our actual applications and infrastructure.

What I'm doing with krnali Ops

I've been building krnali Ops around a relatively simple idea.

Rather than continually throwing more dashboards at operational teams, why not build systems that understand the environment, investigate problems and help operate it?

krnali Ops already uses a locally running model and specialised operational skills to work with my Kubernetes clusters.

The model provides reasoning. The skills provide the operational knowledge and capabilities. The underlying tools and runtime provide the evidence and controlled execution.

I've recently extended that approach into an application-specific security pilot, connecting a dedicated skill to narrowly scoped collectors and current vulnerability sources. It runs alongside my Ops work; feeding its findings into krnali Ops is the next integration step.

It's an interesting progression.

The same operational context used to investigate a deployment problem can also help identify a dangerous configuration, an overly privileged identity or a weakness across multiple components.

Instead of treating application security, infrastructure security and operational resilience as completely separate problems, we can start connecting the evidence.

This is where I see continuous defense becoming practical.

Not by giving an AI agent unrestricted cluster-admin access and hoping for the best.

By providing narrowly defined skills, scoped authority, trusted tools and clear limits on what the agent can do.

Why smaller models are changing the equation

There's a perception that useful AI security capabilities require enormous models, expensive GPUs and constant consumption of cloud inference tokens.

Sometimes they do.

But many operational and security tasks are narrower than that.

Reviewing a Kubernetes RBAC configuration, interpreting scanner findings, identifying risky Terraform changes or correlating a deployment with a security alert doesn't necessarily require a frontier model.

It requires the right context, the right tools and a model capable of reasoning over their results.

Modern open-weight models are increasingly capable of this.

Some particularly interesting candidates:

These aren't endorsements of their vulnerability-detection accuracy. That needs to be measured against real security tasks.

And don't confuse active parameter count with memory requirements. The model weights still need to fit somewhere, alongside the runtime and context cache.

For a first deployment, I'd choose a model that fits the hardware I already have, rather than design an expensive environment around a benchmark leaderboard.

Token efficiency matters too

A lot of the opportunity comes from doing less work with each model call.

Why send an entire repository when you're reviewing one deployment?

Why feed thousands of lines of logs into a model when deterministic tools can extract the relevant events?

Why repeatedly investigate a configuration that hasn't changed?

Use existing security scanners, structured queries and deterministic checks to do what they already do well.

Then let the model reason over the relevant evidence.

Retrieve only necessary application context. Reuse stable summaries. Cache unchanged results. Route simple tasks to smaller models and more complex investigations to larger ones when required.

Less context, fewer unnecessary inference steps, lower latency and better utilisation of local compute.

The model doesn't have to do everything.

It needs to understand enough to use the right tools and reach conclusions we can validate.

Agent skills are the practical starting point

This is the part I'm particularly interested in making accessible.

An agent skill is a reusable definition of how an agent should perform a specific job.

For defensive operations, a useful skill should define:

• The security objective and the systems it is allowed to inspect.
• The application context and evidence it needs.
• The approved tools and permissions it can use.
• How findings should be tested, validated and prioritised.
• What actions are allowed, which require approval, and how outcomes are recorded.

The skill isn't a replacement for your existing security tools.

It's a way to combine those capabilities with application-aware investigation.

Introducing the Security Skills Architect

I'm building Security Skills Architect, available as a downloadable preview, to help people create these specialised skills without having to design the whole agent workflow from scratch.

The idea is simple.

Tell the architect what you want to investigate, the systems involved, and the tools you already have.

It helps produce a structured skill with defined inputs, tool access, boundaries, checks and evidence requirements.

For example:

Build me a read-only Kubernetes security-review skill. It should examine service-account permissions, RBAC, network policies and workload security configurations. Correlate findings with the application's deployment configuration, explain potential attack paths and recommend remediations. Do not read secret values or modify resources. Require evidence for every finding.

Now you have a well-defined starting point. The preview contains the builder instructions and evaluation tooling; connecting an executor and approved tools is a separate implementation step. A public reuse licence is still pending.

Connect it to established tools. Run it against a known environment. Compare its findings with those of your security engineers.

Improve the skill before broadening its scope.

You don't need to fine-tune a model on your application to begin. Give the agent carefully scoped access to the relevant architecture, code, deployment metadata, policies and tools.

And make sure the skill itself is versioned, reviewed and tested. A skill is executable operational knowledge, not automatically a trusted security boundary.

Start small. Build confidence. Accelerate the scale.

I would approach this in four stages.

Stage 1: Observe

Pick one application or cluster.

Deploy a local model with one defensive skill and read-only access to the minimum information necessary.

Have it investigate one well-defined security problem, such as excessive Kubernetes privileges.

No production changes. No unnecessary access to secrets. No autonomous exploitation.

Stage 2: Validate

Compare its findings against established scanners and human security reviews.

Measure what it correctly identifies, what it misses and how often it produces false positives.

Require evidence linked to actual configurations, identities and reachable attack paths.

The important metric isn't how many vulnerabilities an agent claims to discover.

It's how many genuine risks it helps you understand and reduce.

Stage 3: Respond

Once the investigation becomes reliable, allow the system to recommend changes and generate remediation plans.

It might propose tightening an RBAC policy, isolating a workload or removing an unnecessary permission.

Run changes through normal engineering review, approval and deployment controls.

Use independent checks to verify that the vulnerability was addressed without breaking the application.

Stage 4: Scale

Expand across additional applications, repositories and infrastructure environments.

Introduce more specialised skills, reusable evidence, continuous scheduling and risk-based prioritisation.

For well-understood, reversible defensive actions, carefully introduce bounded automation with independent policy enforcement.

Keep humans responsible for consequential decisions.

And continuously measure whether you're actually reducing exposure.

The trust problem doesn't disappear

Running an open-weight model locally is useful, particularly when handling sensitive application and infrastructure information.

But local doesn't automatically mean secure.

An agent reading application code, logs or tool output is potentially processing attacker-controlled content.

A compromised skill, poisoned repository or malicious tool response can still influence its behaviour.

Which is why I consider zero trust, least privilege, isolation and independently enforced permissions fundamental to this approach.

The agent should not be able to grant itself additional authority, disable its own monitoring or bypass the controls governing its actions.

Keep the model separate from the authority to perform privileged operations.

Treat generated recommendations as untrusted until validated.

And record what the system observed, concluded, proposed and actually changed.

The objective isn't to trust the agent more. It's to build an environment where we don't have to.

Where this leads

I don't think we're going to eliminate risk registers, security engineers or penetration testing.

Nor should we.

But we can reduce how much of our security posture depends on infrequent assessments and assumptions that nobody has the time to revisit.

We can have locally deployed defensive agents continuously examining our systems, validating known weaknesses, identifying relationships between them and helping engineers fix what matters.

This is particularly relevant to the low- and medium-risk backlog we've been carrying for years.

Those findings need to be reconsidered in the context of what an attacker can actually reach, not simply what we thought each issue represented in isolation.

Start small. One model. One application. One trusted defensive skill.

Build confidence in the findings, the controls and the operational process.

Then accelerate the scale.

The Security Skills Architect preview is on GitHub. I've also written a separate implementation walkthrough: what the Architect generated, how I connected it to a local model, what the pilot found, and what needs doing next.

AI is changing the economics of attacking our systems. Let's use those same economics to defend them.

Further reading and technical references

• Low Likelihood Is Not a Control — krnali labs
• NIST SP 800-137 — Information Security Continuous Monitoring
• OpenAI gpt-oss models and memory requirements
• Qwen3-Coder model family
• Qwen3-Coder-30B-A3B model card
• OWASP — Prompt Injection and Agent Security