So when Claude found a blind SQL injection in Ghost (50,000 GitHub stars, zero critical vulnerabilities in its entire history) in 90 minutes, I wasn’t shocked. I’ve been watching these models get better in real time. And when Claude Mythos leaked a few days ago, described as “far ahead of any other AI model in cyber capabilities,” and cybersecurity stocks dropped 3 to 7%, yeah, I get the excitement. I share it.

But if you actually run this stuff in production, you know it’s not that simple.

When you actually run AI SAST across a real production codebase, day in, day out, you learn to live with a specific reality: the thing works, but it also lies to you. A lot.

You point your AI scanner at a codebase, and it comes back with a list. SQL injection here. SSRF there. Insecure deserialization in this library. Hardcoded credentials in that config. Broken access control on this endpoint. Some of those are real, and give you that w000t moment.

But a lot of them aren’t. I don’t mean edge cases or theoretical stuff. I mean, the scanner is flat-out wrong. It’s flagging things that can’t actually be exploited because it doesn’t have the full picture.

Your AI scanner reads a function, sees a user-supplied parameter going into a database query, and flags it. Possible SQL injection. Severity: High. Makes sense on paper. But what it doesn’t know, what it can’t know just from reading source code, is that three layers up, there’s an API gateway stripping special characters before the request ever reaches this function. Or there’s middleware parameterizing the query. Or that “user-supplied” input is actually coming from an internal service that already validated it.

The scanner sees the code. It doesn’t get the full picture.

Same thing with access control. The scanner sees an account ID passed as a parameter and forwarded downstream without an ownership check in that file. Flags it Critical. But it has no idea whether the API gateway injects a verified client identity header upstream, or whether the downstream service validates against it. The enforcement might live in a completely different service, maybe even on a different platform. The scanner can’t tell.

So what actually happens? Your AI hands you 200 findings, and your team spends the next two weeks triaging them. Half are real. Half are garbage. And the only way to figure out which is which is to manually check each one against the running system.

Nobody has time for that. So this is what I’ve been building instead.

What if you didn’t stop at the SAST results? What if you took those findings and actually tested them?

The philosophy is simple: code first, exploit second.

Instead of running a generic scan and dumping results on someone’s desk, you structure it. You map every endpoint to its full middleware chain, its auth requirements, its authorization checks. Most of this stuff is code, by the way. Your API gateway config, your middleware handlers, your route definitions, they’re all sitting in repos. But nobody points the scanner at all of it together. The gateway config is in one repo, the back-end in another, auth rules in YAML somewhere else, WAF in a Terraform file. Teams scan the application code and call it a day. The full picture never makes it into one scan.

So you build it yourself. I’ve been building what I call an authorization matrix for every endpoint in your API surface.

At its simplest, it’s a structured map that answers four questions for every route:

• Who is the caller? (auth mechanism: JWT, session, API key)

• Where does identity come from? (header, token claim, request param)

• What checks are enforced? (middleware, service-level validation)

• Where are those checks implemented? (gateway, app, downstream service)

Most of this data already exists, just scattered:

• API gateway configs (routing, auth injection)

• Middleware chains in application code

• Infrastructure definitions (WAF, proxies, service mesh)

• Downstream service validation logic

The matrix stitches all of that into a single view. It shows you every gap at once instead of hunting through endpoints one at a time.

Then you organize findings into categories that actually map to your system. Not generic OWASP buckets, but patterns you can grep for in your own code:

• Endpoints accepting identity parameters that don’t route through your ownership validation function. That’s a potential IDOR. You confirm it by searching the codebase for everywhere that the identity parameter flows and checking which middleware chains include the authorization check.

• Webhook handlers that might not validate signatures. Your API gets callbacks from third-party providers. Does the handler verify the HMAC? Constant-time comparison? Nonce or timestamp check? You can answer all of this from the source code before sending a single request.

• PATCH handlers that exist in the back-end but might not be exposed through the gateway. Routes say one thing, back-end says another. If there’s a catch-all proxy rule, the handler might still be reachable. Static analysis tells you. Dynamic testing confirms.

• Mass assignment where the request body flows straight to the database without field filtering. Does your PUT handler accept audit fields, status flags, role parameters that a regular user shouldn’t touch? Read the code, trace the flow.

Here’s the shift: you only move to dynamic testing when the code confirms a gap. Not before. You’re not blind-fuzzing 200 endpoints. You’re actually testing the 15 that the code tells you are worth testing.

And when you do test, you’re not throwing generic payloads. You authenticate as User A, request User B’s data, and observe the result. You craft exact parameters, supply the right tokens and the right headers. You’re not asking, “Is this endpoint vulnerable to anything?” You’re asking, “This specific code path is missing this specific check. Can I actually reach it from the outside?”

Instead of 200 findings where half are noise, you get maybe 15 confirmed, exploitable vulnerabilities. With reproduction steps. With evidence. With severity validated against the actual production environment. With the exact code location for the fix. That’s something your engineering team can actually work with.

Subscribe now

I recently ran this exact approach against an internal service. Static analysis mapped 46 endpoints across two repos, built the full authorization matrix, and identified 10 vulnerability categories worth investigating. Webhook handlers with no signature validation. Endpoints accepting identity params without ownership checks. Internal APIs potentially exposed through catch-all gateway rules. PATCH handlers bypassing immutability checks.

Dynamic testing then confirmed which were actually exploitable. Some were. Most weren’t, because a gateway or middleware I hadn’t accounted for was doing its job. But I knew before I tested. The static analysis gave me a prioritized hit list, not a pile of maybes.

The industry excitement about AI finding zero-days is warranted. The Ghost demo is impressive. Claude Code Security is impressive. Mythos will probably be more so. But the challenge was never just finding potential vulnerabilities. We’ve had tools generating long lists of potential issues for decades. The challenge is knowing which ones are real.

SAST alone, even AI-powered, can’t tell you that. It reads code. Code is an incomplete picture of reality. Your actual security posture depends on how the thing is deployed, how it’s configured, what sits in front of it, what happens at runtime.

This is the loop: static analysis builds the map, authorization matrix shows where the gaps are, dynamic testing tells you which gaps are actually exploitable. What you end up with is a short list of things that are actually broken, with proof.

I’m building this. I think everyone should be.

We built an AI agent. It worked brilliantly until it suddenly forgot everything it had just done. Fixed it with three changes: made memory loading architectural (not optional), merged all threads into one session, and added safeguard mode to preserve context during compaction. Now the agent actually remembers.

How it started

If you were on AI Twitter last week, you probably saw the chaos: Clawdbot became Moltbot, then became OpenClaw. Three names in one week.

The open-source AI agent project went viral 3 weeks back, then Anthropic sent a trademark request about the “Clawd” name being too close to “Claude.” Developer Peter Steinberger renamed it Moltbot (because lobsters molt, get it?). Then, in the chaos of the rename, crypto scammers hijacked his old username, fake tokens launched, and everything went sideways. Now it’s OpenClaw. Finally.

The project itself is actually useful: an autonomous AI agent that runs locally and executes tasks across messaging platforms. Not just a chatbot, but an agent that actually does things.

We caught the bug early. Downloaded Clawdbot (back when it was still called that), saw what it could do, and thought: “What if we built an agent that does internal audits?”

Not a chatbot that answers audit questions. A full autonomous agent that extracts regulatory requirements, designs test procedures, collaborates across Slack threads, and maintains context over days-long conversations. An AI colleague, not just a tool.

We had the agent running and set it loose. It worked beautifully. Until someone asked a question in a different Slack thread within the same channel.

The agent responded: “I don’t have access to Slack.”

What the actual ****.

You just had a fifty-message conversation. The agent posted detailed findings, created comprehensive reports. And now it claims it’s never seen Slack before?

Welcome to the world of AI agent amnesia. This is the story of how we fixed it and what we learned about building agents that actually remember.

The three problems

1. Memory loading was just advice

Our AGENTS.md file said:

“Before doing anything else: Read SOUL.md, USER.md, and memory/YYYY-MM-DD.md”

These were just instructions - text in a prompt. The agent could ignore them. And it did. Sometimes it would read the memory files. Sometimes it wouldn’t.

Memory loading was advice, not architecture.

2. Threads broke everything

Clawdbot’s default: Each Slack thread = separate session.

Thread 1: agent:main:slack:channel:xxxxxxxxxx:thread:1234
Thread 2: agent:main:slack:channel:xxxxxxxxxx:thread:5678

Makes sense for general chat. Pizza recommendations shouldn’t share context with database migrations.

But for audit work? Threads are just organizational tools. When someone says “Re-extract Chapter 1” in Thread 2, they’re continuing the audit from Thread 1.

Different thread = complete amnesia.

3. Compaction threw away the good stuff

When the context window fills up (~180K tokens), Clawdbot compacts older messages. Necessary - you can’t keep infinite history.

But without saving critical information before compaction, important details just vanished.

The three solutions

Solution 1: Custom memory hooks

The insight: Make memory loading architectural, not optional.

Built a hook that triggers on every message, loads memory files, and injects them before the LLM sees anything.

export default async function memoryContextHook(event) {
    if (event.type !== 'message' || event.action !== 'before') return;
    
    const memoryContext = await loadMemoryContextCached(workspaceDir);
    if (memoryContext) {
        ctx.Body = `${memoryContext}${ctx.Body || ''}`;
    }
}

Before: Message → LLM decides → (maybe reads memory) → Respond

After: Message → LOAD MEMORY → Inject into context → Respond

Memory loading is now deterministic. The agent can’t forget because the memory is already there.

Trade-off: Adds ~2-5K tokens per message. Worth it. An agent that remembers is infinitely more useful than one that saves tokens.

Solution 2: Channel-wide sessions

The insight: Threads aren’t conversation boundaries — they’re organizational tools.

One line change in session-key.js:

// BEFORE:
const useSuffix = params.useSuffix ?? true;

// AFTER:
const useSuffix = params.useSuffix ?? false;

Result: All threads in a channel share one session. Full context continuity.

Solution 3: Safeguard mode + memory flush

The insight: Save critical info before compaction throws it away.

We configured Clawdbot’s compaction to use “safeguard mode”:

{
  "compaction": {
    "mode": "safeguard",
    "memoryFlush": {
      "enabled": true
    }
  }
}

Safeguard mode keeps the last 10-15 messages in full detail (active memory) while compressing older messages into a summary. When compaction triggers:

1. Memory flush runs first - Agent extracts critical information: requirements, evidence mappings, test procedures, decisions, findings, ongoing work

2. Saves to memory files - Writes to daily memory files (memory/YYYY-MM-DD.md)

3. Active memory preserved - Recent 10-15 messages stay in full detail

4. Older messages compressed - Summarized into compact form

5. Context available - Memory files auto-loaded via hooks on next message

Think of it like taking notes before clearing your whiteboard. Recent messages stay in full detail, older messages get summarized, but you’ve written down everything that matters.

Rolling memory pattern

This creates a rolling memory system:

• Active memory - Last 10-15 messages in full detail

• Compact summary - Older messages compressed

• Memory files - Critical information extracted and saved

• Auto-loaded context - Yesterday’s and today’s memory files injected into every message

The agent maintains both short-term context (recent messages) and long-term memory (extracted to files), without losing critical information when the context window fills up.

In practice: A three-day audit with hundreds of messages stays coherent. The agent remembers requirements extracted on Day 1, references evidence mapped on Day 2, and builds on test procedures designed earlier - even though the original messages are long compressed.

The complete architecture

Message arrives
    ↓
Derive session: agent:main:slack:channel:xxxxxxxxxx
(All threads share this session)
    ↓
[HOOK] Load memory files:
  - AGENTS.md
  - MEMORY.md  
  - memory/today.md
  - memory/yesterday.md
    ↓
Inject memory into message body
    ↓
LLM processes with full context
    ↓
[On compaction] 
  Memory flush → Save critical info
  Keep last 10-15 messages in full detail (active memory)
  Compress older messages into summary

Four layers of context:

1. Active memory - Last 10-15 messages in full detail (safeguard mode)

2. Compact summary - Older messages compressed (safeguard mode)

3. Memory files - Persistent context loaded via hooks

4. Memory flush - Critical info saved during compaction

This architecture ensures the agent has:

• Immediate context from recent messages (active memory)

• Historical context from older messages (compact summary)

• Persistent context from workspace files (memory hooks)

• Preserved context across compactions (memory flush)

Before and after

Before

Thread 1:
You: "What audit are you working on?"
Agent: "ISO 27001:2022 audit. 317 requirements extracted..."

Thread 2:
Teammate: "Re-extract Chapter 1"
Agent: "I don't have access to Slack or context about this audit."

After

Thread 1:
You: "What audit are you working on?"
Agent: "ISO 27001:2022 audit. 317 requirements extracted..."

Thread 2:
Teammate: "Re-extract Chapter 1"
Agent: "I'll re-extract Chapter 1 from ISO 27001:2022..."

The agent just... works. Conversations across threads, hours-long breaks - it maintains continuity.

What we learned

1. Architecture > Instructions

You can’t rely on prompts. We spent days tweaking instructions: “Remember to read memory.” “Always load context first.”

None of it worked reliably.

The memory hook fixed it immediately. If something is critical, make it architectural.

2. Default behaviors matter

Clawdbot’s thread isolation default makes sense for general chat. But for focused project work, it was completely wrong.

One line change solved our biggest problem. Question your defaults.

3. Context management is a system

None of these solutions worked alone:

• Memory hooks without channel-wide sessions → lost context across threads

• Channel-wide sessions without memory flush → lost context after compaction

• Memory flush without hooks → agent forgot to load the flushed memory

You need all three layers working together.

4. Token costs are worth it

Memory hooks add 2-5K tokens per message. For a high-volume chatbot, that’s expensive.

But for multi-day audit work? The cost is irrelevant compared to having an agent that remembers.

Optimize for usefulness first, efficiency second.

5. Test in real workflows

Everything looked great in testing. Then we started actual audit work and everything broke.

The edge cases only appear under real conditions: multi-thread conversations, day-long sessions, multiple collaborators.

Implementation

Full implementation available on GitHub: clawdbot-memory-continuity

Quick version:

1. Custom hook: ~/.clawdbot/hooks/memory-context/index.js (~130 lines)

2. Core modification: /opt/homebrew/lib/node_modules/clawdbot/dist/routing/session-key.js (line 70, one boolean flip)

3. Configuration: ~/.clawdbot/clawdbot.json (enable safeguard mode + memory flush)

Maintenance: Hook survives updates. Core modification needs re-applying after npm update (30 seconds with included script).

See the GitHub repository for:

• Complete installation guide

• Auto-apply script for core patch

• Configuration examples

• Troubleshooting guide

• Maintenance instructions

When to use this

Works great for:

• Focused project channels

• Long-running workflows (audits, investigations)

• Collaborative work requiring context

• Professional agents (auditors, analysts)

Might not work for:

• High-traffic general channels

• Independent support threads

• Cost-sensitive high-volume applications

• One-off conversations

The key question: Do threads represent separate conversations or organizational structure within one conversation?

Separate → use thread isolation (Clawdbot default)

Organizational → use channel-wide sessions (our modification)

Maintenance after updates

When you run npm install -g clawdbot@latest:

What survives:

• ✅ Custom hooks

• ✅ Configuration

What gets overwritten:

• ❌ session-key.js modification

To re-apply:

# 1. Backup new version
cp /opt/homebrew/lib/node_modules/clawdbot/dist/routing/session-key.js \
   /opt/homebrew/lib/node_modules/clawdbot/dist/routing/session-key.js.backup

# 2. Edit line 70: change useSuffix ?? true to useSuffix ?? false

# 3. Restart gateway
clawdbot gateway stop
clawdbot gateway install

Or use the auto-apply script from the GitHub repo:

cd clawdbot-memory-continuity
./scripts/apply-patch.sh

Verification

Check memory loading:

clawdbot logs --follow | grep memory-context

Should see:

[memory-context] Injected memory context into message body

Check session keys:

clawdbot logs --follow | grep -E "session.*slack.*channel"

Should see the same session key for all messages in a channel, with no :thread: suffix.

Sometimes the best solutions are the simplest: Make memory architectural, not optional. Make threads organizational, not isolating. Make preservation automatic, not manual.

That’s how you build an agent that actually remembers.

As an organisation that moves fast on AI and low-code/no-code development, we produce a large amount of code/solutions very quickly. That speed is a strength, but it also means we have to pay close attention to the places where mistakes can hide. The Deriv security team has spent the last year examining how AI-assisted engineering works in practice, identifying potential pitfalls, and developing safer practices around it.

AI-assisted coding is in an awkward phase. It feels helpful and clever, and it saves time, so it quietly becomes part of everything we build. But the more we rely on it, the more we see a simple truth. AI will default to generating code that works, not code that is secure, unless you explicitly guide it. It has never lived through an outage. It has never been paged at 2 am with news that one of your externally exposed apps has been breached.

It just predicts what looks right. That is the gap.

Most AI-introduced vulnerabilities are small. They look reasonable. They slip past reviews. They compile cleanly. They appear harmless until the right scenario triggers them or the wrong person finds them first. This is why guardrails are not optional. They are the minimum layer of safety.

So the Deriv Security team is launching a new 5-part series on securing AI-assisted engineering. Not because the industry needs more talk, but because it needs a clear, practical framework for a world where code is no longer written only by humans and old habits no longer fully apply.

Here is what the series will cover:

The 5-part series

Part 1: Guardrails for AI-assisted and low-code/no-code development (published)

The essential boundaries that keep AI-generated code and LCNC workflows safe. What they must always enforce, what they must never allow, and why the safest place to stop failures is at the point of generation before the code or workflow enters an opaque runtime you can no longer fully control.

Part 2: Enforcing secure defaults inside AI development tools

The practical mechanics. How to embed rules directly into IDEs so insecure code never reaches a repository in the first place.

Part 3: AI-powered code review and automated scanning

How AI can catch mistakes that slip past humans. A look at real patterns, real issues, and blind spots that appear when humans assume AI output is safe.

Part 4: Real examples of AI-introduced vulnerabilities & pentesting AI/LCNC solutions

Small snippets that seem harmless but have real-world consequences. For example:

// looks fine at a glance
const user = req.query.user;
const result = await db.query(
  `SELECT * FROM clients WHERE name = ‘${user}’`
);

Compared to a guarded version:

const schema = z.object({ user: z.string().min(1).max(50) });
const parsed = schema.safeParse(req.query);
if (!parsed.success) return res.status(400).send(”Invalid input”);

const result = await db.query(
  “SELECT * FROM clients WHERE name = $1”,
  [parsed.data.user]
);

One trusts the world too much. The other knows the world can be complicated and full of people who type things they should not.

Part 5: A blueprint for responsible AI-driven engineering

How all the pieces fit together. A practical model that combines guardrails, IDE enforcement, PR scanning, LCNC governance, secret lifecycle automation, runtime isolation, observability, and AI change tracking into one secure engineering workflow. This part outlines the architecture, approval flows, monitoring pipelines, and habits needed to operate AI-assisted development safely at scale.

Why this matters

We now generate code faster than we can understand it. Humans write some of it. AI writes the rest. But only one of them understands consequences.

Most AI-generated code works, and that is the danger. When something works, you trust it. When you trust it, you stop checking. That is how small problems grow quietly into serious ones.

AI is helping us build faster. The real challenge is maintaining safety at the same pace.