<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Deedglass blog</title>
    <link>https://deedglass.com/blog</link>
    <atom:link href="https://deedglass.com/blog/rss.xml" rel="self" type="application/rss+xml" />
    <description>Real runs, tested guides and incident lessons about AI agents that act on real systems.</description>
    <language>en</language>
    <lastBuildDate>Wed, 14 Oct 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>Your AI agent said it updated 1 row. Postgres changed 301.</title>
      <link>https://deedglass.com/blog/agent-said-1-row-postgres-changed-301</link>
      <guid isPermaLink="true">https://deedglass.com/blog/agent-said-1-row-postgres-changed-301</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>A real run: an agent's one-row UPDATE fires a legacy trigger, Postgres commits 301 rows, and the tool reports 1. How to see it, and how to put it back.</description>
    </item>
    <item>
      <title>A practical checklist before you let an AI agent near production</title>
      <link>https://deedglass.com/blog/checklist-before-an-agent-touches-production</link>
      <guid isPermaLink="true">https://deedglass.com/blog/checklist-before-an-agent-touches-production</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>Twenty checks to run before an AI agent gets near a production database, payments or customer data: access, limits, destructive verbs, recovery and evidence.</description>
    </item>
    <item>
      <title>Claimed, Checked, Proven: three levels of evidence for agent actions</title>
      <link>https://deedglass.com/blog/claimed-checked-proven</link>
      <guid isPermaLink="true">https://deedglass.com/blog/claimed-checked-proven</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>Three levels of evidence for what an AI agent did: the tool's word, a read-back from the target, and the database's change log. What each one catches.</description>
    </item>
    <item>
      <title>MCP server security basics: what to check before an agent gets a tool</title>
      <link>https://deedglass.com/blog/mcp-server-security-basics</link>
      <guid isPermaLink="true">https://deedglass.com/blog/mcp-server-security-basics</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>Security basics for MCP servers that touch real data: credentials, read-only modes, local HTTP servers, prompt injection and the lethal trifecta.</description>
    </item>
    <item>
      <title>What the Replit and PocketOS incidents teach, from their primary sources</title>
      <link>https://deedglass.com/blog/replit-and-pocketos-what-the-primary-sources-say</link>
      <guid isPermaLink="true">https://deedglass.com/blog/replit-and-pocketos-what-the-primary-sources-say</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>Two widely shared AI agent incidents, read from the platforms' own accounts rather than the headlines: what happened, how, and the fixes that need no vendor.</description>
    </item>
    <item>
      <title>How to give an AI agent safe Postgres access: the role, RLS and statement limits</title>
      <link>https://deedglass.com/blog/safe-postgres-access-for-ai-agents</link>
      <guid isPermaLink="true">https://deedglass.com/blog/safe-postgres-access-for-ai-agents</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>A tested setup for an AI agent's Postgres access: a narrow role, row-level security per customer, statement and lock limits, and the one gap they all share.</description>
    </item>
    <item>
      <title>Undo for agent sessions: putting back what an AI agent changed in Postgres</title>
      <link>https://deedglass.com/blog/undo-for-agent-sessions</link>
      <guid isPermaLink="true">https://deedglass.com/blog/undo-for-agent-sessions</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>An agent ran for an hour and something is wrong. How to put back exactly what it changed in Postgres, without restoring a backup over everyone else's writes.</description>
    </item>
    <item>
      <title>Why logs aren't evidence of what your AI agent did</title>
      <link>https://deedglass.com/blog/why-logs-arent-evidence</link>
      <guid isPermaLink="true">https://deedglass.com/blog/why-logs-arent-evidence</guid>
      <pubDate>Wed, 14 Oct 2026 00:00:00 GMT</pubDate>
      <description>After an agent incident, the first question is what it did. A log can't answer that on its own. What signed, linked records add, with a real tamper run.</description>
    </item>
  </channel>
</rss>
