In October 2023 I published Human Memory Management: Techniques For Actionable Security Research, a blog where I detailed exactly how I used Obsidian. It’s not my most-read post, but it’s the one I get the most questions about. Readers who spent time reading through it often wanted to replicate the system.

My obsidian workflow has changed dramatically over the years, and as such, an update is in order. Most notably, agents have become genuinely useful, which forced me to rethink how the vault is structured. and I’ve spent a lot of time brainstorming how my vault structure should evolve.

Vaults

The traditional obsidian ethos encourages a single vault structure so that [[wikilinks]] can be used to navigate a vault structure and make connections. I am wary of this approach and silo different domains of my life into different vaults. The brain vault I use for planning a vacation should never need to be linked to the security vault I use for offensive security research.

I currently maintain 5 vaults:

• grahamhelton.com: The vault for publishing content to this website
• security: The main obsidian vault I work in. This contains all the notes and knowledge I’ve collected about cybersecurity and my career.
• brain: This is my personal vault I use for journaling, grocery lists, and ideas
• jia van: This is the experimental vault I created for my jia van project.
• testing: This is the staging vault where I test new plugins, ideas, and workflows

This post will mostly describe the main security vault since it’s the most heavily customized one.

Plugins

Historically, I didn’t use many plugins, but AI tools like Claude Code have lowered the time it takes to build custom ones, so I now use several hyper-specific ones throughout my vaults. The grahamhelton.com vault has one that turns Obsidian into a half-CMS, half-CI pipeline for publishing blog posts.

I also use a custom Google Docs-inspired commenting plugin that I created for the sole purpose of allowing AI models to have an interface to act as editor of my writing, not a ghostwriter. The ethos is: build hyper-custom tooling as needed.

Additionally, I’ve borrowed some features from neovim such as a leader key (mapped to ,) and telescope style fuzzy finder where ,ff will search through note titles and ,sg will search through file content.

Attachments

Dealing with attachments is annoying in most software. Obsidian is only slightly less annoying because I’ve opted out of dealing with them entirely. The first setting I change when I first create a vault is the default location for new attachments to In the folder specified below and then set the attachment folder path to _obsidian/attachments.

When any new attachment gets added to the vault, it ends up in that folder. Obsidian really just works at pulling any images, videos, or pdfs from that folder. The only time I have to think about attachments is when sharing files, but I typically send a PDF anyway.

Folders

Folder structure is a controversial topic in the personal knowledge management world. I’ve tried all of the methods like PARA and Zettelkasten and none of them worked well for me. I’ll discuss how I use folders in more detail in a moment, but my vaults all contain a _obsidian folder that houses metadata about the vault such as attachments, templates, etc.

The Security Vault

Here is the canonical and mostly useless graph view picture to convince you I’m a real note taker with real insights into how to do real knowledge management.

My security vault has evolved since the original Human Memory Management post to the point of being unrecognizable. So here’s how the vault works today.

The security vault is organized into 8(ish) top-level directories.

• _obsidian: Metadata about the vault, see above for more details.
• 1_TECHNOLOGY: Any notes about a specific technology. IE: kubernetes
• 2_TECHNIQUE: Any notes on a technique that can be executed upon a technology. IE: BGP
• 3_RESEARCH: This is a catch all for any notes that are things I’m looking into or want to dig into more in the future. Often times I’ll encounter something when working and say “thats weird” and create a new research note with screenshots or output I can use to pick back up on in the future. I honestly don’t use this as often anymore and typically throw these breadcrumbs of research ideas into Linear
• 4_TOOL: Any notes describing what a tool is or how to use it goes here. IE: tcpdump or nmap.
• 5_CONCEPT: This is the largest directory. Anything that is a security concept lives in here. For example: Cryptography
• 6_PROMPTS: A new addition, this is my prompt library where I store useful prompts for AI systems.
• 99_OTHER: Anything that doesn’t fit neatly into another directory gets stuffed into this one.

This entire structure feeds into the note creation process of the vault which is the largest change I’ve made.

Frontmatter

Obsidian properties are the key to my setup. Every note follows a very similar YAML frontmatter schema, allowing me to add structured data to each note. Following a familiar structure for every note has powerful implications for automation, organization, and visualization, especially when using Obsidian Bases.

The frontmatter schema contains the following properties

---
title: knowledge management
date_created: 2026-04-15
description: "The systematic process of capturing, organizing, storing, sharing, and applying information"
type: concept
domain:
  - Career
reference:
  - "[[writing]]"
  - "[[obsidian]]"
---

The specific fields matter less than picking them and sticking to them. The value of frontmatter comes from using them consistently (make sure you template them out!)

Properties also unlock Obsidian Bases, a relatively new feature that turns your notes into databases.

Here are two examples of how I use bases:

1. A base from my brain vault that functions as my cookbook with each card being a recipe note.
2. A base from my security vault that filters for tools, their description, and notes they reference.

Note Creation

The note creation workflow is the most unorthodox part of my Obsidian vault and I only use it for the security vault. Each time a note is created in the vault, a dialogue box appears that forces me to go through a standardized flow that auto-populates the properties within a note. This flow is slightly different depending on which type of note is being created. For a concept note the flow looks like this:

1. Type a name for the note
2. Select what type of note this is
3. Select what domain this note falls under (redteam, blueteam, career, other, etc)
4. Select any other note I want referenced

For a technique note, the flow is the same, except instead of setting the domain property it sets a tag that corresponds to MITRE ATT&CK.

This does add some friction to creating a note but I’ve come to not mind it. I’ve used this system long enough that it’s become second nature, but it also has an unintended outcome. If I create a note that doesn’t fit cleanly into one of these categories, it probably doesn’t follow the atomic note taking structure I want my vault to be in. This structured note creation process enforces that I create atomic notes called something like “knowledge management” and “obsidian” and not “how to do knowledge management using obsidian”.

Atomic notetaking v2

I detailed why atomic notetaking works for me in the original post, but I will quickly recap what I mean when I say it. Atomic notetaking means each note captures one concept, even if that means creating multiple linked notes instead of one long entry. For example, recently I’ve been taking a lot of notes on concepts, tools, and techniques related to AI.

When I come across a new term that is related to AI security, instead of making a new note called how to do a prompt injection attack and how to defend against prompt injection I create a technique note called prompt injection. As I’m researching prompt injection, I might understand more about the structure, specifically there are variants of prompt injection such as indirect prompt injection and there might be defenses for prompt injection such as input validation. Each of these get created in obsidian using the same flow as before

The benefit here is seeing linked notes within the graph view. Just by looking at the graph view I can see indirect prompt injection -> prompt injection -> input validation. Technique -> concept -> defense.

That’s useful if I ever encounter indirect prompt injection and need to recommend a defense.

Finding Gaps in Knowledge

When I take notes on something in obsidian, I’m heavily using the [[wikilinks]] syntax to create a stub of a new note. Surrounding a word or concept with [[double brackets]] doesn’t create the note in the vault, but it does add it as a grey node in the graph view. If I begin to see a large amount of grey’d out nodes around a note, that means there is a lot of gaps in my knowledge in that area.

In this example, you can see several gaps in my knowledge of docker storage mechanisms.

Another useful way to find gaps in your knowledge is to identify what notes have many links connecting to it. If many notes mention something you’re not familiar with, you should probably spend some time learning it. A great example of this is my TLS note with dozens of notes mentioning it.

Using AI

There are a few areas where AI tools really shine in obsidian. First, you can spin up entirely custom extensions in minutes. AI tools like Claude Code genuinely excel at working in a structured environment like an obsidian vault. A well structured claude.md file explaining how to navigate the vault still seems borderline magical.

Aside from generic vault admin work like mass-updating frontmatter to conform to a different schema or generating descriptions/summaries of tools to store in frontmatter, I’m still experimenting with other areas agents can be helpful within my vaults. ## Agents

AI agents live and breathe markdown files which means there are many options for using them when working in obsidian. Despite that reality, my usage of agents within my vault is relatively focused. The goal of my knowledge base is actually not to store as much information as possible. It is not advantageous in any way to have thousands of unreviewed markdown file sitting on disk created by an agent.

I could easily get claude code to churn through tokens filling out my notes on TLS or github actions. I could also google it or, more likely, prompt an LLM with the exact information I need at the time I need it.

There are other reasons the vast majority of the data in my vaults are written by me and by hand.

1. Writing notes by hand helps me synthesize and make sense of the information
2. Writing notes by hand allows me to make connections (via [[wikilinks]]) to ideas or concepts that might not technically have anything to do with what I’m making notes on.
3. As mentioned before, it allows me to map out areas where there are gaps in my knowledge

Truthfully, the speed AI tools are evolving makes it difficult to pin down a single workflow for using agents in my vault. I expect to continue integrating AI tools into my obsidian vault and have a more cohesive workflow nailed down at some point soon. When I do, I will document it in part 3 of this series.

Moving Forward

Obsidian is becoming less of a note taking application and more of an IDE for my thoughts and writing. IDEs like VSCode have a very specific job that includes making the structural work of coding easier so you can spend your attention on the hard part. Linters, jump-to-definition, fuzzy finders, and custom extensions removes friction from everything that isn’t writing the code (once you learn how to use them of course). That’s very similar to what I’ve been building inside of Obsidian with the note creation flow, bases, graph views, and custom plugins.