We run a stack of tools. They tell us what we have... sometimes. They don’t tell us what we decided, what changed, or why.

Assets are in one place. Identities somewhere else. Vulns, tickets, comms, decisions, exceptions... all scattered.

So every request turns into a hunt for context about the thing involved. The asset. The identity. The repo. The vendor. Whatever the question is about.

A high-severity finding fires on a host. Where does it live? Who owns it? Is it in scope for compliance like SOC 2 or ISO 27k? Does it hold customer data? Is it actually exposed, or sitting on a private network behind two layers of controls? Has anyone looked at it before?

Five tabs and a few Slack threads later, you’ve got most of an answer.

Sometimes you don’t. Some of it isn’t written down anywhere. Some lives in someone’s head. Some never got captured.

The decision gets made anyway. Based on whatever we could find at the time. Not the full picture.

Next time a similar request comes in, we do it again.

GTM solved this

CRM isn’t impressive because of any specific vendor. It’s the model. Everything hangs off the customer.

One record. Every email, every call, every quote, every renewal, every lost deal. Every person who’s ever touched the account, with a timestamp and a note about what they did. Reasoning included.

A new rep can open an account, skim the timeline, and have the gist in a few minutes.

CRMs have been around for thirty-plus years. Every GTM function builds around the customer record. Sales. Marketing. Customer success. Support. And the CRM isn’t an island. It’s a hub. It integrates with hundreds of point tools. Marketing automation, sales engineering tooling, email, newsletters, custom integrations with the product itself. The CRM is the centralized platform. Everything else plugs in.

Security doesn’t have an equivalent.

Pick any entity in the environment. Try to reconstruct everything we know about it, every decision we’ve made, every conversation we’ve had, every exception we’ve granted. Good luck.

We’ve accepted this as normal

Two people on my team can talk to the same product or engineering person and get two slightly different answers. Neither answer gets captured anywhere reusable. Next time the question comes up, we ask again.

That’s not a tooling problem. The context lives in the conversation... then it’s gone. There’s nowhere to put it...so nobody puts it anywhere.

You could argue we have tickets. We do...but tickets are time-bound. They capture a moment, not the ongoing state of an entity. Searching across tickets related to an asset gets you fragments, not the full picture. Same scavenger hunt, different surface.

We don’t have the history. We don’t have the reasoning. We don’t have the “why we said yes” or the “why we said no last time.” Every conversation starts from zero. Every finding looks new. Every exception gets re-litigated.

A different model

I started thinking about the model GTM teams follow with the CRM at the center of it all, and wondered if we could apply similar logic to our stuff.

Not just assets. Identities. Systems. Services. Repos. Vendors. Anything that matters from a security standpoint, or anything in the business that touches security.

Each one is an entity. Everything ties back to it. Telemetry. Ownership. Compliance scope. Past decisions. Open and closed exceptions. The Slack thread where someone asked “should I worry about this?” two months ago. Basically anything that helps explain the who, what, when, where, why, and how.

This isn’t asset management. Asset management tells you what you have. This is the context and the relationships around it. What it’s connected to. What we’ve decided about it. What’s changed. Why.

It’s also not the source of truth for the underlying data. The systems that already own that data keep owning it. This is the source of context. The decisions. The reasoning. The conversations. The relationships we’ve inferred. Everything that lives between the records, not in them.

I think the pattern is similar to a CRM, at least from what I’ve seen of one. Central platform. Integrations into a lot of point tools. The difference is what each one is the source of truth for. A CRM owns the customer record. This owns the context layer.

“System of record” isn’t quite the right name for what this is. Source of context is closer. I haven’t landed on the right word for it.

So when something shows up and you ask “what is this thing... and should I care?” The answer is actually there. Without bouncing across five systems. Without guessing. Without making someone reconstruct context they shouldn’t have to reconstruct.

Most of our tools see one slice. EDR sees the host. IAM sees the identity. CSPM sees the cloud config. The scanner sees the CVE. None of them see the whole. And none of them see the human context. The decisions. The exceptions. The “we already looked at this and here’s why we didn’t act.”

That part doesn’t live in any tool today. It lives in someone’s head, or buried in a Slack thread nobody can find.

There’s a working model for this in another domain. AI coding agents and harnesses lean on simple markdown files for context. CLAUDE.md. AGENTS.md. Project READMEs. Plain text, tied to a directory or a repo. The agent reads the context before it does anything.

It works because context is what makes AI useful. Without it, the model is guessing. With it, the model can reason about the actual situation.

We can borrow the pattern. Per entity, captured in something humans and machines can read, tied to the thing it describes. Then humans and AI both have something to work from when a finding fires, a vendor question lands, or an exception gets requested.

This isn’t a new thought for me. I first kicked it around in 2016 or 2017. The barrier was always too high. Hiring developers for a months-long experiment wasn’t a tradeoff I could justify, and I never had the time to build it myself.

What changed is the cost of trying. AI lowers the barrier enough to actually run the experiment. Same lever I wrote about last time.

What I’m building

A rough version of this is already running.

We connect to the systems we already use through their APIs. Asset inventories. IAM directories. Vendor lists. GitHub. The scanners. The ticket systems. Anything that holds data about an entity or a relationship and exposes a way to read it.

Data gets pulled in. Relationships get inferred. Context gets layered on top. The conversation. The decision. The reasoning. Who owns it. What we’ve said before.

None of the source systems get replaced. We’re not building another asset inventory or another vendor list. We’re building the layer above them. The only hard requirement is that those systems have APIs we can read.

We’re still working out how to capture certain types of context, especially the human-in-the-loop kind. That’s a topic for a future post.

It’s messy. Not complete. We may scrap it. We may rebuild it from scratch. We don’t know yet what we’ll end up with. The idea is promising enough to keep building.

Even early... it’s already changing how we look at things.

Stuff that looked critical... isn’t. A “high” finding on a host that turned out to be deprecated, isolated, and unreachable from the internet is just noise. Stuff we would’ve ignored... probably matters more. A quiet permission change on an identity looks different when you can see what it’s actually connected to.

The relationships are doing a lot of the work. Take that same high finding on a host. From the host record, we can see who owns it. What business unit it belongs to. What team is responsible. Who works on it day to day. What other systems it depends on. None of that was sitting on the host record before. It comes from connecting data that already existed in different tools. With those relationships in place, “should I care, and who do I talk to?” has an actual answer.

The tools didn’t change. The findings didn’t change. We just have context now.

Why we create work

I wrote last time that security creates work. This is why.

When we don’t have context, we compensate with process. More tickets. More questionnaires. More “just in case” reviews. Every conversation starts from zero, so we treat every finding like it’s the first time we’ve ever seen it. We push the work onto engineering, compliance, IT... because we don’t have a way to internalize it ourselves.

A system of record is the foundation. AI on top of context is useful. AI on top of nothing is faster slop.

Every automation I’ve talked about gets better when there’s a single place to read from and write to. Intake. Triage. Scope decisions. Vendor reviews. All of it improves the moment context stops being a thing you reconstruct.

Some of the tools my team has built are going to change. The repo-tracking tool from the last post will get replaced entirely by this. Repo scope just becomes a relationship the system renders automatically. Other tools will either integrate to feed context in, act on context, or get replaced entirely.

There’s a longer list of unanticipated benefits we’re starting to see. More on those in future posts.

Not another tool

There’s no shortage of related categories. CMDBs. ASMs. Risk platforms. Exposure management. None of them claim to be a security system of record. Most of them aren’t built for it either.

CMDBs come closest in concept. An entity-centric record with relationships. But the name gives it away: Configuration Management Database. The unit is the Configuration Item. The relationships it tracks are operational. What runs on what. What depends on what. Optimized for change and incident workflows, not for capturing why decisions were made or what conversations produced them. The schema is opinionated and hard to extend. Adapting it for the kind of context security needs is a project of its own.

The rest each do something useful and narrow. ASMs discover external attack footprint. Risk platforms aggregate signals to support risk prioritization. Exposure management focuses on which weaknesses are actually reachable and exploitable. All useful. None of them sit at the center the way a system of record needs to.

The hard part isn’t storing the data. It’s modeling the relationships and capturing the human context. That part is specific to how your business runs. No two businesses do security the same way. Off-the-shelf doesn’t know that we treat ephemeral build infrastructure differently from production. It doesn’t know which engineer owns which repo. It doesn’t know which exceptions we’ve already approved, or what we said to the auditor last quarter.

This is one of those build-vs-buy calls where build wins. Commercial tools are generic by necessity. They have to work across thousands of customers. You end up using maybe ten percent of what they actually do, and you still pay to train people, stand it up, and keep it running. Building it for your own context gets you exactly what you need, configured the way you actually work. Nothing more, nothing less.

That’s not something I want a vendor to define for me.

This isn’t another tool. It’s a different model.

We need a system of record for context and relationships. Something that gives us the why behind what we’re protecting, not just the what.

Better, not perfect

That’s what I’m working on right now.

It doesn’t have to be perfect. It just has to be better than five tabs and a Slack thread.

A lot of it.

A team spins up a new GitHub repo. Nobody tells us.

We find out later. Maybe much later. That repo might be in scope for compliance.

If it is, and we didn’t know it existed, both teams end up scrambling. Security has to explain why it wasn’t caught. Engineering has to reconstruct context for a repo they might not have touched in months. Under audit pressure, with a tight deadline. None of that is work anyone should be doing.

The engineers aren’t hiding anything. They’re building. They have their own deadlines and their own objectives. The old process asked them to stop what they were doing, switch context, update a Confluence page, and notify security. It’s one more thing on a long list... and it’s easy for it to fall through the cracks.

That’s not their failure. That’s ours. We built a process that depended on them remembering, and then acted surprised when they didn’t.

By design

That’s part of it. Most of what we do is work we create on purpose. We built it, normalized it, and call it security.

We’re the ones telling teams they’ve got vulnerabilities, weaknesses, design flaws. Even when we hand them recommendations, they still have to contextualize it, review it, figure out how it lands in their code.

Then there’s the overhead. Tickets. Reviews. Approvals. Questionnaires. Even when we’re trying to help, we’re slowing things down.

When we become the blocker, teams go around us. They ship without telling us, or they tell us late. Risk goes up, not down.

AI is the first tool we’ve had that can take things off the list, not add to it. That’s how we stop being the bottleneck.

The job isn’t to secure everything

The job is to help the business move forward securely.

It’s easy to lose sight of why we’re here. We’re here to help the business move forward, not to stand in its way. Doing that securely is the how. It’s not the why.

That means reducing friction, not adding more. Guardrails instead of gates. Enablement instead of enforcement.

AI isn’t the fix for this. Broken processes plus AI equals faster broken processes. If the workflow is bad, automating it just makes the bad workflow cheaper to run.

What AI actually is, is a lever.

Work that was too expensive or too time-consuming to automate is now within reach. A lot of what we’ve called “good security” was really “what was possible with the tools at hand.” AI is changing that. The question isn’t whether AI can run your program. It’s where it can take manual work off the table so the team can focus on the parts that matter. Less friction means the business moves faster.

There’s another piece of this we don’t talk about enough. Security teams aren’t staffed to do all the work our programs say needs to get done. We’re small. We were small before AI and we’re still small after. Reducing friction for engineering is the visible win. Reducing friction for our own teams is the quieter one... and it’s what makes any of this sustainable.

What eliminating work actually looks like

A few things my team is running or actively building right now. None of these are agents running wild. Every one keeps a human in the loop on the actual decision.

Intake through Slack

We have a Slack channel where teams ask us for help. “Can I use this tool?” “What do you think of this open source library?” “I need access to X.”

We’re building a bot in that channel that creates a ticket automatically when a request comes in, and in some cases just acts on it directly when the ask is something every employee is already allowed to do.

One thing I think is cool: when someone drops a link to an open source repo and asks what we think, the bot pulls the repo, does a first-pass review, and flags the things that matter. Callbacks. Remote code execution. Anything worth a closer look. The engineer gets that context up front and can make an informed call without waiting on us. The busywork of cloning the repo and looking it over is gone.

Outcome: engineers get answers faster. We spend our time on the calls that actually need judgment.

Vulnerability triage

Our AppSec scanners surface a lot of findings. The existing process asks engineering to triage each one, figure out if it’s real, and if so, create a Jira ticket, track it through to completion, and make sure the scanner comes back clean.

What actually happens: findings pile up. Engineers forget to triage, or they triage and forget to create the ticket, or the ticket gets created but nothing moves. We spend a lot of time on the compliance side just reconciling state.

We’re building a dashboard that pulls findings into one place with clear actions (create ticket, mark false positive, defer) and uses AI to do a first pass. AI proposes the triage. The engineer reviews and clicks. A correctly-formed Jira ticket gets created automatically, with the right context, for the ones that matter.

Outcome: engineers stop burning cycles on dead ends like a vulnerable dependency that only shows up at build time and never reaches runtime. We stop chasing. The findings that are real move faster.

New repos, automatic

Back to where this post opened.

We wrote a tool that detects when a new GitHub repo is created, adds it to an inventory, and opens a Jira ticket so it’s tracked and reviewed. Engineers don’t have to remember to update anything. Security doesn’t have to find out by accident.

The next piece: AI does an initial read of the repo and proposes whether it’s in scope for compliance, with a short summary for the reviewer. The human still makes the final call. If it’s in scope, a custom GitHub repo property gets set automatically to mark it. We’ve just removed every step before the decision, and the step right after.

Outcome: we know about every repo. Engineers don’t lose time on notification hygiene. Compliance scope stops being something we reconstruct after the fact.

Start small. Stay deterministic.

This isn’t about building agents to do everything.

To be clear on where my security team is: we haven’t released any AI agents yet. Everything we’ve shipped is deterministic automation. Coding agents helped us build it. Nothing we’ve put into production is AI making decisions. AI agents are something we’ve only started developing in the last month or two.

Start with small, scoped automations. Clear inputs, clear outputs, clear failure modes. Layer in intelligence only where it actually adds value.

Over-engineering early is how these projects die. You build something ambitious, it breaks in a weird way, the team loses trust, and you’re back to manual. Ship something small that works. Iterate.

What this substack will focus on

Real workflows. What actually works versus what sounds good on a slide. Building things, not just talking about them.

Going forward, more on AI and security in practice. What’s working, what isn’t, the tradeoffs worth knowing about. Occasionally a tool summary, an article worth reading, or whatever home lab experiment ends up being relevant.

Some posts will be about security leadership. How I think about running a modern program. Topics I have opinions on. Ones I’ve changed my mind on.

That’s what I’ll be covering.