Claude code x Basic memory interaction

TL;DR: Learn how to create a persistent, AI-accessible knowledge base for security engineering. Store pentest templates, incident reports, infrastructure info, and SIEM queries that Claude can read and write to, so you never re-explain context to your AI assistant again.

The Problem: AI Agent forget what happened

Every AI conversation starts with a blank slate. Your infrastructure details? Gone. Past incidents? Forgotten. Team conventions? Starting from zero.

For security engineers, this is painful:

  • Repeating context constantly: Server names, IP mappings, admin contacts, AWS account structures

  • Templates in multiple places: Pentest reports in Notion, incident templates in Confluence, SIEM queries in random text files

  • Knowledge silos: Each team member maintains their own notes, nothing shared

  • The recurring question: "What was that SIEM query I used last month for detecting brute force?"

What if your AI assistant had persistent memory? What if it could:

  • Remember your infrastructure topology

  • Access your pentest templates

  • Retrieve relevant past incidents

  • Write new findings to your knowledge base

What is Basic Memory?

Basic Memory is a local-first knowledge management system that uses the Model Context Protocol (MCP) to create a bidirectional connection between AI assistants and your files.

The Difference: AI Reads AND Writes

Most RAG systems are read-only. Basic Memory goes both ways:

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Claude Code    │◄──►│  Basic Memory    │◄──►│  Markdown Files │
│  (AI Assistant) │    │  (MCP Server)    │    │  (~/basic-mem)  │
└─────────────────┘    └──────────────────┘    └─────────────────┘
        │                       │                       │
        ▼                       ▼                       ▼
  Query knowledge         Index & sync           Edit in Obsidian
  Write new notes         Knowledge graph        Git version control

How It Works

  1. Knowledge Graph Structure: Entities are stored with Observations (facts) and Relations (connections to other entities)

  2. Semantic Search: Vector-based search understands meaning, not just keywords

  3. Obsidian Compatible: All notes are standard Markdown files you can edit in any tool

  4. Local-First: Your data stays on your machine, in plain text files

Why Basic Memory for Security Engineers?

Security work creates specific knowledge problems. Basic Memory solves them:

Need

How Basic Memory Helps

Template-driven work

Store pentest reports, incident responses, access request templates

Infrastructure context

Map IP → Server → Owner → AWS Account with relations

Knowledge reuse

SIEM queries, payloads, exploitation techniques searchable

Team knowledge

Share via git sync or cloud storage

Local-first security

Sensitive data stays on your machine

The Security Knowledge Graph

Imagine querying: "Who owns the server at 10.0.1.50?"

Claude will do:

10.0.1.50 → production-web-01 → Platform Team → [email protected]

Or ask: "What incidents hit our payment systems?"

Claude follows relations:

payment-api → connects_to → payment-db
           → affected_by → incident-2024-0131
           → related_to → CVE-2024-XXXX

Setup Guide

Step 1: Install Basic Memory

# Install with uv (recommended)
uv tool install basic-memory

# Verify installation
basic-memory --version

Step 2: Create a Security Project

Create a dedicated knowledge base for your security work:

# Create security knowledge base
basic-memory project add security-kb ~/security-knowledge

# Set as default project
basic-memory project default security-kb

# Verify
basic-memory project list

Step 3: Configure Claude Code

Add basic-memory mcp

claude mcp add basic-memory --scope user -- uvx basic-memory mcp --project security-kb

MCP Tools Reference

Basic Memory exposes these tools to Claude Code:

Tool

Description

Security Use Case

write_note

Create or update notes

Save pentest findings, incident notes

read_note

Read by title or permalink

Retrieve templates, past reports

search_notes

Full-text + semantic search

Find relevant past incidents

build_context

Navigate via memory:// URLs

Load related context for AI

edit_note

Append, prepend, or replace

Update running logs, add findings

list_directory

Browse folder structure

Navigate template categories

canvas

Generate visualizations

Map attack paths, infrastructure diagrams

recent_activity

See recent changes

Track what's been updated

Security Use Cases

Use Case 1: Pentest Report Template

Goal: Standardize pentest report format across all engagements.

Prompt: Send below prompt to Claude Code

This prompt creates and stores a new reusable template in your knowledge base.

Use basic memory mcp
Create a note titled "Pentest Report Template" in the templates folder.
Include sections for: Executive Summary, Scope, Methodology, Findings
(with severity ratings), and Remediation.

Claude creates (~/security-knowledge/templates/pentest-report-template.md):

---
title: Pentest Report Template
permalink: pentest-report-template
tags:
  - template
  - pentest
---

# Pentest Report Template

## Observations
- [section] Executive Summary - High-level overview for management
- [section] Scope and Methodology - What was tested and how
- [section] Technical Findings - Detailed vulnerability analysis
- [section] Risk Assessment - Business impact and severity ratings
- [section] Remediation Recommendations - Prioritized fixes

## Relations
- relates_to [[Vulnerability Classification Guide]]
- requires [[Client Engagement Checklist]]
- references [[CVSS Calculator]]

Using it later:

Since the template was stored earlier, retrieve and apply it to a new engagement:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
Use the pentest report template to start a new engagement for Acme Corp

Claude reads the template and creates a new note pre-filled with the structure.

Use Case 2: Infrastructure Knowledge Base

Goal: Track server-to-owner mappings for fast incident response.

Prompt: Send below prompt to Claude Code

This prompt stores server details in your knowledge base for incident response.

Use basic memory mcp
Create a note about production-web-01 server. It's at 10.0.1.50,
runs Ubuntu 22.04, owned by the Platform team, admin contact is
[email protected], and it hosts the customer portal

Claude creates (~/security-knowledge/infrastructure/production-web-01.md):

---
title: Production Web Server 01
permalink: production-web-01
tags:
  - infrastructure
  - production
  - web-server
---

# Production Web Server 01

## Observations
- [ip] 10.0.1.50
- [os] Ubuntu 22.04 LTS
- [owner] Platform Team
- [contact] [email protected]
- [environment] Production
- [service] Customer Portal
- [criticality] High

## Relations
- connects_to [[Production Database Cluster]]
- managed_by [[Platform Team]]
- part_of [[Production Environment]]
- upstream_of [[Load Balancer Primary]]

Real incident scenario:

Since the server info was stored earlier, Claude retrieves it instantly:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
We're seeing suspicious traffic to 10.0.1.50. Who owns this server
and what does it run?

Claude pulls the answer immediately. No digging through wikis or Slack history.

Concrete Example: At 3 AM, a SOC analyst spotted anomalous traffic from 10.0.1.50. Instead of searching Confluence, Slack history, or waking up the Platform team, they asked Claude: "Who owns 10.0.1.50?" Claude returned: Platform Team, contact [email protected], hosts Customer Portal, criticality High. The analyst contacted the on-call Platform engineer within 5 minutes. Time saved: ~30 minutes of searching and escalations.

Use Case 3: SIEM Query Library

Goal: Build a searchable repository of detection queries.

Prompt: Send below prompt to Claude Code

This prompt stores the query in your knowledge base for future retrieval.

Use basic memory mcp
Save this Splunk query to my knowledge base:

index=security sourcetype=auth action=failure
| stats count by src_ip, user
| where count > 10
| sort - count

Tag it for brute-force detection and failed login monitoring.

Claude creates (~/security-knowledge/queries/brute-force-detection.md):

---
title: Brute Force Detection Query
permalink: brute-force-detection-query
tags:
  - splunk
  - siem-query
  - brute-force
  - authentication
---

# Brute Force Detection Query

## Observations
- [platform] Splunk
- [category] Authentication Monitoring
- [use_case] Detect brute force attacks by counting failed logins
- [threshold] >10 failures per source IP
- [query] index=security sourcetype=auth action=failure | stats count by src_ip, user | where count > 10 | sort - count

## Relations
- relates_to [[Account Lockout Monitoring]]
- tunes_to [[Authentication Baselines]]

Querying later:

Retrieve stored queries from your knowledge base:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
What SIEM queries do I have for brute-force detection?

Claude searches and returns all relevant queries with their use cases.

Concrete Example: A security engineer was tuning detection rules and remembered using a Splunk query for impossible travel detection 6 months ago. Instead of digging through saved searches, they asked: "What SIEM queries do I have for detecting impossible travel or geo-anomaly?" Claude returned the saved query, including the threshold values and tune notes: index=auth | geolocation src_ip | eventstats values(location) as locations by user | where mvcount(locations) > 1. The engineer copied it, adjusted thresholds, and deployed within 10 minutes.

Use Case 4: Incident Report Template

Goal: Standardize incident documentation for compliance and post-mortems.

Prompt: Send below prompt to Claude Code

This prompt creates a standardized template for consistent incident documentation.

Use basic memory mcp
Create an incident report template with these sections:
- Incident ID and Classification
- Detection Time and Method
- Affected Systems and Users
- Impact Assessment
- Root Cause Analysis
- Timeline of Events
- Actions Taken
- Lessons Learned
- References and Evidence

Use during an incident:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
Start a new incident report for a suspected phishing attack.
Detection time was 2026-01-25 09:30 UTC via user report

Claude creates a new note from the template, pre-fills known details, and links to relevant phishing playbooks.

Concrete Example: During incident INC-1234 (ransomware attempt detected on finance workstation), the IR lead used the template to document in real-time. Prompt: "Start incident report for INC-1234. Detection: EDR alert at 14:32 UTC. Affected system: FIN-WS-042." Claude created the note, linked to the workstation's infrastructure note ([[FIN-WS-042]]), and pulled in the Phishing Response Playbook. As the incident progressed, findings were appended: "Add to timeline: 14:35 - Isolated FIN-WS-042 from network. 14:40 - Retrieved email sample from user." The complete timeline was ready for the post-mortem without manual formatting.

Use Case 5: Bug Bounty Report Template

Goal: Consistent, professional bug bounty submissions.

Prompt: Send below prompt to Claude Code

This prompt stores a professional report template for consistent submissions.

Use basic memory mcp
Create a bug bounty report template with: Title, Vulnerability Type,
CVSS Score, Description, Steps to Reproduce, Impact Analysis,
Proof of Concept, and Remediation Suggestions

Using it:

Retrieve and apply the stored template:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
Use the bug bounty template to write up an XSS I found on target.com
The vulnerability is in the search parameter, reflected without encoding
CVSS score is 6.1 (Medium)
Payload: <img src=x onerror=alert(document.cookie)>

Concrete Example: A bug hunter found a stored XSS on a major e-commerce platform's product review section. Using the template, they prompted: "Use bug bounty template for stored XSS in product reviews. Payload: <img src=x onerror=alert(document.cookie)>. Impact: Session hijacking of any user viewing reviews. CVSS 7.5." Claude generated a professional report with: steps to reproduce (create review, submit payload, view on product page), impact analysis (steal cookies, perform actions as victim), and remediation (output encoding, CSP headers). The report was submitted to HackerOne and triaged within 24 hours. Bounty received: $1,500.

Use Case 6: Access Request Template

Goal: Standardize access requests for audit compliance.

Prompt: Send below prompt to Claude Code

This prompt creates an audit-compliant template for access requests.

Use basic memory mcp
Create an access request template for production systems.
Include: Requester, System, Access Level, Justification,
Duration, Approver, and Ticket Reference

Claude creates (~/security-knowledge/templates/access-request-template.md):

---
title: Access Request Template
permalink: access-request-template
tags:
  - template
  - access-control
  - compliance
---

# Access Request Template

## Observations
- [requester] [Name and team]
- [system] [System name]
- [access_level] [Read/Write/Admin]
- [justification] [Business reason]
- [duration] [Time period]
- [approver] [Approving manager]
- [ticket] [Ticket reference]

## Relations
- relates_to [[Access Control Policy]]
- requires [[Manager Approval]]

Concrete Example: A junior security engineer needed read-only access to production logs for an investigation. Using the template: "Create access request for PROD-LOG-SERVER, read-only, for security investigation INC-2024-0189, duration 48 hours, approved by Security Lead, ticket SEC-1234." Claude generated a compliant access request note with all required fields. The request was auto-linked to the incident note for audit trail. During the quarterly access review, auditors could trace every temporary access to its justification and ticket.

Use Case 7: Payload Library

Goal: Categorize and retrieve useful payloads for testing.

Prompt: Send below prompt to Claude Code

This prompt builds a categorized payload library for quick reference.

Use basic memory mcp
Create a note for XSS payloads. Include these examples:
- <script>alert('XSS')</script>
- <img src=x onerror=alert('XSS')>
- javascript:alert('XSS')
- {{constructor.constructor('alert(1)')()}}

Tag each with context: HTML context, attribute context, URL context, template injection

Retrieving later:

Search your stored payload library:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
Show me XSS payloads that work in HTML context for a reflected XSS test

Concrete Example: During a web application pentest, the tester found a search parameter reflecting user input inside a div tag: <div>Search results for: [INPUT]</div>. They asked Claude: "Show XSS payloads for HTML context inside a div tag." Claude returned 5 relevant payloads from the library, tagged as html-context. The tester tried <img src=x onerror=alert(1)> first—it fired. Total time from finding to PoC: under 2 minutes. The payload library, built over 6 months of engagements, saved searching payload repositories like PayloadsAllTheThings or PortSwigger's cheat sheet.

Knowledge Graph in Action

Basic Memory stores notes as connected entities - each note can link to others using [[wiki-style]] relations like - affects [[Server Name]] or - follows [[Playbook]]. When you use memory:// URLs, Claude will do these connections and returns not just the note you asked for, but all related context in one call.

Example

You create:                    You ask:
┌──────────────┐               "Load context from memory://incidents/phishing-attack"
│ Phishing     │               
│ Incident     │               Claude returns:
│              │               ┌──────────────┐
│ relates_to   │──────────────►│ Phishing     │
│ [[Playbook]] │               │ Playbook     │
└──────────────┘               │ (steps)      │
                               └──────────────┘
                               ┌──────────────┐
                          ┌───►│ Email        │
                          │    │ Controls     │
                          │    │ (SPF/DKIM)   │
┌──────────────┐          │    └──────────────┘
│ Email        │──────────┘
│ Controls     │
│ requires     │
└──────────────┘

One memory:// call -> All connected knowledge, since relations between notes are where this gets useful

Example: Incident Response Context

When an incident occurs, build_context loads everything connected:

Prompt: Send below prompt to Claude Code

Use basic memory mcp
Load context from memory://incidents/production-outage-2025-01

The value after memory:// is the permalink — a unique address for each note based on its folder path and filename (e.g., incidents/production-outage-2025-01), which lets you reference and retrieve any note regardless of where it's stored.

Claude will do:

production-outage-2025-01
  ├── affects [[production-api-01]]
  ├── affects [[production-db-primary]]
  ├── caused_by [[aws-us-east-1-outage]]
  ├── reported_by [[monitoring-alert-system]]
  ├── assigned_to [[Platform Team]]
  └── relates_to [[incident-2025-01]] (similar incident)

Visualizing with Canvas

Prompt: Send below prompt to Claude Code

Use basic memory mcp
Create a canvas visualization of our production infrastructure
showing connections between servers, databases, and teams

Claude generates an Obsidian canvas file you can open and explore visually.

Once you start storing notes, commands, or findings in your second brain, the collection gradually organizes itself.
In my setup, Basic Memory automatically groups related items together based on context.

Second brain knowledge grouping

Advanced: Multi-Project Setup

For consultants or those managing multiple environments:

Separate Projects by Client

# Create project per client
basic-memory project add client-acme ~/kb/acme
basic-memory project add client-globex ~/kb/globex
basic-memory project add internal ~/kb/internal

# Switch between projects
basic-memory project default client-acme

Data Isolation

Each project is completely independent:

  • Separate knowledge graphs

  • No cross-project search (by design)

  • Perfect for sensitive engagements

Security Considerations

Local-First Design

  • Data sovereignty: All files stored locally in ~/security-knowledge/

  • No cloud required: Works entirely offline

  • Plain text: Markdown files you can encrypt, backup, or version control

Sensitive Data Handling

Recommendations:

1. Encryption at rest: Use FileVault (macOS), BitLocker (Windows), or LUKS (Linux)

2. Git storage: Use private repositories only

3. Exclude secrets: Never store actual credentials. Use references to vault paths instead.

4. Access control: Rely on filesystem permissions

Integration with Obsidian

Basic Memory uses the same Markdown format as Obsidian, enabling direct integration:

Benefits

  • Visual editing: Use Obsidian's rich editor instead of raw Markdown

  • Graph view: Visualize your knowledge graph

  • Plugins: Use Obsidian plugins (Dataview, Templater, etc.)

  • Mobile access: Obsidian mobile apps for on-the-go reference

What’s Next ?

I’ll share a specific use case of Basic Memory for a second brain in the next post, stay tuned and subscribe so you don’t miss it.

MFA

Conclusion

Basic Memory gives Claude Code a memory:

  • Templates: Standardize your work without manual copy-paste

  • Infrastructure context: Instant lookup during incidents

  • Knowledge reuse: SIEM queries, payloads, techniques searchable

  • Compounds: Your knowledge base grows more valuable over time

Don't overthink it. Create one template. Add a few server notes. Let it grow from there.

Further Reading

MCP Servers for Security:

Security Skills & Agents:

Configuration Tools:

Ready to apply AI to your Security Engineering ?

Subscribe to Secengai Newsletter for weekly actionable content on AI for security engineers.

Keep Reading