RichardHam.co.uk Blog

Author: admin

  • GitHub Weekly — SecureScore Goes Live, Agentic Ops Mature, and the Atlas Foundation Takes Shape

    Introduction

    Seventy-four repos, one week, and a surprising amount of shipped work. This week’s activity spans three themes: production security tooling crossing from plan into live operation, agentic infrastructure maturing with better observability and failover, and a new initiative — the Atlas Foundation — taking shape around public-good AI proposals. Here’s what happened, what shipped, and what it signals.

    What Happened

    SecureScore: From Dry-Run to Live

    The Hermes SecureScore project crossed a meaningful threshold this week. After install dry-runs and collector CLI fixes over the previous days, the project recorded its live activation on June 19. The Docker collector for SecureScore evidence shipped, a config collector bug for string provider entries was fixed, and the evidence pipeline moved from testing to production. On the dashboard side, the main Hermes Agent repo merged PR #1 adding a SecureScore view, confirming this isn’t a standalone experiment but an integrated part of operations.

    Why it matters: security评分 that runs locally, on your own infra, without sending data externally — that’s a pattern more teams will need as AI agent deployments multiply and audit requirements tighten.

    Hermes Mgmt: Dashboard v0.17 and the Work Behind It

    The management dashboard saw a methodical series of doc-and-script updates. Highlights:

    • v0.17.0 migration guide published, including a process restart requirement — a small detail that saves a lot of “why isn’t this working?” confusion.
    • Langfuse cost analytics landed as a cross-provider spend report with a weekly digest cron. Teams running multi-model setups can now track spend across providers without spreadsheet gymnastics.
    • Agent Tool Audit Report 2026-06-24 opened as a PR, systematically cataloguing what the agent toolkit actually contains and where the gaps are.
    • Telegram flood protection (Layers 3+4+5) merged, covering restart hygiene, notification deduplication, and rate-limit handling.
    • Security vulnerability remediation — 16 CVEs patched across nltk and starlette dependencies.

    The pattern here isn’t glamorous features; it’s the unglamorous maintainability work that keeps agent infrastructure from rotting.

    Agentic Coordination: Failover, Cost Awareness, and Escalation

    Three PRs from the Hermes Mgmt repo tell a story about agentic ops moving past the demo phase:

    1. Local-primary triage and tiered escalation (PR #624) — an EPIC outlining how a local model (Hermes3:8b) handles first-tier requests and escalates to stronger models when responses are weak or empty. This is the failover tier the project has been building toward.
    2. Credit-awareness fix plan for OpenRouter — because nothing kills an agent workflow faster than hitting a model credit limit mid-task without warning.
    3. Agent Radar got its initial commit with a roadmap of MVP tasks: detector rules for common agent frameworks, repo status badges, and schema examples. The idea is to build a tool that scans repos and identifies agent frameworks automatically.

    Infrastructure: Hardening and Monitoring

    On the infrastructure side:

    • Hamnet shipped SSH hardening for the VPS with a dynamic-IP allowlist failsafe — the kind of defensive depth that matters when IPs change and locks you out. Vhost routing was also hardened after an incident where a domain served the wrong site.
    • Ollama dashboard and metrics pipeline (Hamnet PR #134) — because if you’re running models locally, you need to know the server is alive without checking manually.
    • A WordPress blog import runbook was added, documenting the pipeline that keeps the blog publishing workflow reproducible.

    Atlas Foundation: Public-Good Agent Proposals

    The project-atlas-foundation repo saw significant activity: candidate proposals scored, shaping docs created, and a safety checklist added. The current proposal slate includes:

    • An open-source issue triage assistant
    • A digital-access assistant for elderly users
    • A small charity automation kit
    • A public-good agent template library

    A Claude Code handover document was added for the team, covering setup, sync, and triage workflows — suggesting the project is moving from concept to collaborative execution.

    HamMediaLabs: Governance Deepening

    HamMediaLabs shipped a wave of internal governance: onboarding guides, a development guide, risk register, branch hygiene policy, and a PR review dashboard with dependency health reporting. For a small team, this is the scaffolding that prevents chaos as contributors scale up.

    Key Takeaways

    1. Production security is becoming operational, not aspirational. SecureScore’s live activation is a signal that local-first security scoring is viable for small teams without enterprise tooling budgets.

    2. The agent ops story is shifting from “can we build it?” to “can we keep it running?” Flood protection, cost dashboards, failover tiers, and tool audits — this is the maintenance phase of the agentic infrastructure lifecycle.

    3. Multi-model cost visibility is now a first-class concern. Langfuse cost analytics with cross-provider reporting, OpenRouter credit-awareness, and tiered escalation — these all reflect the reality that running multiple AI models costs real money and needs real monitoring.

    4. Governance-as-code is emerging in smaller projects. HamMediaLabs and Atlas Foundation both shipped policy documents as code: branch hygiene, risk registers, safety checklists. This is where the industry is heading — compliance documentation that lives in the repo, not in a SharePoint graveyard.

    Code Snippet: Dynamic SSH Allowlist

    From the Hamnet infrastructure work, a pattern worth showing — dynamically resolving an ISP’s current IP for an SSH allowlist, with a failsafe that doesn’t lock you out:

    #!/usr/bin/env bash
# update-ssh-allowlist.sh — refresh dynamic IP in allowlist
set -euo pipefail

CURRENT_IP=$(curl -s --max-time 5 https://ifconfig.me)
KNOWN_FALLBACK="203.0.113.0/24"  # static backup range

if [[ "$CURRENT_IP" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
    iptables -D INPUT -p tcp --dport 22 -j DROP 2>/dev/null || true
    iptables -A INPUT -s "$CURRENT_IP/32" -p tcp --dport 22 -j ACCEPT
    echo "Updated: $CURRENT_IP/32"
else
    iptables -A INPUT -s "$KNOWN_FALLBACK" -p tcp --dport 22 -j ACCEPT
    echo "Fallback applied: $KNOWN_FALLBACK"
fi

    The key insight: always have a fallback. Dynamic DNS is reliable until the day your ISP changes your IP at 2 AM and you can’t SSH in to fix it.

    Data source: commits, issues, and PRs from 49 repositories over the past 7 days. Collected via the GitHub CLI on 2026-06-25.

  • GitHub Weekly — SecureScore Goes Live, Agentic Ops Mature, and the Atlas Foundation Takes Shape

    Introduction

    Seventy-four repos, one week, and a surprising amount of shipped work. This week’s activity spans three themes: production security tooling crossing from plan into live operation, agentic infrastructure maturing with better observability and failover, and a new initiative — the Atlas Foundation — taking shape around public-good AI proposals. Here’s what happened, what shipped, and what it signals.

    What Happened

    SecureScore: From Dry-Run to Live

    The Hermes SecureScore project crossed a meaningful threshold this week. After install dry-runs and collector CLI fixes over the previous days, the project recorded its live activation on June 19. The Docker collector for SecureScore evidence shipped, a config collector bug for string provider entries was fixed, and the evidence pipeline moved from testing to production. On the dashboard side, the main Hermes Agent repo merged PR #1 adding a SecureScore view, confirming this isn’t a standalone experiment but an integrated part of operations.

    Why it matters: security评分 that runs locally, on your own infra, without sending data externally — that’s a pattern more teams will need as AI agent deployments multiply and audit requirements tighten.

    Hermes Mgmt: Dashboard v0.17 and the Work Behind It

    The management dashboard saw a methodical series of doc-and-script updates. Highlights:

    • v0.17.0 migration guide published, including a process restart requirement — a small detail that saves a lot of “why isn’t this working?” confusion.
    • Langfuse cost analytics landed as a cross-provider spend report with a weekly digest cron. Teams running multi-model setups can now track spend across providers without spreadsheet gymnastics.
    • Agent Tool Audit Report 2026-06-24 opened as a PR, systematically cataloguing what the agent toolkit actually contains and where the gaps are.
    • Telegram flood protection (Layers 3+4+5) merged, covering restart hygiene, notification deduplication, and rate-limit handling.
    • Security vulnerability remediation — 16 CVEs patched across nltk and starlette dependencies.

    The pattern here isn’t glamorous features; it’s the unglamorous maintainability work that keeps agent infrastructure from rotting.

    Agentic Coordination: Failover, Cost Awareness, and Escalation

    Three PRs from the Hermes Mgmt repo tell a story about agentic ops moving past the demo phase:

    1. Local-primary triage and tiered escalation (PR #624) — an EPIC outlining how a local model (Hermes3:8b) handles first-tier requests and escalates to stronger models when responses are weak or empty. This is the failover tier the project has been building toward.
    2. Credit-awareness fix plan for OpenRouter — because nothing kills an agent workflow faster than hitting a model credit limit mid-task without warning.
    3. Agent Radar got its initial commit with a roadmap of MVP tasks: detector rules for common agent frameworks, repo status badges, and schema examples. The idea is to build a tool that scans repos and identifies agent frameworks automatically.

    Infrastructure: Hardening and Monitoring

    On the infrastructure side:

    • Hamnet shipped SSH hardening for the VPS with a dynamic-IP allowlist failsafe — the kind of defensive depth that matters when IPs change and locks you out. Vhost routing was also hardened after an incident where a domain served the wrong site.
    • Ollama dashboard and metrics pipeline (Hamnet PR #134) — because if you’re running models locally, you need to know the server is alive without checking manually.
    • A WordPress blog import runbook was added, documenting the pipeline that keeps the blog publishing workflow reproducible.

    Atlas Foundation: Public-Good Agent Proposals

    The project-atlas-foundation repo saw significant activity: candidate proposals scored, shaping docs created, and a safety checklist added. The current proposal slate includes:

    • An open-source issue triage assistant
    • A digital-access assistant for elderly users
    • A small charity automation kit
    • A public-good agent template library

    A Claude Code handover document was added for the team, covering setup, sync, and triage workflows — suggesting the project is moving from concept to collaborative execution.

    HamMediaLabs: Governance Deepening

    HamMediaLabs shipped a wave of internal governance: onboarding guides, a development guide, risk register, branch hygiene policy, and a PR review dashboard with dependency health reporting. For a small team, this is the scaffolding that prevents chaos as contributors scale up.

    Key Takeaways

    1. Production security is becoming operational, not aspirational. SecureScore’s live activation is a signal that local-first security scoring is viable for small teams without enterprise tooling budgets.

    2. The agent ops story is shifting from “can we build it?” to “can we keep it running?” Flood protection, cost dashboards, failover tiers, and tool audits — this is the maintenance phase of the agentic infrastructure lifecycle.

    3. Multi-model cost visibility is now a first-class concern. Langfuse cost analytics with cross-provider reporting, OpenRouter credit-awareness, and tiered escalation — these all reflect the reality that running multiple AI models costs real money and needs real monitoring.

    4. Governance-as-code is emerging in smaller projects. HamMediaLabs and Atlas Foundation both shipped policy documents as code: branch hygiene, risk registers, safety checklists. This is where the industry is heading — compliance documentation that lives in the repo, not in a SharePoint graveyard.

    Code Snippet: Dynamic SSH Allowlist

    From the Hamnet infrastructure work, a pattern worth showing — dynamically resolving an ISP’s current IP for an SSH allowlist, with a failsafe that doesn’t lock you out:

    #!/usr/bin/env bash
# update-ssh-allowlist.sh — refresh dynamic IP in allowlist
set -euo pipefail

CURRENT_IP=$(curl -s --max-time 5 https://ifconfig.me)
KNOWN_FALLBACK="203.0.113.0/24"  # static backup range

if [[ "$CURRENT_IP" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
    iptables -D INPUT -p tcp --dport 22 -j DROP 2>/dev/null || true
    iptables -A INPUT -s "$CURRENT_IP/32" -p tcp --dport 22 -j ACCEPT
    echo "Updated: $CURRENT_IP/32"
else
    iptables -A INPUT -s "$KNOWN_FALLBACK" -p tcp --dport 22 -j ACCEPT
    echo "Fallback applied: $KNOWN_FALLBACK"
fi

    The key insight: always have a fallback. Dynamic DNS is reliable until the day your ISP changes your IP at 2 AM and you can’t SSH in to fix it.

    Data source: commits, issues, and PRs from 49 repositories over the past 7 days. Collected via the GitHub CLI on 2026-06-25.

  • Hardening Without Drama

    Hardening Without Drama

    This was one of those weeks where the work that mattered most was the work nobody would notice if it went right. That usually means it is important.

    What changed

    • The security posture got tighter at the edges. A system that handles real work needs controls that survive when the environment changes.

    • Observability was also pushed a little closer to the truth. Good metrics do not flatter the operator; they tell you what is actually happening.

    • Several changes pointed to the same idea: if a process can fail, it should have a clear fallback and a clear owner.

    Closing thought

    The useful version of hardening is calm. No theatre, no chest-beating, just fewer weak spots and better recovery when something does break.

  • GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    g

    The week of June 15-22 was not defined by a single dramatic event. Instead, it was the kind of week that separates platforms that merely work from platforms that hold up under sustained pressure. Across 50 repositories, over 100 events — commits, pull requests, issues — pushed forward several long-running threads: memory architecture, health monitoring, security governance, and the unglamorous but essential work of keeping production infrastructure honest.

    What Happened

    hermes-mgmt — Hardening the Core

    The hermes-mgmt repository remained the busiest node in the network, with 20-plus commits, 20 PRs, and 13 issues. The dominant theme was memory system reliability. A significant fix (PR covering issues #573, #574, #575) hardened dual_memory.py across three dimensions: Ollama-first Mem0 configuration, deterministic Letta archival behaviour, and Qdrant vector dimension alignment. These are the kinds of fixes that don’t make headlines but prevent the subtle data corruption that erodes trust in AI systems over time.

    A related fix (issue #411) corrected a memory drift check that was comparing the wrong Letta data — core-memory passages instead of ARCHIVAL passages. This is a telling detail: as memory architectures grow more layered (core, archival, vector), the surface area for misaligned reads increases. Catching this before it caused silent data degradation matters.

    Health probes got a major upgrade with PR #568, which introduced functional health checks for services that report as “green” but are actually broken — Letta, n8n, Langfuse, Qdrant, Gateway, and Ollama. This is a pattern anyone running distributed systems will recognise: the dashboard shows all green, but something is quietly failing. Functional probes go beyond “is the process running?” to “does the service actually respond correctly?” — a distinction that matters enormously in production.

    Secrets management continued to mature. PR #552 delivered a comprehensive secrets management architecture built around Bitwarden and HashiCorp Vault, while PR #527 removed committed default secrets from the Langfuse compose configuration. These are the foundational security practices that need to be in place before scale makes them painful to retrofit.

    On the cron and scheduling side, the system now runs 38 cron jobs with 36 healthy — a 95% health rate that reflects the cumulative effect of weeks of hardening work. PR #504 corrected cron exit-code semantics so that findings and alerts are no longer misinterpreted as failures, which was causing unnecessary noise in the monitoring pipeline.

    Several open issues point to the next layer of work: Telegram flood-control protection (#583), gateway ungraceful shutdown (#582), Ollama-agent sequential dispatch performance (#580), and a Langfuse Cost Report cron that’s been disabled due to stale API keys (#576). None of these are emergencies, but they represent the known gaps that get addressed in order of priority.

    hamnet — Infrastructure Truth

    The hamnet repository, which manages infrastructure automation, saw 9 commits and 10 PRs with a focus on hosting hardening and monitoring.

    SSH hardening was codified for the VPS fleet (PR #131), including a dynamic-IP allowlist failsafe — a practical safeguard for environments where IP addresses shift. Vhost routing was hardened after www.theitrevolution.co.uk was found serving the wrong site, a class of misconfiguration that can be difficult to spot without deliberate verification.

    On the monitoring side, an Alertmanager webhook receiver was added with X-Webhook-Token authentication (PR #87), and a new Mac AI Server dashboard was built for the Ollama era (PR #134). The dashboard work reflects a broader shift: as the AI infrastructure stack evolves (Ollama replacing previous model servers), the monitoring layer needs to evolve in parallel or it becomes a liability rather than an asset.

    An open issue (#95) flags an SSL certificate SAN mismatch for www.richardham.co.uk — the kind of thing that works until it doesn’t, usually at the worst possible moment.

    hermes-agent — Gateway Stability

    The hermes-agent repository received 10 commits focused on gateway reliability. The command-line matcher was hardened, Windows restart no longer causes a silent outage, and the gateway now refreshes its cached agent max_iterations from the current config rather than stale values. A fix for dict choice unwrapping in the clarify function rounds out a set of small but meaningful stability improvements.

    These are the fixes that users never notice — because they prevent the failures that would have been noticed. Silent outages and stale config caches are particularly insidious because they can persist for extended periods before manifesting as user-visible problems.

    hermes-securescore — Evidence Collection

    The SecureScore project advanced with 9 commits and 2 PRs, adding both a Docker collector and a Hermes config collector for security evidence. A high-risk action approval playbook was also added, formalising the governance process for sensitive operations. The project recorded its live activation this week — a milestone that moves it from development into operational use.

    hermes-voice-satellite — Laying Groundwork

    The voice satellite project saw 9 commits establishing the MVP build plan, an operations runbook, a Hermes voice satellite API contract, and a Termux bootstrap script for Android (S24). A native Android app placeholder was also added. This is early-stage infrastructure work — the kind of foundation that needs to exist before feature development can accelerate.

    project-atlas-foundation — Launch Readiness

    Project Atlas received 10 commits focused on governance and launch preparation: a PR template, MIT licence, security policy, CODEOWNERS, a safety checklist, research workflow, promotion process, CI configuration, and hardened lifecycle guides. Scoring of proposals #3-#7 was completed alongside shaping docs and a launch checklist update. This is the organisational scaffolding that turns a codebase into a project other people can contribute to.

    AgentRadar — New Arrival

    AgentRadar received its initial commit this week. Details are sparse, but a new repository appearing in the portfolio is always worth noting — it represents a new thread that will either find its place or be retired honestly.

    richardham-web-and-Brand — Content Pipeline

    The web-and-brand repository saw 10 commits and 5 PRs, primarily focused on blog publishing and content pipeline maintenance. Four new blog posts in the agentic AI series were added with proper date spacing, and a build fix declared window.__calComLoaded to resolve a strict type-check failure. A WordPress publishing blocker was documented (VPS SSH key issue), which is the kind of honest infrastructure transparency that keeps content pipelines reliable.

    Key Takeaways

    Memory architecture is the new frontier. The volume of work on dual-memory hardening, Letta archival alignment, and Qdrant dimension matching signals that the memory subsystem has become a first-class concern. As AI agents handle longer and more complex tasks, the reliability of their memory layer directly determines the reliability of everything built on top of it. The drift-check fix — comparing the right data — is a small change with outsized implications.

    Functional health probes close a critical gap. The distinction between “process is running” and “service is working” is one of the most common blind spots in monitoring. Adding functional probes for six core services moves the observability stack from surface-level to meaningful. This is the kind of investment that pays for itself the first time it catches a green-but-broken service before a user does.

    Security governance is becoming systematic, not reactive. Between the secrets management architecture, the SecureScore evidence collectors, the high-risk action approval playbook, and the removal of committed defaults, the pattern is clear: security is being built into the development process rather than bolted on after incidents. This is the maturation path every platform needs to follow.

    Infrastructure truth matters. The hamnet work — SSH hardening, vhost routing fixes, SSL certificate monitoring, dashboard reconciliation — is the unglamorous foundation that everything else depends on. When www.theitrevolution.co.uk serves the wrong site, no amount of AI sophistication compensates. Keeping the infrastructure layer honest is a continuous discipline, not a one-time project.

    The content pipeline is converging with the platform. The parallel work on blog publishing, brand positioning, and the agentic AI content series is not separate from the technical work — it is how the technical work becomes visible and valuable. A hardened platform with strong governance needs an equally strong narrative around it.

    Looking Ahead

    The open issues across the portfolio paint a clear picture of next week’s priorities: resolve the Telegram flood-control design, address the gateway ungraceful shutdown path, fix the Langfuse Cost Report cron’s stale API keys, and close the SSL certificate SAN mismatch. On the infrastructure side, the Mac AI Server Ollama dashboard and metrics pipeline need to land, and the remaining open PRs in the web-and-brand repository need to progress through review.

    The velocity of the last week is notable not for its drama but for its consistency. Every repository moved forward. No single event dominated. That is what a healthy development portfolio looks like in practice — not a single sprint, but sustained, disciplined progress across every layer of the stack.

  • GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    The week of June 15-22 was not defined by a single dramatic event. Instead, it was the kind of week that separates platforms that merely work from platforms that hold up under sustained pressure. Across 50 repositories, over 100 events — commits, pull requests, issues — pushed forward several long-running threads: memory architecture, health monitoring, security governance, and the unglamorous but essential work of keeping production infrastructure honest.

    What Happened

    hermes-mgmt — Hardening the Core

    The hermes-mgmt repository remained the busiest node in the network, with 20-plus commits, 20 PRs, and 13 issues. The dominant theme was memory system reliability. A significant fix (PR covering issues #573, #574, #575) hardened dual_memory.py across three dimensions: Ollama-first Mem0 configuration, deterministic Letta archival behaviour, and Qdrant vector dimension alignment. These are the kinds of fixes that don’t make headlines but prevent the subtle data corruption that erodes trust in AI systems over time.

    A related fix (issue #411) corrected a memory drift check that was comparing the wrong Letta data — core-memory passages instead of ARCHIVAL passages. This is a telling detail: as memory architectures grow more layered (core, archival, vector), the surface area for misaligned reads increases. Catching this before it caused silent data degradation matters.

    Health probes got a major upgrade with PR #568, which introduced functional health checks for services that report as “green” but are actually broken — Letta, n8n, Langfuse, Qdrant, Gateway, and Ollama. This is a pattern anyone running distributed systems will recognise: the dashboard shows all green, but something is quietly failing. Functional probes go beyond “is the process running?” to “does the service actually respond correctly?” — a distinction that matters enormously in production.

    Secrets management continued to mature. PR #552 delivered a comprehensive secrets management architecture built around Bitwarden and HashiCorp Vault, while PR #527 removed committed default secrets from the Langfuse compose configuration. These are the foundational security practices that need to be in place before scale makes them painful to retrofit.

    On the cron and scheduling side, the system now runs 38 cron jobs with 36 healthy — a 95% health rate that reflects the cumulative effect of weeks of hardening work. PR #504 corrected cron exit-code semantics so that findings and alerts are no longer misinterpreted as failures, which was causing unnecessary noise in the monitoring pipeline.

    Several open issues point to the next layer of work: Telegram flood-control protection (#583), gateway ungraceful shutdown (#582), Ollama-agent sequential dispatch performance (#580), and a Langfuse Cost Report cron that’s been disabled due to stale API keys (#576). None of these are emergencies, but they represent the known gaps that get addressed in order of priority.

    hamnet — Infrastructure Truth

    The hamnet repository, which manages infrastructure automation, saw 9 commits and 10 PRs with a focus on hosting hardening and monitoring.

    SSH hardening was codified for the VPS fleet (PR #131), including a dynamic-IP allowlist failsafe — a practical safeguard for environments where IP addresses shift. Vhost routing was hardened after www.theitrevolution.co.uk was found serving the wrong site, a class of misconfiguration that can be difficult to spot without deliberate verification.

    On the monitoring side, an Alertmanager webhook receiver was added with X-Webhook-Token authentication (PR #87), and a new Mac AI Server dashboard was built for the Ollama era (PR #134). The dashboard work reflects a broader shift: as the AI infrastructure stack evolves (Ollama replacing previous model servers), the monitoring layer needs to evolve in parallel or it becomes a liability rather than an asset.

    An open issue (#95) flags an SSL certificate SAN mismatch for www.richardham.co.uk — the kind of thing that works until it doesn’t, usually at the worst possible moment.

    hermes-agent — Gateway Stability

    The hermes-agent repository received 10 commits focused on gateway reliability. The command-line matcher was hardened, Windows restart no longer causes a silent outage, and the gateway now refreshes its cached agent max_iterations from the current config rather than stale values. A fix for dict choice unwrapping in the clarify function rounds out a set of small but meaningful stability improvements.

    These are the fixes that users never notice — because they prevent the failures that would have been noticed. Silent outages and stale config caches are particularly insidious because they can persist for extended periods before manifesting as user-visible problems.

    hermes-securescore — Evidence Collection

    The SecureScore project advanced with 9 commits and 2 PRs, adding both a Docker collector and a Hermes config collector for security evidence. A high-risk action approval playbook was also added, formalising the governance process for sensitive operations. The project recorded its live activation this week — a milestone that moves it from development into operational use.

    hermes-voice-satellite — Laying Groundwork

    The voice satellite project saw 9 commits establishing the MVP build plan, an operations runbook, a Hermes voice satellite API contract, and a Termux bootstrap script for Android (S24). A native Android app placeholder was also added. This is early-stage infrastructure work — the kind of foundation that needs to exist before feature development can accelerate.

    project-atlas-foundation — Launch Readiness

    Project Atlas received 10 commits focused on governance and launch preparation: a PR template, MIT licence, security policy, CODEOWNERS, a safety checklist, research workflow, promotion process, CI configuration, and hardened lifecycle guides. Scoring of proposals #3-#7 was completed alongside shaping docs and a launch checklist update. This is the organisational scaffolding that turns a codebase into a project other people can contribute to.

    AgentRadar — New Arrival

    AgentRadar received its initial commit this week. Details are sparse, but a new repository appearing in the portfolio is always worth noting — it represents a new thread that will either find its place or be retired honestly.

    richardham-web-and-Brand — Content Pipeline

    The web-and-brand repository saw 10 commits and 5 PRs, primarily focused on blog publishing and content pipeline maintenance. Four new blog posts in the agentic AI series were added with proper date spacing, and a build fix declared window.__calComLoaded to resolve a strict type-check failure. A WordPress publishing blocker was documented (VPS SSH key issue), which is the kind of honest infrastructure transparency that keeps content pipelines reliable.

    Key Takeaways

    Memory architecture is the new frontier. The volume of work on dual-memory hardening, Letta archival alignment, and Qdrant dimension matching signals that the memory subsystem has become a first-class concern. As AI agents handle longer and more complex tasks, the reliability of their memory layer directly determines the reliability of everything built on top of it. The drift-check fix — comparing the right data — is a small change with outsized implications.

    Functional health probes close a critical gap. The distinction between “process is running” and “service is working” is one of the most common blind spots in monitoring. Adding functional probes for six core services moves the observability stack from surface-level to meaningful. This is the kind of investment that pays for itself the first time it catches a green-but-broken service before a user does.

    Security governance is becoming systematic, not reactive. Between the secrets management architecture, the SecureScore evidence collectors, the high-risk action approval playbook, and the removal of committed defaults, the pattern is clear: security is being built into the development process rather than bolted on after incidents. This is the maturation path every platform needs to follow.

    Infrastructure truth matters. The hamnet work — SSH hardening, vhost routing fixes, SSL certificate monitoring, dashboard reconciliation — is the unglamorous foundation that everything else depends on. When www.theitrevolution.co.uk serves the wrong site, no amount of AI sophistication compensates. Keeping the infrastructure layer honest is a continuous discipline, not a one-time project.

    The content pipeline is converging with the platform. The parallel work on blog publishing, brand positioning, and the agentic AI content series is not separate from the technical work — it is how the technical work becomes visible and valuable. A hardened platform with strong governance needs an equally strong narrative around it.

    Looking Ahead

    The open issues across the portfolio paint a clear picture of next week’s priorities: resolve the Telegram flood-control design, address the gateway ungraceful shutdown path, fix the Langfuse Cost Report cron’s stale API keys, and close the SSL certificate SAN mismatch. On the infrastructure side, the Mac AI Server Ollama dashboard and metrics pipeline need to land, and the remaining open PRs in the web-and-brand repository need to progress through review.

    The velocity of the last week is notable not for its drama but for its consistency. Every repository moved forward. No single event dominated. That is what a healthy development portfolio looks like in practice — not a single sprint, but sustained, disciplined progress across every layer of the stack.

  • GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    GitHub Weekly: Memory Architecture, Health Probes, and the Quiet Work of Production Hardening

    The week of June 15-22 was not defined by a single dramatic event. Instead, it was the kind of week that separates platforms that merely work from platforms that hold up under sustained pressure. Across 50 repositories, over 100 events — commits, pull requests, issues — pushed forward several long-running threads: memory architecture, health monitoring, security governance, and the unglamorous but essential work of keeping production infrastructure honest.

    What Happened

    hermes-mgmt — Hardening the Core

    The hermes-mgmt repository remained the busiest node in the network, with 20-plus commits, 20 PRs, and 13 issues. The dominant theme was memory system reliability. A significant fix (PR covering issues #573, #574, #575) hardened dual_memory.py across three dimensions: Ollama-first Mem0 configuration, deterministic Letta archival behaviour, and Qdrant vector dimension alignment. These are the kinds of fixes that don’t make headlines but prevent the subtle data corruption that erodes trust in AI systems over time.

    A related fix (issue #411) corrected a memory drift check that was comparing the wrong Letta data — core-memory passages instead of ARCHIVAL passages. This is a telling detail: as memory architectures grow more layered (core, archival, vector), the surface area for misaligned reads increases. Catching this before it caused silent data degradation matters.

    Health probes got a major upgrade with PR #568, which introduced functional health checks for services that report as “green” but are actually broken — Letta, n8n, Langfuse, Qdrant, Gateway, and Ollama. This is a pattern anyone running distributed systems will recognise: the dashboard shows all green, but something is quietly failing. Functional probes go beyond “is the process running?” to “does the service actually respond correctly?” — a distinction that matters enormously in production.

    Secrets management continued to mature. PR #552 delivered a comprehensive secrets management architecture built around Bitwarden and HashiCorp Vault, while PR #527 removed committed default secrets from the Langfuse compose configuration. These are the foundational security practices that need to be in place before scale makes them painful to retrofit.

    On the cron and scheduling side, the system now runs 38 cron jobs with 36 healthy — a 95% health rate that reflects the cumulative effect of weeks of hardening work. PR #504 corrected cron exit-code semantics so that findings and alerts are no longer misinterpreted as failures, which was causing unnecessary noise in the monitoring pipeline.

    Several open issues point to the next layer of work: Telegram flood-control protection (#583), gateway ungraceful shutdown (#582), Ollama-agent sequential dispatch performance (#580), and a Langfuse Cost Report cron that’s been disabled due to stale API keys (#576). None of these are emergencies, but they represent the known gaps that get addressed in order of priority.

    hamnet — Infrastructure Truth

    The hamnet repository, which manages infrastructure automation, saw 9 commits and 10 PRs with a focus on hosting hardening and monitoring.

    SSH hardening was codified for the VPS fleet (PR #131), including a dynamic-IP allowlist failsafe — a practical safeguard for environments where IP addresses shift. Vhost routing was hardened after www.theitrevolution.co.uk was found serving the wrong site, a class of misconfiguration that can be difficult to spot without deliberate verification.

    On the monitoring side, an Alertmanager webhook receiver was added with X-Webhook-Token authentication (PR #87), and a new Mac AI Server dashboard was built for the Ollama era (PR #134). The dashboard work reflects a broader shift: as the AI infrastructure stack evolves (Ollama replacing previous model servers), the monitoring layer needs to evolve in parallel or it becomes a liability rather than an asset.

    An open issue (#95) flags an SSL certificate SAN mismatch for www.richardham.co.uk — the kind of thing that works until it doesn’t, usually at the worst possible moment.

    hermes-agent — Gateway Stability

    The hermes-agent repository received 10 commits focused on gateway reliability. The command-line matcher was hardened, Windows restart no longer causes a silent outage, and the gateway now refreshes its cached agent max_iterations from the current config rather than stale values. A fix for dict choice unwrapping in the clarify function rounds out a set of small but meaningful stability improvements.

    These are the fixes that users never notice — because they prevent the failures that would have been noticed. Silent outages and stale config caches are particularly insidious because they can persist for extended periods before manifesting as user-visible problems.

    hermes-securescore — Evidence Collection

    The SecureScore project advanced with 9 commits and 2 PRs, adding both a Docker collector and a Hermes config collector for security evidence. A high-risk action approval playbook was also added, formalising the governance process for sensitive operations. The project recorded its live activation this week — a milestone that moves it from development into operational use.

    hermes-voice-satellite — Laying Groundwork

    The voice satellite project saw 9 commits establishing the MVP build plan, an operations runbook, a Hermes voice satellite API contract, and a Termux bootstrap script for Android (S24). A native Android app placeholder was also added. This is early-stage infrastructure work — the kind of foundation that needs to exist before feature development can accelerate.

    project-atlas-foundation — Launch Readiness

    Project Atlas received 10 commits focused on governance and launch preparation: a PR template, MIT licence, security policy, CODEOWNERS, a safety checklist, research workflow, promotion process, CI configuration, and hardened lifecycle guides. Scoring of proposals #3-#7 was completed alongside shaping docs and a launch checklist update. This is the organisational scaffolding that turns a codebase into a project other people can contribute to.

    AgentRadar — New Arrival

    AgentRadar received its initial commit this week. Details are sparse, but a new repository appearing in the portfolio is always worth noting — it represents a new thread that will either find its place or be retired honestly.

    richardham-web-and-Brand — Content Pipeline

    The web-and-brand repository saw 10 commits and 5 PRs, primarily focused on blog publishing and content pipeline maintenance. Four new blog posts in the agentic AI series were added with proper date spacing, and a build fix declared window.__calComLoaded to resolve a strict type-check failure. A WordPress publishing blocker was documented (VPS SSH key issue), which is the kind of honest infrastructure transparency that keeps content pipelines reliable.

    Key Takeaways

    Memory architecture is the new frontier. The volume of work on dual-memory hardening, Letta archival alignment, and Qdrant dimension matching signals that the memory subsystem has become a first-class concern. As AI agents handle longer and more complex tasks, the reliability of their memory layer directly determines the reliability of everything built on top of it. The drift-check fix — comparing the right data — is a small change with outsized implications.

    Functional health probes close a critical gap. The distinction between “process is running” and “service is working” is one of the most common blind spots in monitoring. Adding functional probes for six core services moves the observability stack from surface-level to meaningful. This is the kind of investment that pays for itself the first time it catches a green-but-broken service before a user does.

    Security governance is becoming systematic, not reactive. Between the secrets management architecture, the SecureScore evidence collectors, the high-risk action approval playbook, and the removal of committed defaults, the pattern is clear: security is being built into the development process rather than bolted on after incidents. This is the maturation path every platform needs to follow.

    Infrastructure truth matters. The hamnet work — SSH hardening, vhost routing fixes, SSL certificate monitoring, dashboard reconciliation — is the unglamorous foundation that everything else depends on. When www.theitrevolution.co.uk serves the wrong site, no amount of AI sophistication compensates. Keeping the infrastructure layer honest is a continuous discipline, not a one-time project.

    The content pipeline is converging with the platform. The parallel work on blog publishing, brand positioning, and the agentic AI content series is not separate from the technical work — it is how the technical work becomes visible and valuable. A hardened platform with strong governance needs an equally strong narrative around it.

    Looking Ahead

    The open issues across the portfolio paint a clear picture of next week’s priorities: resolve the Telegram flood-control design, address the gateway ungraceful shutdown path, fix the Langfuse Cost Report cron’s stale API keys, and close the SSL certificate SAN mismatch. On the infrastructure side, the Mac AI Server Ollama dashboard and metrics pipeline need to land, and the remaining open PRs in the web-and-brand repository need to progress through review.

    The velocity of the last week is notable not for its drama but for its consistency. Every repository moved forward. No single event dominated. That is what a healthy development portfolio looks like in practice — not a single sprint, but sustained, disciplined progress across every layer of the stack.

  • What Actually Makes an AI Stack Coherent

    t

    A lot of people describe an AI stack by listing components.

    Model router. Agent framework. automation layer. memory system. observability tool. evaluation harness. MCP server. Dashboard. Scheduler. Local inference. Cloud fallback.

    That list can sound impressive, but it does not tell you whether the system is coherent. It only tells you what has been installed.

    In practice, coherence comes from something more demanding: each component needs a clear job, the boundaries between them need to make sense, and the whole stack needs to be operable by someone who did not build it from memory.

    That is the difference between an AI stack and an AI estate.

    The real problem is integration, not acquisition

    Most modern AI components are fairly easy to stand up in isolation. The hard part begins when they have to behave as one system.

    That is where questions start mattering:

    • which layer actually owns routing?
    • where does workflow state live?
    • what should be remembered and for how long?
    • which layer enforces approval or review?
    • where do traces go when something fails?
    • how does an operator explain the end-to-end behaviour afterward?

    If the answer to those questions is fuzzy, the stack may still look sophisticated from a distance. But it will behave like a collection of parts rather than an operating model.

    The components are less important than their roles

    A coherent stack usually has a few recurring functions, even if the exact tools differ.

    1. Orchestration

    Something needs to decide how work is delegated, sequenced, and surfaced back to the operator. That can be an agent gateway, a workflow engine, or a mix of the two. What matters is that the control plane is understandable.

    2. Automation

    Event-driven and scheduled work needs a predictable home. If webhooks, cron tasks, notifications, and system glue are scattered across ad hoc scripts, the stack becomes harder to reason about very quickly.

    3. Memory

    Useful AI systems usually need both immediate context and some form of longer-lived recall. The difficult part is not just adding memory. It is deciding what deserves to persist, what should stay local, and what should never be carried forward automatically.

    4. Model routing

    Without an explicit routing layer, cost and trust boundaries tend to drift. Cheap models get used where better judgement was required, or expensive models get wasted on routine work. A coherent stack makes that decision visible and deliberate.

    5. Observability and evaluation

    If you cannot inspect what happened, replay the path, and compare changes over time, the stack becomes increasingly hard to trust. This is especially true once several tools and providers sit in the same chain.

    What coherence looks like operationally

    The practical signs are usually boring in the best possible way.

    A coherent system lets an operator answer simple questions quickly:

    • what happened?
    • why did it happen that way?
    • which component made the decision?
    • what data or memory influenced it?
    • what changed compared with the previous run?
    • how do we recover if the preferred path is unavailable?

    If those answers require guesswork, the stack is still immature no matter how many components it contains.

    The biggest design mistake

    The most common mistake I see is confusing capability expansion with architectural progress.

    Adding a new framework, model, or tool can increase capability. But it also adds operational cost. More boundaries. More failure modes. More decisions about ownership. More ambiguity if the roles are not explicit.

    That is why I think the most important design question is not “what else can we add?” It is “what problem does this layer uniquely solve, and what would break if it were removed?”

    If the answer is vague, the component is probably decorative.

    Why this matters for serious AI work

    Once AI systems move beyond experimentation, they start inheriting the obligations of any production environment:

    • predictable behaviour
    • clear trust boundaries
    • controlled cost
    • useful monitoring
    • recovery paths that do not depend on one person’s memory
    • documentation that survives handover

    That is why coherence matters. It is what turns a stack from a demo environment into something a business can depend on.

    A simpler test

    If I had to reduce the whole topic to one test, it would be this:

    Can you explain your AI stack in terms of operating responsibilities rather than product names?

    If you can, there is a good chance the architecture is maturing.

    If you cannot, the problem is probably not that you need one more tool. It is that the current layers have not been given clear enough jobs yet.

    That is where most of the real architecture work lives.

    And it is usually far more valuable than adding another box to the diagram.

    If you are trying to make an AI stack coherent enough to run like real infrastructure rather than a pile of experiments, the AI & Automation Architecture work is designed around exactly that problem. Or get in touch if you want a practical review of the roles, boundaries, and operating model in your current setup.

  • The M365 Security Baseline Most SMEs Skip

    p

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • The M365 Security Baseline Most SMEs Skip

    The M365 Security Baseline Most SMEs Skip

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • The M365 Security Baseline Most SMEs Skip

    The M365 Security Baseline Most SMEs Skip

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

Powered by