RichardHam.co.uk Blog

Tag: security

  • Why Dependency Hygiene Becomes a Leadership Issue

    Why Dependency Hygiene Becomes a Leadership Issue

    A lot of teams still treat package upgrades and release housekeeping as purely technical chores.

    That made sense when the application estate was simpler, the change rate was slower, and a missed patch mostly meant a slightly awkward sprint later on. It makes much less sense once your organisation depends on AI services, automation workflows, customer-facing portals, and a growing set of third-party components that can change under your feet.

    This week’s GitHub activity was a useful reminder of that.

    Across several public repos, the work was not centred on a dramatic new feature. It was centred on the quieter jobs that keep live systems usable: upgrading a framework across multiple sites, tightening the way an agent platform distinguishes billing exhaustion from authentication failure, restoring an explicit safety guard with regression coverage, and shipping deployment handover notes alongside a website redesign.

    That mix matters because it points to a broader operating reality: dependency hygiene is no longer just a developer preference. It has become part of leadership discipline.

    The recent GitHub signals were small, but not trivial

    A few examples stood out.

    One public media/website repo recently went through a cluster of framework upgrades across multiple surfaces. On the face of it, those are dependency bumps. In practice, they are evidence of someone choosing not to let the front-end estate drift quietly into a harder future upgrade.

    Another public analytics/cost-tracking repo saw updates to numerical and coverage tooling. Again, this is the sort of work many leadership teams never see. Yet if cost reporting or analytics underpin operational decisions, stale numerical libraries and test tooling are not invisible engineering details. They affect how confidently the team can rely on output.

    In one public agent platform, a recent change separated billing exhaustion from a generic authentication failure, while another restored a missing enabled-guard and added regression tests. Those are strong examples of operational maturity. The first makes failure states easier to understand. The second makes it harder for a disabled service path to behave ambiguously.

    Then there was website delivery work in a public site repo: one change added a deployment handover document, and another shipped the full site build and deploy tooling. That is not just design delivery. It is an acknowledgement that shipping is only half the job if nobody else can support the result safely afterwards.

    Why senior leaders should care about this work

    If you are a founder, managing partner, COO, CIO, or board sponsor, none of this should be dismissed as back-room maintenance.

    Once AI, automation, or client-facing digital journeys are part of the operating model, dependency hygiene becomes a business issue for three reasons.

    1. Drift increases the cost of every later decision

    Technical drift rarely fails all at once. It accumulates quietly.

    A framework stays two major versions behind. A library update gets deferred because it is inconvenient. A brittle edge case stays undocumented because the team who understands it is still around. Nothing looks urgent until a new feature, security fix, or partner integration suddenly depends on clearing months of deferred maintenance.

    That is when the bill arrives.

    For SMEs and founder-led businesses, that usually shows up as delivery drag. For law firms and healthcare organisations, it can also create assurance problems because the stack behind a client-facing process becomes harder to explain. For PE-backed companies, it turns into diligence friction. If the technology estate looks under-maintained, every transformation claim starts to feel less believable.

    2. Poorly classified failures waste leadership attention

    One of the most useful repo changes this week was not a new feature at all. It was the decision in one public agent platform to separate billing exhaustion from a generic auth failure.

    That matters because leaders make bad decisions when the system reports the wrong category of problem.

    If a model provider has hit a spend limit, that is a budget, quota, or supplier-management conversation. If the credentials are wrong, that is a configuration or secrets-management conversation. If both are lumped together as “auth failed”, the team loses time, the escalation path gets muddled, and confidence in the monitoring starts to erode.

    At scale, this is one of the easiest ways for senior people to get dragged into operational noise that should have been designed out earlier.

    3. Handover quality is part of risk control

    I think many organisations still underestimate how much risk sits in the gap between “it works” and “someone else can run it”.

    That is why the deployment handover work in dh-electrical-uk-website is commercially important. When a redesign lands with deploy tooling and supporting handover notes, the delivery is stronger than a visually successful launch on its own. It means the service is more likely to survive staff changes, supplier changes, holiday cover, and the inevitable moment when something needs to be updated under time pressure.

    In practical terms, handover is where a lot of hidden fragility gets exposed:

    • which versions are actually supported
    • which environment assumptions are undocumented
    • which steps still live in one person’s head
    • which recovery actions have never been written down

    If that sounds familiar, the issue is not documentation style. It is operating-model debt.

    What good leadership looks like here

    The answer is not for non-technical leaders to micromanage every package bump.

    The answer is to treat upgrade hygiene, failure clarity, and supportability as visible management concerns. In practice, I would want four things.

    Keep an explicit tolerance for drift

    Not every dependency needs to be latest immediately. But the organisation should know what level of lag is acceptable, where major-version changes are being deferred deliberately, and who owns the call when a deferral becomes risky.

    Insist on failure signals that guide action

    If an automation platform cannot distinguish billing, auth, config, runtime, and policy problems cleanly, the team will spend too much time diagnosing symptoms and not enough time fixing causes.

    Ask for handover evidence before calling a project done

    If a supplier, internal team, or blended delivery setup cannot show you the deploy path, the support notes, and the recovery assumptions, you do not yet have a finished operational asset.

    Connect maintenance discipline to commercial credibility

    Clients, investors, regulators, and acquirers do not usually ask whether numpy or Astro was bumped on Tuesday. They do care whether your digital services are dependable, whether your reporting is trustworthy enough to guide decisions, and whether your systems can be maintained without heroics.

    That is the commercial expression of dependency hygiene.

    A simple question worth asking this quarter

    If your organisation relies on AI, automation, or a modern web estate, ask one blunt question:

    Which live services would become awkward or risky to change if the current operator disappeared for two weeks?

    The answer usually reveals more than a tooling audit alone.

    It shows where drift has been tolerated too long, where failure messages are too vague to manage well, and where handover has been assumed rather than designed. Those are exactly the places where fractional leadership earns its keep, because the problem is rarely just a code problem. It sits across governance, service design, supplier control, and risk appetite.

    If that question exposes uncomfortable gaps, that is useful. It gives you a practical starting point.

    If you want help turning that picture into a calmer operating model, my services cover the overlap between security leadership, IT direction, and AI architecture. Or get in touch if you want a senior review of where maintenance debt, weak handover, or ambiguous failure handling is making change harder than it should be.

  • Fractional CISO vs Virtual CISO: What UK SMEs Actually Need

    Search for security leadership support for a UK SME and you will hit two terms: fractional CISO and virtual CISO. Providers use them interchangeably, job ads mix them up, and most comparison content on the internet was written to fill a gap rather than to explain the market.

    Here is the honest answer: in the UK market, these two terms usually describe the same thing. A senior security leader working with your business on a part-time, retained basis. If you are comparing providers on their job title alone, you are comparing the wrong thing. What actually differs is how the engagement is structured — and that is where SMEs get this decision right or wrong.

    Why the terms get used interchangeably

    Both models exist for the same reason: most SMEs do not need a full-time CISO. A permanent CISO in the UK runs roughly £120,000 to £180,000 a year, and most businesses under a few hundred staff cannot justify that role five days a week. What they need is serious security judgement in the room a few days a month — someone to set direction, own risk, and answer to the board, insurers and customers.

    Both fractional and virtual CISO models deliver exactly that. Some providers call two retained days a week a fractional engagement; others call the same arrangement virtual. There is no standards body defining the terms, so the label tells you less than it appears to.

    What the engagement actually looks like

    Rather than comparing labels, compare the shape of the arrangement. These are the dimensions that genuinely differ between providers — under either name:

    – Days and rhythm: how many days a month, and whether they are fixed (for example, the first Tuesday of each month) or drawn on demand. Fixed rhythms produce better governance; on-demand arrangements tend to react rather than lead.
    – Scope: is the engagement strategy-only, or does it include hands-on work — configuring controls, reviewing your Microsoft 365 baseline, running supplier assessments? Some leaders stay at board level; others roll up their sleeves. Both are valid, but you should know which you are buying.
    – Deliverables: a security strategy, a risk register that actually gets updated, policy set, an incident response plan your team can follow, evidence packs for Cyber Essentials or ISO 27001. If a provider cannot list what lands in your inbox each month, you are buying a retainer, not an outcome.
    – Presence: do they attend your board or leadership meetings? Do they speak to your insurers or your largest customer’s security team when a supplier assurance questionnaire arrives? That conversation is often the real job.
    – Cover: what happens when something goes wrong at 4am, or while your CISO-equivalent is on holiday? Some engagements include incident cover; others do not.

    What UK SMEs should actually compare

    When you are weighing two proposals, these questions separate a genuine security leader from an expensive pair of hands:

    – Regulatory grounding: can they explain how your UK GDPR accountability obligations apply to the systems you actually run, including any AI tools your team has adopted? A good fractional CISO reads your record of processing and tells you what is missing.
    – Certification pathway: if a customer or insurer has made Cyber Essentials Plus or ISO 27001 a condition of doing business, do they own that programme end to end — gap assessment, remediation, internal audit, certification support? This is where part-time security leadership earns its fee.
    – Evidence habits: insurers and enterprise customers increasingly ask for evidence, not assurances. Do they build the logging, reporting and review routines that produce that evidence continuously, or scramble for it when a renewal lands?
    – Honesty about fit: a good provider will tell you when you do not need them yet. If every conversation pushes you towards a bigger retainer, treat that as a signal.

    A realistic progression for a growing SME

    A pattern I see repeatedly, and one worth planning for:

    Early stage, you bring in fractional support to build the foundations — strategy, policy set, a risk register, a Cyber Essentials submission. A few days a month is enough.

    As you grow, customer scrutiny grows with you. Enterprise buyers start sending supplier assurance questionnaires. Cyber insurance renewals start asking harder questions. The monthly rhythm that worked at twenty staff leaves gaps at a hundred, and the engagement shifts towards a more continuous virtual model — more days, more operational presence, real incident cover.

    The businesses that handle this well treat it as one relationship maturing, not two different services. The ones that struggle rip up the arrangement each time their circumstances change, usually under time pressure from a customer deadline.

    The short version

    Fractional CISO and virtual CISO are two labels for an overlapping market. Do not choose between the terms — choose the provider, and compare them on days, scope, deliverables, presence and cover. Ask what evidence they will produce for your insurers, your customers and your auditors. And if you are planning an AI pilot alongside all this, make sure whoever takes the security lead can talk about that too, because it is now a board question, not a technical one.

    If you are weighing up security leadership support for your business and want a straight view on what you actually need, get in touch via the contact page.

  • Hermes in the Enterprise: A Security Team’s Threat Model

    Hermes Agent is heading for enterprise networks. On 7 October 2026 the Wall Street Journal reported that Nous Research had raised $90 million at a $1.5 billion valuation to take its open-source agent from individual developers into corporate environments — the article notes more than 22 million downloads since February. This is no longer a tool your most curious engineer runs on a spare VM. It will be bought, piloted and integrated by organisations that answer to auditors, insurers and customers.

    If your team is evaluating Hermes or any agentic AI of this class, what should your security function ask first? Not “is it safe?” — that never gets a useful answer. The right questions: what can this thing do without me, who can talk to it, and how would I know when it did something I would not have approved?

    What Hermes actually does

    Hermes Agent is an autonomous agent from Nous Research, the open-weights lab behind the Hermes model family — not a chatbot bolted onto an API. It uses tool calling to read and write files, run shell commands and code, browse the web, call external APIs and model context protocol servers, and spawn isolated subagents. It runs on terminal backends from your own machine to Docker containers, remote SSH hosts or serverless sandboxes.

    Two features matter most for a threat model. First, the learning loop: Hermes creates and updates its own skills — reusable procedural documents it loads when a task matches — and the official docs state the agent can modify or delete any skill, with human-approved skill writes as an optional gate that is off by default. Second, the messaging gateway: the same agent is reachable from Telegram, Discord, Slack, WhatsApp, Microsoft Teams and more, with built-in scheduling so it runs unattended jobs around the clock. You can message it from your phone while it executes on a server you never log into.

    That combination — persistent autonomy, self-modifying procedure, conversational remote control — is genuinely useful, and a prompt-injection class in production form.

    The threat model

    Prompt injection via web content and files. Hermes reads what you point it at: web pages, documents, repositories, emails. Instructions hidden in that content are indistinguishable from instructions you gave it. This is not hypothetical — in July 2026 researchers published a proof of concept, reported by The Hacker News, showing leading coding agents tricked into executing attacker-supplied binaries via a poisoned README in an open-source repository. Hermes has mitigations — context-file scanning, always-on request forgery protection blocking fetches to private networks, a configurable website blocklist — but the scanning is explicitly heuristic, not semantic. Treat web and file content as untrusted input to a privileged process.
    Malicious or drifting self-created skills. Skills are the agent’s procedural memory, drawn from bundled sets, community hubs, or the agent writing its own. A skill is a markdown document that shapes future behaviour — instructions to ignore approvals, exfiltrate data or quietly widen scope would persist until someone reads the file. Default configuration writes skills freely, and a skill that was correct in March can drift as the environment changes.
    Chat account takeover. Hermes treats whoever can message the gateway as the operator. An attacker who compromises a linked Telegram or Discord account inherits the agent’s access. The gateway has layered authorisation — per-platform user allowlists, pairing codes, deny-by-default when nothing is configured — but consumer chat platforms are not your identity provider.
    Secrets exposure. The agent holds model API keys and can be handed cloud, email and code-hosting credentials. Redaction exists for tool error output, but anything the agent can read — environment files, notes, logs — can end up in a model prompt, a chat message, or a file it writes somewhere public.
    Over-broad permissions. With dozens of built-in tools and shell execution, a default install is a small operating system with your name on it. YOLO mode exists and disables approval prompts entirely; so does flipping approvals off in configuration. Headless surfaces default to denying dangerous commands, but defaults are a floor, not a control set.
    Weak audit trail. Hermes logs locally and keeps session history, but if your security operations team cannot query it, you do not have an audit trail — you have files. An agent acting every few minutes needs central logging before it needs a use case.

    Controls that actually apply

    Most of these exist in Hermes today. The gap in most pilots is that nobody configures them.

    Sandbox execution. Run command execution on the container backend — which drops Linux capabilities, blocks privilege escalation and limits processes — or on a dedicated host behind an SSH backend. Never a domain-joined workstation.
    Gate skill writes and new skills. Turn on the skill write-approval gate so every skill the agent creates or edits is staged for human review. Review staged skills with the seriousness you give code changes; functionally they are.
    Least-privilege credentials. Give the agent scoped keys with hard spend caps, separate from any human admin account. Never one credential that unlocks both infrastructure and production data.
    Disable consumer chat channels, or fence them properly. If the pilot needs messaging, use a dedicated workspace with explicit user allowlists and pairing codes; if not, run CLI-only. Do not bridge an enterprise agent to a personal Telegram account.
    Central logging. Ship gateway and session logs to your existing log platform on day one. Log authorisation denials, approval decisions and skill writes at minimum.
    A kill switch that is really a switch. Hermes does not ship a single named panic button; build one. Stopping the gateway service, revoking platform tokens and disabling API keys are three independent ways to stop it — documented and tested, and placed outside the agent, since Hermes deliberately blocks self-restart from inside its own supervised process.
    Keep it updated, and say no to the easy paths. Run updates for security patches, keep allow-all-user flags off in production, and treat “just disable approvals for the pilot” as the decision it really is.

    Field notes

    I run Hermes myself across my own operations, so these come from real deployments, not lab speculation. Tool names stay; internal infrastructure stays out.

    – Secrets do end up in transcripts. A dedicated scanning and rotation process found hundreds of credential-shaped findings in Hermes session transcripts over a few months — API keys and bearer tokens reaching cloud model contexts through normal tool use. Hermes redacts tool error output, but that is one layer; what the agent reads can still reach a model prompt. Scanning after the fact is no substitute for not feeding it secrets.
    – Skill self-management is double-edged. The agent’s ability to create and edit its own skills is useful — and it also meant every profile loaded the full skill catalogue regardless of relevance, wasting tokens and polluting context with instructions for domains that did not apply. Per-profile isolation was needed to fix it. If the agent writes its own procedures, someone has to review what accumulated.
    – Approval gates create friction — and that friction is the point. My approval gate blocking routine cleanup commands (think `rm -rf` on temp directories after agent work) caused files to pile up. The fix is not to weaken the gate; it is to document an approved alternative path. If your team starts asking to disable approvals to “get things moving”, you have found the real control.
    – Monitoring the agent matters as much as the agent itself. My own budget-and-spend guard cron fired a false critical alert for days because of a logic quirk — reading the wrong figure as budget exhaustion. Automated agents generate automated noise; if nobody owns the monitoring that watches the agent, false alarms and real ones look identical.

    Pre-deployment checklist

    Before Hermes (or anything like it) touches enterprise data:

    1. Written threat model covering injection via every content source the agent reads.
    2. Command execution sandboxed — container or dedicated host, non-root, resource-limited.
    3. Skill write-approval enabled; a named human reviews staged skills.
    4. Credential inventory complete; agent keys scoped, capped and separable.
    5. Chat channels either disabled or on allowlists behind a dedicated workspace.
    6. Central logging live and queried at least once before go-live.
    7. Kill switch documented, owned and tested from outside the agent.
    8. YOLO and approval-off modes blocked by configuration review.
    9. Update and patch cadence assigned to a named owner.
    10. A rollback: what you will do when the first incident happens.

    Most of this is unglamorous. None of it is optional. Agentic AI rewards teams that treat the control plane as the product.

    If your team is evaluating agentic AI and wants a second pair of eyes on the threat model before a pilot starts, my services page covers security and security strategy work for UK businesses — or get in touch and we can talk through where you are.

    Sources

    – WSJ Pro, “Nous Research Scores $90 Million to Bring Open-Source AI Assistant to Enterprises”, 7 October 2026 (funding figure, valuation, enterprise strategy, download count).
    – Hermes Agent official documentation, Nous Research: overview, skills system, security user guide, messaging gateway.
    – The Hacker News, “Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It”, 9 July 2026, covering the AI Now Institute “Friendly Fire” proof of concept.

    Flagged, not stated as fact: “kill switch” is operational framing, not a documented Hermes feature; prompt-injection evidence cited is from competing agents; download counts are vendor-reported via WSJ.

  • Before You Launch an AI Assessment, Fix the Operating Model

    Before You Launch an AI Assessment, Fix the Operating Model

    A lot of AI advisory offers now start with an assessment.

    The problem is that many of these offers are still being built like marketing assets rather than client-facing systems.

    If the output influences buying decisions, budget allocation, compliance posture, or board discussion, the operating model behind it matters as much as the prompt or the front end. Recent GitHub work around an AI consultancy assessment build, plus reliability work in adjacent automation repos, makes that obvious.

    The recent signals are not about polish alone

    One assessment build in particular stood out this week.

    The visible activity was not just about shipping a shiny MVP. It included concrete follow-up work such as:

    • provider fallback handling for report generation
    • safer rendering of generated reports and clearer visitor handoff paths
    • lead email notification flows
    • privacy, GDPR, and security controls
    • a protected admin dashboard for internal review

    That list is commercially useful because it shows the build moving away from “can we generate an AI report?” and toward the harder question: “can we run this as a client-facing service?”

    The same instinct showed up elsewhere. In one public agent platform, recent changes added approval requirements around sensitive gateway replacement paths and tightened behaviour when an API server is explicitly disabled. In another internal management context, recent work also focused on surfacing failed or missing configuration steps as real errors rather than false-green output.

    An AI assessment is a service, not a content asset

    This is the point many firms miss.

    An AI assessment may arrive through a landing page, but from the user’s point of view it behaves like a service. It collects inputs. It processes them. It generates output that may shape strategy. It creates follow-up work for your team. It may retain commercially sensitive information. It may trigger email workflows or lead handling.

    That means buyers, especially in law firms, healthcare organisations, PE-backed businesses, and regulated SMEs, will judge it on more than whether the wording feels intelligent.

    They will care about questions such as:

    • What happens if the model fails halfway through a report?
    • Where does the submitted information go?
    • Who can see the results internally?
    • Will someone follow up while the lead is still warm?

    Those are operating-model questions. If they are answered late, the launch becomes fragile. If they are answered early, the assessment becomes a serious commercial asset.

    The four controls I would design before launch

    When I look at the recent issue set, I see four controls that should exist before any AI assessment is treated as production-grade.

    1. Fallbacks for report generation

    Provider fallback handling is one of the first giveaways that the team is thinking properly.

    If your report workflow depends on a single provider, a temporary outage or degraded model response can turn a promising user journey into a dead end. A fallback model path does not need to be elaborate on day one, but it does need to exist. You should know:

    • which provider is primary
    • which fallback path is acceptable
    • how quality is checked before the output is shown
    • what the user sees if both paths fail

    2. Safe rendering and an explicit handoff path

    Safe rendering and an explicit handoff path may sound like front-end housekeeping, but they are more important than that.

    AI-generated output often carries awkward structure, inconsistent formatting, and the occasional sentence that reads far more confidently than the evidence supports. Treat output rendering as a control surface: sanitize it, structure it, keep the language disciplined, then give the reader a clear next step.

    A practical CTA is part of the safety model here, not just the conversion model. If the output is intended to open a commercial conversation rather than substitute for expert judgement, the interface should say so and point naturally to the services page or the contact page.

    3. Privacy, GDPR, and role-based access

    For UK buyers, especially in legal and healthcare environments, privacy, GDPR, and role-based access are where a build starts becoming credible.

    An assessment tool often collects exactly the sort of operational detail that organisations do not want sprayed across logs, inboxes, and loosely protected admin views. Decide early:

    • what data is stored
    • what is redacted or minimised
    • how long submissions are retained
    • which internal roles can access raw answers
    • what the lawful basis and privacy notice look like

    A protected admin dashboard belongs in the same conversation. Internal convenience is not a good enough reason for weak access control.

    4. Truthful monitoring and approvals around the edges

    The adjacent repo activity matters here because it reinforces a broader discipline.

    If a nightly check can go false-green, or a gateway action can happen without the right approval, your delivery stack is already telling you something about risk appetite. Public agent-platform fixes and internal management work both point to the same lesson: the system around the assessment needs honest signals and controlled change paths.

    For a buyer-facing AI assessment, keep one rule in mind: do not automate yourself into ambiguity.

    If emails fail, surface it. If a fallback is used, log it. If an admin action changes routing or content, require the right level of review. If an integration is disabled, behave safely and obviously rather than trying to muddle through.

    That is how you keep confidence high without pretending the system is infallible.

    Where this lands commercially

    This is not only a product design issue. It affects how the market reads your firm.

    A well-run assessment signals seniority. It tells a prospect that you understand not just AI tooling, but governance, service design, delivery risk, and follow-through. A weakly controlled assessment suggests the front-end story is outrunning the operating reality behind it.

    For founder-led firms, that usually shows up as missed leads, messy handovers, and inconsistent output. For more regulated sectors, it can create trust friction before a proposal is even on the table.

    A sensible pre-launch checklist

    Before putting an AI assessment in front of serious buyers, I would want five things in place:

    • a tested fallback path for report generation
    • sanitised, structured output with a clear advisory disclaimer where needed
    • a defined CTA path into the services page or the contact page
    • privacy, retention, and access decisions written down
    • alerts and admin workflows that fail visibly rather than silently

    That will not make the launch flashy. It will make it usable.

    And in this category, usable beats flashy every time.

    If you are building an AI assessment, advisory funnel, or client-facing automation journey and want the surrounding controls designed properly, my services cover that mix of security leadership, IT operating model, and AI architecture. If you already have something live, get in touch and I can help you pressure-test it before it becomes a trust problem.

  • GitHub Weekly — Security Hardening, Governance Cleanup, and Website Delivery

    GitHub Weekly — Security Hardening, Governance Cleanup, and Website Delivery

    This week’s GitHub activity had a very familiar shape: a lot of small changes, but a very clear direction.

    When I pulled the last seven days together, I ended up with 250 events across 64 repositories. The detail varied, but the pattern was hard to miss. The most useful work clustered around three themes: making systems safer to operate, making decisions easier to trace, and moving real work out of drafts and into something usable.

    That combination matters. It is easy to celebrate a feature release and overlook the quieter work that makes the next release easier, safer, and less dependent on memory. This week was mostly about exactly that.

    What happened

    1. The hardening work kept moving

    The busiest thread was around the Hermes management side of the stack. There were issues and pull requests covering gateway restart behaviour, profile-scoped tools and memory surfaces, local Vault health, OAuth token expiry, dependency CVEs, and a few routing and performance concerns.

    That is the kind of activity I like to see in a living system, even when it is uncomfortable. The work was not cosmetic. It was focused on failure modes:

    • what happens when the secrets backend is sealed
    • what happens when a token expires unexpectedly
    • what happens when dependency drift creates exposure in the runtime
    • what happens when routing logic gets too expensive to keep running blindly
    • what happens when multiple operators need clean boundaries around tools and state

    In other words, the week was spent asking the right questions before the answers became incidents.

    There was also a useful operational thread around keeping the system honest: adding safety nets, reviewing carry-forward behaviour, and tightening the control plane around restarts and state. That kind of work rarely looks dramatic in a changelog, but it is often where the real reliability gains come from.

    2. Governance became more concrete

    A second pattern showed up in the roadmap and control repositories. There were commits and pull requests for provisioning scripts, README links, alert-rule tuning, and monitoring documentation.

    That matters because strategy is only useful when it can be executed repeatedly.

    A plan is just a plan until it has:

    • a provisioning path
    • a documented handover
    • a clear monitoring expectation
    • a change history that another person can follow

    The activity this week pushed in that direction. Roadmap work became more operational. Monitoring guidance became more explicit. Decision-making became easier to track. Even the recurring “decision desk” style updates are useful in that sense: they turn vague progress into a traceable record.

    That is particularly important in AI and automation work, where teams can move quickly but still leave behind unclear assumptions. The more complex the stack gets, the more valuable it becomes to treat governance as part of the delivery process rather than as a separate admin task.

    3. Website work moved from intention to delivery

    The third thread was more visible: website work.

    There was a full redesign path on one service site, including layout work, deploy tooling, and a clear move from mockups to implemented pages. On the content side, the blog workflow itself also kept moving, with a new weekly roundup drafted and the editorial queue updated.

    I think this is an underrated signal. People often talk about code, but delivery includes the path around the code too:

    • the build steps
    • the draft content
    • the publication workflow
    • the editorial queue
    • the handoff between “done locally” and “live somewhere useful”

    If those pieces are weak, the site may look finished while still being awkward to maintain. If they are strong, the site becomes easier to update, easier to trust, and easier to keep current.

    That same lesson shows up in content systems, operations tooling, and AI workflows. The system is only as strong as the path from intent to output.

    Key takeaways

    A week like this leaves a few practical lessons.

    • Security debt is easiest to fix before it becomes visible. The moment a sealed Vault, an expired token, or a dependency CVE shows up in a weekly review is the moment to deal with it.
    • Operational boundaries matter more as systems grow. Profile-scoped tools, explicit memory surfaces, and predictable restart behaviour are all examples of the same idea: reduce ambiguity.
    • Roadmaps need executable steps, not just aspirations. Provisioning scripts, alert-rule updates, and readable docs make a roadmap real.
    • Delivery includes the publishing path. A draft that never reaches the right place is only half a result.
    • The best week-over-week improvement is often cumulative, not flashy. Small fixes across security, governance, and publishing add up to a stronger operating model.

    A practical standard

    If I had to compress the week into one rule, it would be this:

    • if it can fail, define the failure mode
    • if it repeats, make it traceable
    • if it matters, write it down
    • if it ships, make the path to shipping reliable

    That is a good standard for AI work, but it is just as useful for infrastructure, websites, and internal operations. The details change. The principle does not.

    The goal is not to eliminate all uncertainty. The goal is to make the important parts of the system clear enough that they can be operated without guesswork.

    Closing thought

    The most useful work this week was not a single large feature. It was the accumulation of smaller changes that make a system easier to run: better failure handling, clearer governance, more repeatable delivery, and a stronger publishing path.

    That is usually where durable progress lives.

    If you are working through a similar mix of security, automation, and delivery problems, the AI & Automation Architecture service is a good starting point. Or get in touch if you want to talk through the shape of the system before it becomes the problem.

  • When the Rules Become the Product

    When the Rules Become the Product

    This week kept returning to the same idea: the most useful engineering work is often the work that makes a system easier to trust.

    That does not always look exciting from the outside. It is not always a new feature, a flashy demo, or a dramatic redesign. More often it is the quieter work of making rules explicit, tightening feedback loops, removing ambiguity, and making the next decision easier than the last one.

    Across the repos I watched this week, that pattern showed up again and again. The common thread was less about adding novelty and more about turning guesswork into something people can actually operate.

    What happened

    1. hermes-mgmt kept pushing on cost, routing, and safety

    hermes-mgmt was the busiest repo in the set, and the signal was very clear: the platform is maturing by making its own guard rails stronger.

    A few of the issues were a good reminder that reliability starts with honesty. One thread called out how expensive large context windows become when autonomous loops keep calling them. Another flagged a provider routing problem where fallback behaviour was not matching the intent of the system. There was also a security issue around dependency CVEs and overly permissive local state handling, plus a series of local service defects that needed attention before they could become bigger problems.

    The pull requests told the same story from the implementation side. There were updates around shared spend visibility, stronger routing defaults, helper scripts for operator actions, secret-finding classifiers, carry guard hooks, resilient re-apply logic, memory activation, and better health checks. In plain English: this is the part of the work where a system stops relying on optimism and starts relying on policy.

    That matters because most production problems are not caused by one spectacular failure. They come from small inconsistencies that accumulate until the platform becomes harder to predict than it should be. The work in hermes-mgmt was a good example of the opposite: make the rules visible, make the fallback paths deliberate, and make the expensive behaviour harder to trigger by accident.

    2. ricambio-ai-roadmap moved product behaviour into the open

    The second big theme lived in ricambio-ai-roadmap, where the work on pilot2_email and the surrounding platform showed a lot more operational maturity than a casual observer might expect.

    There were fixes for transient IMAP failures, a fallback provider chain, and intent-based routing. There was also a 48-hour expiry policy, an in-app help section, and review-session documentation that makes the decision path much easier to follow later. At the same time, the live-platform review surfaced issues around basic-auth defaults, placeholder leakage risk, console labelling, and filter gaps.

    That mix is important. It means the project is no longer just building features; it is building a way to reason about those features.

    If a workflow is going to make decisions on behalf of a user, then the decision rules need to be legible. If a review finds a weak spot, the fix should not just patch the symptom. It should make the system easier to explain the next time somebody has to operate it.

    That is why the recent work here feels significant. It is not only improving the product. It is making the product harder to misunderstand.

    3. richardham-web-and-brand treated content and navigation as part of the system

    The web and brand repo had a very different surface area, but the same underlying pattern.

    There was work on missing sector pages, menu ordering, the AI stack page, homepage hero messaging, and proof-point content. There was also a rewrite of a blog post that had been flagged for confidential or internal detail. That kind of content cleanup is easy to underestimate, but it is exactly the sort of work that keeps a site coherent and credible.

    The best websites do not just look polished. They make it obvious where to go next.

    When navigation is clear, a visitor does not have to guess. When page structure is consistent, a service line is easier to understand. When internal detail is removed from public-facing copy, the story becomes more focused and more trustworthy. That is why I think of this sort of content work as part of the system, not a separate marketing task.

    It is also a useful reminder that design discipline and operational discipline are cousins. Both are about reducing friction. Both are about making the important thing easier to find. And both become more valuable as the system grows.

    4. Smaller repos kept reinforcing the same direction

    A few other repos pointed in the same direction even if they were not as noisy.

    dh-electrical-uk-website had redesign work and deploy tooling, which is a nice example of making a site feel more coherent and easier to ship.

    HamMediaLabs, lk-ai-roadmap, control-tower, and ai-cost-tracker all contributed to the broader picture as well: the more a platform matures, the more the useful work shifts toward clarity, repeatability, and control.

    That is a pattern I like because it is easy to miss in the moment. From far away, all of this can look like a list of unrelated tasks. Up close, it is really one story told in different repos: make the rules explicit, make the system observable, and make the next step easier to take.

    Key takeaways

    A few lessons stood out this week:

    • Routing should be policy, not folklore. If a system needs to choose between paths, the choice should be deliberate and explainable.
    • Security work belongs in the main workflow. Review findings, dependency checks, and permission problems are not side quests; they are part of keeping the platform honest.
    • Visibility is worth more than cleverness. Spend tracking, health checks, and honest dashboards make a system easier to run than vague confidence ever will.
    • Content operations matter. Navigation, structure, and public copy are part of the user experience and deserve the same discipline as the code behind them.
    • The best guard rail is a clear rule. The less people have to remember, the less likely the system is to depend on luck.

    Closing thought

    The strongest theme this week was not speed. It was trust.

    A system becomes easier to trust when the important choices are written down, the fallback paths are deliberate, and the rough edges are visible before they become incidents. That is true for routing policies, for security reviews, for website navigation, and for the way content moves from draft to publish.

    If you are trying to make an AI or automation workflow feel less like improvisation and more like operations, the next step usually is not more complexity. It is more clarity.

    And if that is the kind of cleanup you are wrestling with, get in touch.

  • Containment Patterns for Autonomous AI Agents

    Containment Patterns for Autonomous AI Agents

    You wouldn’t give a new employee the keys to every office, the admin password to every system, and a company credit card on day one. You’d onboard them gradually — scoped access, supervised actions, and a clear audit trail of what they did and why.

    Autonomous AI agents deserve the same treatment. Arguably more, because they can act faster, at greater scale, and with less inherent judgment than any human hire.

    Yet the pattern I see repeatedly is teams wiring agents directly into production systems with broad API keys, unrestricted network access, and no oversight. The agent works brilliantly — until it doesn’t. And when it goes wrong, nobody can explain what happened or why.

    This is a containment problem. And it’s solvable.

    Why containment matters now

    Autonomous agents are moving from demos into production. They’re reading emails, writing database records, triggering deployments, and calling external APIs. Each of those actions carries real business risk.

    The uncomfortable truth is that today’s agents are semi-trusted at best. Hallucinations aren’t just a chatbot annoyance — they’re an action an agent might take on a live system. A misinterpreted prompt can become a bulk delete. A confused tool call can cascade into an outage.

    Regulators are watching. The EU AI Act’s transparency and risk management requirements are already in force for high-risk systems. UK boards are starting to ask pointed questions about AI governance. If you can’t explain what your agents did and what guardrails were in place, you have a problem that no amount of prompt engineering will fix.

    The five containment patterns

    The patterns below are drawn from how we’d sandbox any untrusted or semi-trusted process — adapted for the specific risks that autonomous agents introduce. I’ve been implementing these in SentinelForge, a platform for running agents with strict governance, auditing, and observability.

    1. Process isolation

    Agents should run in their own isolated environment — a separate container or VM, not on a shared host alongside your production workloads.

    This means:

    • Dedicated runtime per agent or agent class, with its own filesystem and process namespace
    • Resource limits (CPU, memory, disk) so a runaway agent can’t starve other services
    • Immutable infrastructure — the agent’s environment is defined in code, rebuilt from scratch each run, and never patched in place

    If the agent is compromised or behaves unexpectedly, the blast radius stops at the container boundary.

    2. Network segmentation

    An agent should only be able to reach the endpoints it explicitly needs. Nothing more.

    In practice:

    • Egress filtering — whitelist approved domains and IP ranges; block everything else
    • No direct access to internal networks, metadata services (like cloud instance metadata endpoints), or other agents’ environments
    • DNS-level controls to prevent DNS exfiltration or calls to unexpected services

    Think of it like a corporate network with VLANs. The marketing intern doesn’t need access to the finance database. Your agent doesn’t need access to the public internet.

    3. Credential scoping

    This is where most agent deployments go wrong. A single long-lived API key with broad permissions is the agent equivalent of a master key.

    Instead:

    • Time-limited tokens — credentials that expire after a task or session, not months
    • Minimum privilege — if the agent only needs to read from a database, it doesn’t get write access
    • Brokered access — credentials are injected at runtime by a secrets manager, never stored in the agent’s environment or prompt
    • Per-task credentials — different actions get different tokens, so a compromise in one area doesn’t cascade

    4. Output validation

    Before an agent’s action hits a real system, it should pass through a validation layer.

    This means:

    • Schema validation — does the agent’s requested action match an expected structure?
    • Policy checks — is this action allowed given the current context, user, and risk level?
    • Human-in-the-loop gates for high-risk actions (bulk operations, deletions, external communications)
    • Dry-run capability — the ability to simulate what the agent would do before it does it

    This isn’t about slowing agents down. It’s about making sure the action that executes is the action you intended.

    5. Audit logging

    Every action an agent takes should be recorded in a tamper-evident log that’s separate from the agent itself.

    Capture:

    • What the agent did (the action, the target, the parameters)
    • Why it did it (the prompt, the reasoning chain, the tool call context)
    • When it happened (with reliable, centralised timestamps)
    • What the outcome was (success, failure, validation result)

    This log is your forensic trail when something goes wrong. It’s also your evidence for compliance, board reporting, and continuous improvement.

    A practical containment checklist

    If you’re deploying autonomous agents today, here’s a quick audit:

    • [ ] Each agent runs in an isolated container or VM with resource limits
    • [ ] Network egress is restricted to an explicit allowlist
    • [ ] No long-lived credentials — tokens are time-limited and minimum-privilege
    • [ ] Credentials are brokered at runtime, never hardcoded or stored in prompts
    • [ ] Agent actions pass through a validation or policy layer before execution
    • [ ] High-risk actions require human approval
    • [ ] All actions are logged to a tamper-evident, centralised audit trail
    • [ ] Logs are reviewed regularly, not just when something goes wrong

    If you can’t check at least six of those boxes, your agents are running with more freedom than most of your employees.

    The principle is simple

    Autonomous agents are powerful. That power needs guardrails — not because the technology is malicious, but because it’s fast, scalable, and imperfect. The same qualities that make agents valuable are the qualities that make containment essential.

    The patterns aren’t exotic. They’re the same ones we’ve used for decades to manage untrusted code, third-party integrations, and new employees. The difference is that agents can act at machine speed, so your guardrails need to be just as fast and just as automated.

    This is the problem I’m working on with SentinelForge — making these patterns practical and deployable, not just theoretical.

    If agent containment is on your roadmap, get in touch or take a look at the projects I’m building in this space.

  • The M365 Audit You Can Run Before Calling a Consultant

    The M365 Audit You Can Run Before Calling a Consultant

    Last month I published a post about the M365 security baseline most SMEs skip — the default tenant configuration that leaves businesses exposed because no one with security expertise has reviewed it since the initial migration.

    That post explained what to check. This one gives you the tool to check it.

    I built an open-source M365 Audit Toolkit and put it on GitHub. It is a set of read-only PowerShell modules that connect to your tenant using your credentials, interrogate the configuration, and produce a structured report of what is misconfigured, missing, or ranging beyond what you would reasonably accept. It does not change anything. It does not write data. It reads, evaluates, and reports.

    And it is designed so that you can run it yourself — before you pick up the phone to a consultant.

    Why a Self-Service Audit

    Most UK SMEs operate in a state of confident uncertainty about their M365 tenant. The IT provider set it up. It works. Email flows. SharePoint files sync. Teams calls connect. Everything appears fine.

    But “fine” is not a security posture. It is an absence of visible failure.

    The problem is that the gaps in an M365 tenant are invisible until they are not. A compromised account exposes every SharePoint site the user can reach. A forgotten guest account with access to a shared folder persists indefinitely. A mailbox that has never been audited leaves no trail when something goes wrong. These gaps do not generate alerts. They do not appear in the admin console with a red warning icon. They sit quietly until a breach unmasks them, a subject access request forces you to find every piece of personal data in the tenant, or a client’s due diligence questionnaire asks questions you cannot answer.

    I built the toolkit because the cost of a structured audit should not be a barrier to knowing where you stand. You should not need to engage a consultant just to find out whether your conditional access policies are configured, your admin roles are clean, or your retention policies align with your data retention schedule.

    Run the audit first. Understand your gaps. Then decide whether you need help closing them.

    What the Toolkit Covers

    The M365 Audit Toolkit is modular. You can run the full audit or pick the modules relevant to your situation currently and build from there. At present it covers five areas.

    Security Baseline Assessment. Checks MFA enforcement across all users, verifies that legacy authentication protocols is blocked, reviews conditional access policy configuration, mailbox auditing status, and DLP label deployment. This maps directly to the seven controls most SMEs skip.

    Admin Role Hygiene. Identifies every global administrator in the tenant, flags accounts that should not hold that role, checks for service principal permissions that grant equivalent access, and reports on role-based access control adoption for other administrative functions. If your tenant has four, six, or eight global admins, this module will tell you exactly who they are and what they can do.

    Guest Access Audit. Enumerates every external guest account in the tenant, what they can access, when they were last active, and whether access reviews are configured. This is the module that finds the former contractor who still has access to your shared folders three years after their engagement ended — which is more common than you would think.

    SharePoint and OneDrive Governance. Reviews site-level sharing settings, detects externally shared content, checks for orphaned sites, and reports on storage allocation and versioning configuration. If you have ever wondered how much of your organisation’s data is sitting in personal OneDrive accounts that the business does not back up and cannot access, this module provides the answer.

    AI Readiness Evaluation. Assesses your tenant’s readiness to adopt Copilot and other AI services safely — reviewing sensitivity label coverage, data loss prevention configuration, and access controls that would govern what an AI service can surface to users. This is increasingly relevant as Microsoft bundles Copilot into enterprise and business tiers.

    How to Run It

    The toolkit uses interactive MFA authentication, meaning it connects as you and inherits your permissions. It does not require app registrations, client secrets, or service accounts. If you have global reader access to the tenant, you can run the audit.

    The general workflow:

    1. Clone the repository from GitHub and review the modules.
    2. Connect to your tenant using interactive browser-based MFA authentication.
    3. Select the modules relevant to your assessment — security baseline, guest access, governance, AI readiness, or all of them.
    4. Review the output as a structured summary showing what passed, what failed, and what needs attention.

    The entire process can be completed in under an hour for a typical SME tenant. The output is a point-in-time snapshot — it does not persist data, and it does not leave artefacts in your tenant beyond the sign-in logs generated by your own authentication.

    When to Call a Consultant

    Running the audit yourself is the right first step. But there are situations where the findings will tell you that it is time to bring in expertise.

    • The report is long and you do not know where to start. If every module returns significant findings, the remediation effort is material and benefits from prioritisation and sequencing — which is exactly what a structured engagement provides.
    • You lack the permissions or authority to make changes. If the audit reveals that conditional access policies need to be reconfigured but your IT provider controls the tenant, the value of the report is in telling you exactly what to ask for and why.
    • You are preparing for client due diligence, a cyber insurance application, or a regulatory review. The audit output gives you a factual baseline, but remediation may need to be documented, evidenced, and in some cases certified.
    • You are adopting Copilot or other AI services. The AI readiness module will tell you where your gaps are, but closing them — sensitivity labels, access controls, DLP policies — is a project that benefits from experience doing it.

    The point is not to avoid consultants. The point is to arrive at that conversation informed, with a clear picture of what needs to be done rather than starting from a blank page.

    The Checklist Before You Pick Up the Phone

    If you want to understand your M365 tenant before committing to an engagement, here is the minimum viable assessment:

    • [ ] Run the security baseline module and resolve any critical MFA or conditional access findings
    • [ ] Run the admin role module and reduce global administrators to two or three accounts
    • [ ] Run the guest access module and revoke access for accounts no longer needed
    • [ ] Review the SharePoint governance report for externally shared sites and orphaned content
    • [ ] Review the AI readiness output if Copilot adoption is on your roadmap

    If you can work through that list and resolve the findings, your tenant is in materially better shape. If you cannot, you now have a specific, evidenced brief for what needs to happen next.

    The M365 Audit Toolkit is available now on GitHub. It is free, read-only, and built for exactly this use case.

    If you run it and the findings warrant a conversation, the Security & Compliance Strategy service covers M365 tenant configuration as part of a broader engagement. Or get in touch with your report — I can tell you within a 30-minute call whether the gaps are ones you can close yourself or whether it is time to bring in support.

  • Building a Secure Agent Control Plane With Observability From Day One

    Building a Secure Agent Control Plane With Observability From Day One

    AI agents are being connected to real business systems at pace. Email inboxes. CRM records. Finance platforms. Document stores. In many organisations, agents now read, write, and decide across these systems — not as a pilot, but as operational infrastructure.

    The problem is that the operational infrastructure around those agents has not kept pace. Teams connect agents to sensitive systems the same way they would connect a chatbot: authenticate, test, deploy. There is no logging layer, no approval gate, no cost tracking, no failure recovery. The agent works until it does not, and when it breaks, nobody knows why.

    The agents themselves are often well-designed. The prompts are thoughtful. The integrations function. But there is no control plane — no layer between the agent and the systems it touches that handles authorisation, logging, rate limiting, approval, and monitoring. Without one, you are running production workloads with no operations team.

    What an Agent Control Plane Actually Is

    An agent control plane is the operational layer that sits between your AI agents and the systems they interact with. It is not a single tool. It is a set of components that collectively ensure agents act safely, their actions are visible, and failures are recoverable.

    Think of it the way you would think about any production system. A web application has authentication, logging, rate limiting, monitoring, and alerting. A database has access controls, backup procedures, and performance monitoring. An agent that reads client records, sends emails, and updates financial data needs the same — arguably more, because its behaviour is less deterministic than a traditional application.

    The control plane answers a set of questions that every production system must answer: Who is allowed to do what? What actually happened? How much did it cost? What do we do when it fails? And can we prove all of this to an auditor, a regulator, or a board?

    The Six Components You Need

    Authentication broker. Agents need credentials to access systems, but those credentials should not live inside the agent or its prompt. A central broker issues scoped, time-limited tokens with minimum permissions. When the token expires, access stops. This is service account management applied to agents.

    Audit logger. Every agent action must be logged in a structured, tamper-evident format. Not just the final output — the full chain: what the agent was asked, which tools it called, what decisions it made, what it executed, and what it returned. Teams log the input and output but miss the intermediate steps. When an agent takes an unexpected action, you need to trace the reasoning that led to it.

    Approval workflow. Not every action should be autonomous. A control plane defines which actions require human approval before execution. Sending an internal summary might be automated. Sending a client-facing email or modifying a financial record should require sign-off. The approval gate sits in the control plane, not in the agent’s prompt — a prompt is a request, not an enforcement mechanism.

    Observability. Tools like Langfuse are designed for this. Observability for agents means tracking execution traces, token usage, latency, error rates, and cost per execution. It means answering questions like: which workflow failed most often last week? Which agent is consuming the most tokens? Is the error rate increasing?

    Cost tracking. Agentic AI is not free. Every model call, every tool invocation, every token consumed has a cost. Without cost tracking per agent, per workflow, and per execution, you cannot budget, optimise, or identify waste.

    Failure recovery. Agents fail. Models time out. APIs return errors. A control plane defines what happens: does it retry? Escalate to a human? Roll back? Without explicit failure recovery, a failed agent either silently drops the task or retries indefinitely, burning tokens and creating duplicate actions.

    A Concrete Example

    Consider an n8n workflow that processes incoming client data: it reads a form submission, enriches the record with data from an external API, updates the CRM, and sends a confirmation email.

    Without a control plane, this workflow runs with a static API key, no logging beyond n8n’s default execution history, no approval gate for the email send, and no cost tracking. If the CRM API returns an error, the workflow fails silently. If the agent sends a confirmation email to the wrong address because the form data was malformed, there is no record of what data it saw or why it made that decision.

    With a control plane, the same workflow runs with a scoped token from the authentication broker, full execution tracing through Langfuse, an approval gate that holds the email send when the confidence score is below a threshold, and automatic retry with escalation on failure. Every execution is logged with its full decision chain. Cost per execution is tracked and surfaced on a dashboard.

    The workflow is the same. The operational posture is completely different.

    Why From Day One Matters

    Retrofitting observability and security into a live system is significantly more expensive than building it in from the start. Not just in money — in time, risk, and organisational friction.

    When you add a control plane after agents are already in production, you must modify every existing workflow to route through the new layer, backfill logs for actions that already happened, and negotiate with teams accustomed to unfettered agent access. In practice, this work costs roughly three times what it would have cost to build the control plane first — before accounting for the risk exposure during the period agents ran without controls.

    Building it from day one means the control plane is part of the deployment process. Every new agent is onboarded through it. Every execution is logged from the first run. Every cost is tracked from the first token. No migration, no retrofitting, no gap.

    What to Do Next

    If you are running agentic AI in your organisation — or planning to — here is where to start.

    1. Inventory your agents. List every agent, workflow, and automated process that takes action on a business system. Include what systems it accesses, what credentials it uses, and what actions it can perform. You cannot secure what you have not catalogued.

    2. Add structured logging. For every agent execution, log the input, the decision chain, the action taken, the output, and the timestamp. Use a consistent schema. Send these logs to a central, append-only store. If you are using n8n, configure each node to log its input and output. Integrate a tracing tool like Langfuse from the start.

    3. Implement approval gates for high-risk actions. Define which actions require human sign-off: anything client-facing, anything that modifies financial data, anything that changes system configuration. Build the approval gate into the control plane, not into the agent’s prompt.

    4. Set up observability. Deploy an observability layer that tracks execution traces, error rates, token usage, and cost per workflow. Build dashboards. Set alerts for anomalies — sudden cost increases, rising error rates, unusual execution patterns.

    5. Define failure recovery. For every workflow, document what happens on failure. Retry logic, escalation paths, rollback procedures. Test these before you need them.

    The organisations that will extract the most value from agentic AI are not the ones that move fastest. They are the ones that move safely — with the infrastructure to observe, control, and recover from the inevitable failures.

    If you are building agentic systems and need help designing the control plane, observability, and security architecture around them, the AI & Automation Architecture service covers exactly this. For examples of what this looks like in practice, see recent projects.

  • Building a Secure Agent Control Plane With Observability From Day One

    Building a Secure Agent Control Plane With Observability From Day One

    AI agents are being connected to real business systems at pace. Email inboxes. CRM records. Finance platforms. Document stores. In many organisations, agents now read, write, and decide across these systems — not as a pilot, but as operational infrastructure.

    The problem is that the operational infrastructure around those agents has not kept pace. Teams connect agents to sensitive systems the same way they would connect a chatbot: authenticate, test, deploy. There is no logging layer, no approval gate, no cost tracking, no failure recovery. The agent works until it does not, and when it breaks, nobody knows why.

    The agents themselves are often well-designed. The prompts are thoughtful. The integrations function. But there is no control plane — no layer between the agent and the systems it touches that handles authorisation, logging, rate limiting, approval, and monitoring. Without one, you are running production workloads with no operations team.

    What an Agent Control Plane Actually Is

    An agent control plane is the operational layer that sits between your AI agents and the systems they interact with. It is not a single tool. It is a set of components that collectively ensure agents act safely, their actions are visible, and failures are recoverable.

    Think of it the way you would think about any production system. A web application has authentication, logging, rate limiting, monitoring, and alerting. A database has access controls, backup procedures, and performance monitoring. An agent that reads client records, sends emails, and updates financial data needs the same — arguably more, because its behaviour is less deterministic than a traditional application.

    The control plane answers a set of questions that every production system must answer: Who is allowed to do what? What actually happened? How much did it cost? What do we do when it fails? And can we prove all of this to an auditor, a regulator, or a board?

    The Six Components You Need

    Authentication broker. Agents need credentials to access systems, but those credentials should not live inside the agent or its prompt. A central broker issues scoped, time-limited tokens with minimum permissions. When the token expires, access stops. This is service account management applied to agents.

    Audit logger. Every agent action must be logged in a structured, tamper-evident format. Not just the final output — the full chain: what the agent was asked, which tools it called, what decisions it made, what it executed, and what it returned. Teams log the input and output but miss the intermediate steps. When an agent takes an unexpected action, you need to trace the reasoning that led to it.

    Approval workflow. Not every action should be autonomous. A control plane defines which actions require human approval before execution. Sending an internal summary might be automated. Sending a client-facing email or modifying a financial record should require sign-off. The approval gate sits in the control plane, not in the agent’s prompt — a prompt is a request, not an enforcement mechanism.

    Observability. Tools like Langfuse are designed for this. Observability for agents means tracking execution traces, token usage, latency, error rates, and cost per execution. It means answering questions like: which workflow failed most often last week? Which agent is consuming the most tokens? Is the error rate increasing?

    Cost tracking. Agentic AI is not free. Every model call, every tool invocation, every token consumed has a cost. Without cost tracking per agent, per workflow, and per execution, you cannot budget, optimise, or identify waste.

    Failure recovery. Agents fail. Models time out. APIs return errors. A control plane defines what happens: does it retry? Escalate to a human? Roll back? Without explicit failure recovery, a failed agent either silently drops the task or retries indefinitely, burning tokens and creating duplicate actions.

    A Concrete Example

    Consider an n8n workflow that processes incoming client data: it reads a form submission, enriches the record with data from an external API, updates the CRM, and sends a confirmation email.

    Without a control plane, this workflow runs with a static API key, no logging beyond n8n’s default execution history, no approval gate for the email send, and no cost tracking. If the CRM API returns an error, the workflow fails silently. If the agent sends a confirmation email to the wrong address because the form data was malformed, there is no record of what data it saw or why it made that decision.

    With a control plane, the same workflow runs with a scoped token from the authentication broker, full execution tracing through Langfuse, an approval gate that holds the email send when the confidence score is below a threshold, and automatic retry with escalation on failure. Every execution is logged with its full decision chain. Cost per execution is tracked and surfaced on a dashboard.

    The workflow is the same. The operational posture is completely different.

    Why From Day One Matters

    Retrofitting observability and security into a live system is significantly more expensive than building it in from the start. Not just in money — in time, risk, and organisational friction.

    When you add a control plane after agents are already in production, you must modify every existing workflow to route through the new layer, backfill logs for actions that already happened, and negotiate with teams accustomed to unfettered agent access. In practice, this work costs roughly three times what it would have cost to build the control plane first — before accounting for the risk exposure during the period agents ran without controls.

    Building it from day one means the control plane is part of the deployment process. Every new agent is onboarded through it. Every execution is logged from the first run. Every cost is tracked from the first token. No migration, no retrofitting, no gap.

    What to Do Next

    If you are running agentic AI in your organisation — or planning to — here is where to start.

    1. Inventory your agents. List every agent, workflow, and automated process that takes action on a business system. Include what systems it accesses, what credentials it uses, and what actions it can perform. You cannot secure what you have not catalogued.

    2. Add structured logging. For every agent execution, log the input, the decision chain, the action taken, the output, and the timestamp. Use a consistent schema. Send these logs to a central, append-only store. If you are using n8n, configure each node to log its input and output. Integrate a tracing tool like Langfuse from the start.

    3. Implement approval gates for high-risk actions. Define which actions require human sign-off: anything client-facing, anything that modifies financial data, anything that changes system configuration. Build the approval gate into the control plane, not into the agent’s prompt.

    4. Set up observability. Deploy an observability layer that tracks execution traces, error rates, token usage, and cost per workflow. Build dashboards. Set alerts for anomalies — sudden cost increases, rising error rates, unusual execution patterns.

    5. Define failure recovery. For every workflow, document what happens on failure. Retry logic, escalation paths, rollback procedures. Test these before you need them.

    The organisations that will extract the most value from agentic AI are not the ones that move fastest. They are the ones that move safely — with the infrastructure to observe, control, and recover from the inevitable failures.

    If you are building agentic systems and need help designing the control plane, observability, and security architecture around them, the AI & Automation Architecture service covers exactly this. For examples of what this looks like in practice, see recent projects.

Powered by CookieAdmin