<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>lgkm.org field notes</title>
  <subtitle>The state of modern IT and security</subtitle>
  <link href="https://lgkm.org/notes/feed.xml" rel="self"/>
  <link href="https://lgkm.org/notes/"/>
  <id>https://lgkm.org/notes/</id>
  <updated>2026-10-29T00:00:00Z</updated>
  <author><name>Simon Bennett</name></author>
  <entry>
    <title>The AI supply chain: models, plugins and tool servers as third parties</title>
    <link href="https://lgkm.org/notes/ai-supply-chain-third-parties/"/>
    <id>https://lgkm.org/notes/ai-supply-chain-third-parties/</id>
    <updated>2026-10-29T00:00:00Z</updated>
    <category term="ai"/>
    <summary>An AI feature is assembled from parts other people made: a hosted model, downloaded weights, editor plugins, tool servers and SaaS connectors. Each is a supplier with access, and the incidents of the last two years came through exactly those parts. Most third-party registers list only the first.</summary>
  </entry>
  <entry>
    <title>DNSSEC: why it exists, who uses it and what it has broken</title>
    <link href="https://lgkm.org/notes/dnssec-why-who-and-what-broke/"/>
    <id>https://lgkm.org/notes/dnssec-why-who-and-what-broke/</id>
    <updated>2026-10-27T00:00:00Z</updated>
    <category term="network"/>
    <summary>DNSSEC lets a resolver check that a DNS answer really came from the owner of the name. It was built to stop forged answers, it is switched on far more by resolvers than by domain owners, and when it fails it takes whole domains, and once a whole country's zone, offline.</summary>
  </entry>
  <entry>
    <title>Email was built to trust everyone: TLS, SPF, DKIM and DMARC, and what each one breaks</title>
    <link href="https://lgkm.org/notes/email-security-patches/"/>
    <id>https://lgkm.org/notes/email-security-patches/</id>
    <updated>2026-10-27T00:00:00Z</updated>
    <category term="network"/>
    <summary>Email still runs on a 1980s protocol that lets any server claim to be anyone and send in the clear. Opportunistic TLS, SPF, DKIM and DMARC were added on top, one problem at a time. Each fixes something real, each breaks something else, and none of them stops a lookalike domain.</summary>
  </entry>
  <entry>
    <title>Jev, the model that only decides: where it fits in security work</title>
    <link href="https://lgkm.org/notes/jev-use-cases/"/>
    <id>https://lgkm.org/notes/jev-use-cases/</id>
    <updated>2026-10-27T00:00:00Z</updated>
    <category term="ai"/>
    <summary>Jev is a new kind of AI model that writes no text. It reads something and answers typed questions with a choice, a score or a yes/no probability, in a fraction of a second and for a fraction of a cent. That makes it a good first sorter for alerts, data labels and agent actions, and a poor final judge.</summary>
  </entry>
  <entry>
    <title>Which language model for which job</title>
    <link href="https://lgkm.org/notes/which-language-model-for-which-job/"/>
    <id>https://lgkm.org/notes/which-language-model-for-which-job/</id>
    <updated>2026-10-27T00:00:00Z</updated>
    <category term="ai"/>
    <summary>Large language models now come in four kinds, not one: frontier models for the hardest work, workhorses for most of it, small fast models for volume, and open-weight models you run yourself. The names change every month and the kinds do not, so choose by job, test one size down, and write policy about kinds rather than names.</summary>
  </entry>
  <entry>
    <title>IP address or identity: what should actually let someone in?</title>
    <link href="https://lgkm.org/notes/ip-address-or-identity/"/>
    <id>https://lgkm.org/notes/ip-address-or-identity/</id>
    <updated>2026-10-26T00:00:00Z</updated>
    <category term="network"/>
    <summary>An IP allowlist says where a request comes from. Identity says who or what is asking. Both still have a place, on the internet and inside the network, but each only works when certain things are in place, and each fails in its own way.</summary>
  </entry>
  <entry>
    <title>Post-quantum migration starts with a cryptography inventory</title>
    <link href="https://lgkm.org/notes/post-quantum-starts-with-inventory/"/>
    <id>https://lgkm.org/notes/post-quantum-starts-with-inventory/</id>
    <updated>2026-10-26T00:00:00Z</updated>
    <category term="architecture"/>
    <summary>The new quantum-safe algorithms are standard and the deadlines are set: 2028 to know what you have, 2035 to finish. The hard part is not the maths. It is finding every place an organisation uses cryptography, and most cannot list them yet.</summary>
  </entry>
  <entry>
    <title>Blast radius belongs in the board pack</title>
    <link href="https://lgkm.org/notes/blast-radius-board-pack/"/>
    <id>https://lgkm.org/notes/blast-radius-board-pack/</id>
    <updated>2026-10-22T00:00:00Z</updated>
    <category term="network"/>
    <summary>Boards are told how many vulnerabilities were patched and how many people did the training. The question they actually need answered is how far one intruder could get. Blast radius can be measured, tested and reported in a line, and it belongs in the board pack.</summary>
  </entry>
  <entry>
    <title>Governing AI agents: keep the record, expire the access</title>
    <link href="https://lgkm.org/notes/governing-ai-agents/"/>
    <id>https://lgkm.org/notes/governing-ai-agents/</id>
    <updated>2026-10-21T00:00:00Z</updated>
    <category term="identity"/>
    <summary>Identity governance, access reviews and privileged access management can all cope with AI agents, once each agent is split into a lasting record with a human sponsor and access that is granted for a task and then expires. What that looks like in practice, and why the borrowed login defeats all of it.</summary>
  </entry>
  <entry>
    <title>Agents are the new insiders, with API keys</title>
    <link href="https://lgkm.org/notes/agents-are-the-new-insiders/"/>
    <id>https://lgkm.org/notes/agents-are-the-new-insiders/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="ai"/>
    <summary>An AI agent that can read mail, call APIs and change records is a privileged insider that can be talked into things. Treat it like one: an owner, the least access that works, and a record of what it did.</summary>
  </entry>
  <entry>
    <title>DLP after generative AI: the leak is now a prompt</title>
    <link href="https://lgkm.org/notes/dlp-after-generative-ai/"/>
    <id>https://lgkm.org/notes/dlp-after-generative-ai/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="data"/>
    <summary>Data used to leave by email, upload or USB stick. Now it leaves as text pasted into an AI assistant. Banning the tools does not work; giving people a safe one, and watching the prompt, does.</summary>
  </entry>
  <entry>
    <title>DORA in practice: what the third-party register reveals</title>
    <link href="https://lgkm.org/notes/dora-third-party-register/"/>
    <id>https://lgkm.org/notes/dora-third-party-register/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="resilience"/>
    <summary>DORA made every EU financial firm list its ICT suppliers in one standard register. The first lesson is not about suppliers at all. It is how hard it is to say which services depend on which contracts.</summary>
  </entry>
  <entry>
    <title>Identity is the perimeter, so what guards identity?</title>
    <link href="https://lgkm.org/notes/identity-is-the-perimeter/"/>
    <id>https://lgkm.org/notes/identity-is-the-perimeter/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="identity"/>
    <summary>Once identity decides access, stolen credentials and forgotten accounts become the way in. Guarding identity means phishing-resistant sign-in, owners for every account, and watching sessions, not only logins.</summary>
  </entry>
  <entry>
    <title>Is an AI agent just another non-human identity?</title>
    <link href="https://lgkm.org/notes/is-an-agent-just-another-non-human-identity/"/>
    <id>https://lgkm.org/notes/is-an-agent-just-another-non-human-identity/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="identity"/>
    <summary>An AI agent is a non-human identity only when it has credentials of its own. If it carries a person's delegated authority or borrows their login, it is something else, and the route decides whether PAM, access reviews and IGA can see it.</summary>
  </entry>
  <entry>
    <title>Labels before rules: why microsegmentation projects stall</title>
    <link href="https://lgkm.org/notes/labels-before-rules/"/>
    <id>https://lgkm.org/notes/labels-before-rules/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="network"/>
    <summary>Microsegmentation projects stall because nobody can say what each workload is. Label the estate first, by application, environment and role, and the rules almost write themselves.</summary>
  </entry>
  <entry>
    <title>Machine identities outnumber people; few organisations can list them</title>
    <link href="https://lgkm.org/notes/machine-identities-outnumber-people/"/>
    <id>https://lgkm.org/notes/machine-identities-outnumber-people/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="identity"/>
    <summary>Service accounts, API keys, tokens and certificates now far outnumber staff, and most have no owner and no end date. Start with an inventory that names an owner for each, then shorten how long their secrets live.</summary>
  </entry>
  <entry>
    <title>Shared responsibility still fails at the same seam</title>
    <link href="https://lgkm.org/notes/shared-responsibility-same-seam/"/>
    <id>https://lgkm.org/notes/shared-responsibility-same-seam/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="cloud"/>
    <summary>Cloud providers rarely get breached through their own platform. Their customers do, at the seam where the provider's controls end and the customer's settings begin: identity, configuration and data access.</summary>
  </entry>
  <entry>
    <title>Vulnerability counts are the wrong number</title>
    <link href="https://lgkm.org/notes/vulnerability-counts-wrong-number/"/>
    <id>https://lgkm.org/notes/vulnerability-counts-wrong-number/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="exposure"/>
    <summary>A falling count of open vulnerabilities feels like progress and says little about risk. What matters is which weaknesses an attacker can reach and use, on the things the business depends on, and how fast those get closed.</summary>
  </entry>
  <entry>
    <title>Security runs on pub-sub: the mesh, the logs and the monitoring</title>
    <link href="https://lgkm.org/notes/security-runs-on-pub-sub/"/>
    <id>https://lgkm.org/notes/security-runs-on-pub-sub/</id>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="architecture"/>
    <summary>Most of what makes a security architecture work is one pattern in disguise, publish and subscribe. Seeing it explains why logging, monitoring and the mesh succeed or fail together.</summary>
  </entry>
  <entry>
    <title>Where security architecture stands, and why most organisations run several at once</title>
    <link href="https://lgkm.org/notes/where-security-architecture-stands/"/>
    <id>https://lgkm.org/notes/where-security-architecture-stands/</id>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="architecture"/>
    <summary>Security architecture has moved through seven stages, from ad hoc to AI-native. Most organisations live in several at once, and that mix is the real starting point.</summary>
  </entry>
</feed>
