A post I wrote by hand, every word mine, got flagged as fully AI-generated.
That was the day I stopped trusting a prompt to hold my voice.

Here is what most anti-AI tools miss. They check one thing: the words. A
banned-word list catches the obvious filler, flags “delve” and “leverage,” and calls the job done. But a draft can dodge every flagged word and still read like a machine wrote it. It has the shape of writing with nothing real inside.

A vocabulary list checks which words you used. It cannot check whether you actually said anything.

I spent twelve years in threat intelligence, where the giveaway is rarely the word someone picks. It is the structure underneath. So I built a gate that checks both layers.

• The machine layer. Banned words, em dashes, unverifiable stats, and the cadence tells: three sentences opening the same way, uniform sentence length
• The substance layer. No first-person witness, no specific named thing, no concrete number, and it fires. This is the part almost nothing else does. It is the gap that lets generated prose slip past every word list.
• Two hooks, two moments. One on every save of a content file. One on the assistant’s final message at turn end, so a draft you paste straight into a post gets caught too.
• Deterministic. No model in the loop, so it never hallucinates a verdict and never costs a token.
• Yours to tune. Plain-text word and phrase lists you edit. No code change to customize.

Thirty-eight tests, all green. The free repo is the seed. The paid Writing Voice Gate adds the substance detector, the format checks for headlines and email, and the one-command installer.

A prompt asks the model to sound human. This makes the draft prove it has a witness, a name, and a number, or it does not ship.

$29, at claudedaddy.io. I build this discipline into writing pipelines for
teams who publish at volume, that part is the consulting.

You have probably watched it too. You give Claude Code a real task and step away. You come back and it has spent an hour going in a circle.

It retried a call that already failed, four times. It spawned three subagents
that came back with nothing. It read the same file five times and counted each pass as progress. By tool call forty the tokens are gone and the work has moved sideways, not forward.

That is not the model thinking too little. It is the model with no brakes. A car does not get safer by asking the driver to concentrate harder. It gets
safer with a seatbelt that works whether the driver remembers it or not.

I spent twelve years in threat intelligence, where a process left to run
unchecked is how you lose the whole night. So I built the seatbelt for Claude Code: token-guard.py, a hook that runs before every tool call, counts what the model is actually doing, and stops it the moment it starts to spin.

storms, MCP floods, read and edit spirals, same-file re-reads, grep drift,
subagents that return nothing, time stalls.

• Guards your secrets. Blocks any write to .env, .pem, or .key before it happens, not after.
• No model in the loop. The check is deterministic, so it is fast and it
  cannot be talked out of its verdict.
• Three profiles. Safe, aggressive, paranoid. The installer wires the one you pick.
• Ships green. Thirty-five tests, run the way Claude Code actually calls the
  hooks. Run them yourself.

The free repo, claude-focus, gives you the three core hooks. The paid kit adds the deadlock-proof stop gate, the instruction-budget preflight, the pipeline reliability modules, and a two-minute installer with per-OS guides.

The model will not stop itself. It does not know it is spinning. Give it the
brake it cannot argue with.

$39, at claudedaddy.io. I wire this into repos for teams running agents at volume, that part is the consulting.

Most founders research a market by asking their network. Friends, advisors, a few warm intros. Everyone nods. The idea sounds good.

That is a mirror, not research. You asked people like you, and they handed
your own assumptions back with a smile.

Your real buyers are already talking, in public, to each other. On Reddit, in
the threads where they trash the tools they pay for. They use specific words. They do not know you are reading, so they tell the truth.

Twelve years in threat intelligence taught me to build a read on a target from what they say in the open, before contact. Knowing your customer is the same work. So I built a tool that does it.

It runs in Claude Code, reads the actual Reddit threads, and hands you:

• Where your buyers live. The subreddits they gather in, ranked.
• Voice of customer. Real quotes, linked, in their exact words.
• A competitor read. What people say about the alternatives, and the gap
  across all of them.
• The objection. Why they will not switch, even when they hate what they have.
• The wedge. The gap nobody fills, and the exact language to use against it.

It links every quote. If the threads come back empty, it tells you. It never
invents a “people say,” because a made-up insight sends you building for a
customer who was never there.

Free. You need a paid Claude plan and one Terminal command for the Reddit connection (the README walks you through it), then /plugin install github:assafkip/customer-recon

Your market already said what it wants, out loud. Go read it.

Free, with the rest: claudedaddy.io

You can prep a pitch for a week and still miss the one thing that decides the meeting. Not your deck. What the fund already concluded about you before you walked in.

They looked at your deck, your site, your LinkedIn. They closed a few questions. Then you sit down and answer the ones they already settled, blind to the single objection that actually kills the deal.

I spent twelve years in threat intelligence. The whole job was building a picture of the other side from what they say in the open, before they know you are looking. A VC meeting is the same problem. So I built a tool for it.

It runs in Claude Code, reads the fund’s real material, and before the meeting hands you:

• The fund’s real thesis, quoted from their own material, with links. Not what their homepage wishes they backed. What their last deals say they actually back.
• A portfolio map. Where you fit, which company they already own that you
• The question set this partner will ask, drawn from their cited thesis and
  your stage.
• The one hesitation. The single thing about your company that makes this specific fund pause.
• The counter. How you answer it before they raise it.
• Sources and gaps. Every link it used, and an honest list of what it could not confirm.

It cites every claim. When it cannot find something, it says “Not found.” It
never guesses a fund’s deals or check size from the name, because a confident wrong brief walks you into the wrong room.

Free. No email. Open Claude Code, paste one block, answer two questions. Or install it: /plugin install github:assafkip/investor-recon

The side that did the homework runs the room. Usually that is the fund. Make it you. Get it free, with the rest of the kit: claudedaddy.io

Every enterprise I’ve worked inside had the same scene when new threat intel drops.

Eight to twelve people read the same report. The intel analyst summarizes it.Then someone in detection rewrites the summary as a rule. Someone in identity rewrites it as a policy. Someone in endpoint rewrites it as an IOC bundle. Each translation is lossy. None of them coordinate during the work.

Forty hours of skilled labor before a single control deploys. That’s the operating model.

The mismatch

The CISO sits on top of this. The board grades them on regulatory disclosure,

personal liability under the new SEC rules, revenue protection, executive judgment.

But the job runs like a senior IC role. Tickets and alerts pile up faster than anyone can triage them. Audit findings sit open. Forty different vendors with forty different consoles, each promising to fix the same thing.

That’s the mismatch.

I’ve been in rooms where the question was “is this done or not.” Nobody asked for a 40-page report. Nobody asked for the next slide.

Greg Hancock calls this a decision-quality problem in “Thrive Leadership in Action.” He’s right. Visibility doesn’t fix it. Dashboards don’t fix it. What needs to exist is infrastructure that lets the business own the residual risk in writing.

Three states the board cares about

- READY. Verified, ready for adversarial review by the eng team.

- ACTION NEEDED. Non-blocking gaps that human reviewers must backfill before sign-off.

- BLOCKED. A safety gate fired, work can’t proceed until it clears.

Consistency is the catch. CLI exit code has to agree with the HTML report. JSON metadata has to agree with both. So does the board slide. Five surfaces with one verdict across the whole stack. If they disagree, the system is lying somewhere.

A former CISO I met with put it cleanest: “Otherwise it’s just a shopping list without anything crossed off on it.”

The autonomy trap

Every agent vendor in cyber is selling autonomy. More automation. Less human in the loop.

Run the failure mode forward.

An autonomous agent ships a flawed rule. The rule breaks authentication for a quarter of users. Engineering takes the page at 2am. Finance takes the revenue hit Friday morning. The board asks the CISO who approved it.

Not the vendor. The CISO.

Autonomy isn’t the win. Coordination plus receipts is the win.

One threat advisory should land as eleven artifacts at once. A Sigma rule for detection runs alongside an Okta policy diff for identity, generated from the same source paragraph. Same input. Different output per team. Generated together. No team surprised.

The trust boundary is the part that matters. What the system signs for is one set of things. What the customer chooses to deploy is the customer’s call. Engineering stays the final validator. Auto-deploy isn’t the goal. Audit-grade is.

Better prompts don’t solve hallucinations

The industry tried. Production proved it.

One fabricated dollar figure in a security artifact. One made-up vendor citation. The department’s credibility is gone for a year.

The fix is engineering, not prompts. Five layers, blocking by default:

1. Source-Span Containment. Every claim must be a verbatim substring of the source.

2. Semantic Alignment. The artifact body matches the cited TTP tag.

3. Category Cross-Check. An independent LLM verifies the specialist’s classification.

4. Hallucination Scanner. Deterministic regex catches fabricated vendors, dates, dollaramounts.

5. Prose Grounding. Sentence-level check that the source supports every assertion.

Each one fires on every run. Hallucinations stop being a probability and become a build failure.

Receipts are the ammo

The audit chain uses alhc-1 (forward-hash) and mhdc-2 (manifest seals) on every run. Sounds like plumbing. Changes what you bring to the board.

Instead of vague reassurance, you bring an action ledger. A longitudinal record. It shows what the business chose to act on. It shows what they chose to defer instead, by whom, and when. Every row carries a timestamp and a signature.

Former CISO again, on what this gets you:

“They want ammo to say ‘I told you so.’ Give me the damn money. I covered my ass. I did everything I was supposed to do. And the drop is on you guys.”

That’s what the ledger does. It converts risk acceptance from a meeting minute into a record.

The clock

The leaders standing at the end of 2026 are the ones whose stack produces receipts. Not the ones with the most autonomous tools. The next breach disclosure form will ask: when did you know, what did you do about it, who signed off on the decision.

Does your current stack answer that?

If not, you have a coordination problem dressed up as a tooling problem.

Most developers Claude gurus use Claude Code one project at a time.

I run 18.

Not 18 sessions. 18 instances of the same OS, each running a different business, all sharing one skeleton I update once and propagate everywhere.

Most developers treat Claude Code as a smarter editor.

That’s where it all goes wrong and you get frustrated.

Claude Code becomes a real operating system the moment you stop thinking of sessions as the unit of work and start thinking of the whole environment as a substrate you build on top of.

Here are 9 building blocks I use. The thesis is at the bottom.

1. Build a skeleton with selective propagation, not a project.

Most developers build one project per Claude Code workspace. I built a template instead.

It has plugins, rules, agents, hooks, schemas, commands. When I start a new business I clone it and the new instance inherits the entire OS.

Right now I run instances for: strategy, product, marketing website, threat intelligence, three consulting clients, a personal brand layer. Each one boots with the same DNA. Each one diverges on canonical files, memory, output, and project state. None of them bleed into the others.

The sync mechanism is the load-bearing part. The update CLI pushes plugins, rules, agents, hooks, schemas. It never touches memory, output, canonical, or my-project. Those are the parts of an instance that accumulate.

Without selective sync you have two options: rebuild every instance on every change, or never update. Both are dead ends.

If you build features into one project, you wrote a project.If you build features into a template that propagates, you wrote an OS.

I’m one person operating eighteen versions of myself.

2. Move state out of prompts and into code.

LLMs are bad at remembering. Code is designed for it. Most AI workflows leak state into the prompt. Voice rules. Style preferences. Banned words. Recent decisions. Eventually you hit context limits or contradictions.

I moved as much state as possible into MCP servers. Voice linter. Lead scorer. Schedule validator. Loop tracker. They run in Python, return structured data, not hallucinations.

Rule of thumb: if you’ve explained it to Claude more than twice, it should be code.

3. Use receipts, not status fields.

This one took me the longest to figure out. Every workflow I had was claim something is done. Issue marked closed. PRD marked shipped. Test marked passing.

The problem: the LLM can claim anything.

I rebuilt the system around receipts. An issue can’t reach verified until a script runs and writes a verification record. A PRD can’t archive until every accepted finding has a receipt. A morning routine can’t close without log entries from every phase. Receipts get written by code, not by the model. The model can’t lie about whether code ran.

4. Build a wiring-check gate.

Half-built features rot. In a normal repo you notice because something breaks. In an AI repo nothing breaks. The half-built feature sits there and Claude pretends it works.

I built a /wiring-check command. Before any task counts as done, it checks: every new skill has a trigger, every new hook lives in settings.json, every new MCP tool sits in the server, every new bus file has a producer and a consumer.

“I think it works” fails the gate. “I ran X, got Y” passes.

5. Make rules auto-load, not slash commands.

If you have to type /voice to apply voice rules, voice rules will not get applied.

Rules in .claude/rules/ load automatically. The voice rule fires on outbound text. The AUDHD rule fires on anything I’ll act on. The social-reaction rule fires when I share someone else’s post.

No remembering. No willpower.

6. Lint style in code, not in prose.

I wrote a voice document once. Claude ignored half of it. Same emdashes, same filler, same hedging.

I moved the banned word list into a Python scanner. Now every outbound draft hits two linters. They block emdashes, AI hype words, and 40-something other tells. The model can’t talk its way past a regex.

7. Track file dependencies with a graph.

Canonical files reference each other. Change one and three others go stale. I keep a ripple-graph.json that maps these. When I edit talk-tracks, the system flags current-state and the engagement playbook for review.

8. Chain sessions with handoffs and memory. (This is the big one)

Sessions are drafts. The work is everything that survives the session: canonical files, memory, handoffs, output. If nothing persisted, you didn’t work. You chatted. Every session in my system ends with /q-wrap. Writes a handoff doc, a memory update, and a status receipt. /q-morning reads all three before doing anything else.

The handoff covers: what shipped, what’s blocked, what’s next, what I learned. Memory files hold the longer-term version.

The result: I can sleep for a week, come back, and the system reminds me where I was, what I cared about, and what the next move is.Nothing about Claude Code does this by default. You build it.

Continuity is a system property, not a habit.

9. Turn corrections into principles, not patches.

Wrong way to learn from a correction: tell Claude stop doing X in the next session.

Right way: extract the principle, write it to a markdown file, commit it, and let a reviewer model audit the diff.

I built a learn-from-correction skill that does this. Every correction becomes a proposal in output/skill-proposals/. I read it, accept or reject, commit. The skill file changes. The rule propagates to every instance on the next update. Corrections compound into capability.

Most devs think AI coding is about getting better answers.

That’s tool thinking.

The real shift is building something that persists across sessions, replicates across projects, learns from its own corrections, and lints its own output.

Not a chat.

An OS.

Cloudflare. Palo Alto Networks. Zscaler. Tanium. Tenable. Proofpoint. Qualys. Rubrik.

Eight security companies. One eight-month window. One attack class. The same attack class those companies sell products to prevent.

Each one published its own breach disclosure between August and October 2025. Cloudflare’s blog laid out the timeline hour by hour. Palo Alto’s Unit 42 wrote the technical post. Zscaler did its own version. They were honest about what got out. Business contacts. Support tickets. In Cloudflare’s case, customer-shared logs, tokens, and passwords from the support system itself.

If those eight companies failed, “buy better tools” is not the answer.

So what is the answer.

The name is Pokémon. The metaphor is the better story.

The group calls itself ShinyHunters. The name comes from Pokémon, where players hunt rare alternate-color creatures. That is the literal etymology. They picked it themselves around 2020 when they showed up on dark-web forums.

Forget the etymology. The metaphor is what matters.

Defenders chase shinies. The newest CVE. The latest XDR. The trending threat report. The next AI security category. Conferences run on shinies. Budgets get approved for shinies. Vendor pipelines fill with shinies.

ShinyHunters wins by attacking the boring stuff. Helpdesk verification scripts. Salesforce default settings. Refresh-token policies. OAuth Device Flow. None of it is shiny. Nobody pitches a Series B around it. Nobody runs a keynote about it.

That is the whole engine.

How they actually work

I worked threat intelligence at LinkedIn, Google, Meta, and ElevenLabs for twelve years. I have read a lot of attack write-ups. The thing about ShinyHunters that surprises people is how unimpressive each step is. There is no zero-day. No malware. No infrastructure exploit. They use a phone.

Three paths. None novel.

Path one: phone the helpdesk

Pretext is “we are updating your MFA settings.” Helpdesk worker walks the victim to a typosquatted SSO portal. Real-time man-in-the-middle captures credentials and the MFA code. Attacker registers their own MFA device. Then they authorize an OAuth-connected email tool that lets them silently delete the “security method enrolled” notification email so the legitimate user never sees the new device. Done.

Path two: phone the user

Same pretext. This time they walk the victim to the real Salesforce setup page at `login.salesforce.com/setup/connect`. Tell them to type an eight-character code. The code authorizes a connected app the attacker pre-registered, often disguised as “My Ticket Portal.” Salesforce issues an OAuth token to the attacker’s modified Data Loader. No MFA bypass. The token is from Salesforce itself. Traffic from that token looks like trusted integration traffic.

Path three: no phone call

Compromise a SaaS vendor that integrates with Salesforce. In the August 2025 case, attackers got into Salesloft’s GitHub repos in March, pivoted to Salesloft’s AWS, stole the OAuth tokens Salesloft uses for the Drift chatbot integration, and over ten days in August ran those tokens against more than seven hundred downstream customers. The customer was the third hop. They did nothing wrong.

Three paths. One name. Same outcome. Salesforce, OneDrive, SharePoint, Workspace data exfiltrated, then a delayed extortion email weeks or months later demanding four to twenty Bitcoin.

The eight boring things

Across the verified victim list, eight gaps repeat. Each one is named in Mandiant’s reports, the FBI advisory, Varonis’s analysis, or Salesforce’s own admin guidance. None of them are exotic.

1. MFA that is not phishing-resistant. SMS, push, OTP all defeated by the man-in-the-middle page. FIDO2 keys and passkeys are not.
2. Helpdesk verification an attacker can pass. Employee ID. Last four of SSN. Manager name. All of those are findable.
3. Salesforce defaults that let any user authorize an external connected app via OAuth Device Flow. Salesforce changed this default in September 2025. Most customers have not completed the audit.
4. OAuth refresh tokens with no IP binding and no expiry.
5. No monitoring of new connected apps or OAuth token use.
6. No detection of bulk file downloads or sensitive-keyword searches across SharePoint, OneDrive, Salesforce.
7. Third-party SaaS-to-SaaS integrations treated as trusted, not vetted.
8. No anomaly detection on identity events. No alert on a new MFA device registered outside enrollment, or a login from an anonymizer ASN.

Read that list again. It is not a tools list. It is a configuration list, a process list, and an ownership list. None of it is shiny. None of it gets a marketing budget.

The perimeter fallacy

The security industry spent fifteen years getting good at perimeter and endpoint. Firewalls evolved. Antivirus became EDR became XDR. The investment was real. The progress was real.

During those same fifteen years, customer data quietly moved into SaaS. Salesforce became the customer database. Workspace and 365 became the file store. Slack became the comms layer. Identity became the access plane. The data left the perimeter.

The investment did not follow it.

Inside most enterprises today, Salesforce admin reports through revenue or operations. OAuth governance lives nowhere. Helpdesk reports through IT support. Connected-app catalogs are owned by whoever last clicked “approve.” The org chart and the data flow are not aligned.

ShinyHunters operates in that misalignment. Vishing path one straddles helpdesk and IAM. The OAuth path straddles Salesforce admin, SOC, and identity. The supply-chain path straddles procurement, legal, and identity. None of those gaps belong to one team. All of them belong to nobody.

That is the perimeter fallacy. Not “the perimeter is gone.” The perimeter is gone is a slogan. The fallacy is the assumption that capital deployed against the old perimeter would somehow protect the new one. It does not. Better firewalls do not stop a phone call. Better EDR does not catch an OAuth token issued by Salesforce. Better DLP does not see a bulk export running through a legitimate connected app at API speed.

The investment did not move. The attackers did.

The advisory tax

Mandiant shipped a detailed hardening guide for UNC6040. It includes seven multi-event detection rules. The highest-fidelity one fires when an OAuth login is followed within ten minutes by data exfiltration by the same user. That is the operational signature of UNC6040.

Most victims did not deploy the rule.

FBI IC3 shipped IOC IP and domain lists in September 2025. Most victims did not block them.

Salesforce changed a default in September 2025 that closes the OAuth Device Flow vector.

Most customers did not complete the audit.

The rules exist. The IOCs exist. The defaults exist. They do not get deployed because every advisory is a nine-team scramble that nobody owns. The IAM team reads the MFA recommendation. The Salesforce admin reads the OAuth recommendation. The SOC reads the detection rules. The procurement team reads the third-party recommendation. Each team picks the one item that fits their mandate. The other seven rot.

I have watched this happen at four companies. It always looks the same. A high-quality advisory drops. There is a kickoff meeting. Eight people show up. One person owns it for two weeks. Then they get pulled to something shinier. The advisory becomes a thread in Slack. Six months later, the next advisory drops, and the cycle restarts.

That is the advisory tax.

Every new ShinyHunters research artifact is treated as a ticket to read, not as a Learning Artifact to govern. The next advisory will look the same. So will the response.

Attackers compound. Defenders restart.

Seven hundred companies got breached on the same day in August 2025 through Salesloft Drift. Six months later, ask each of them which of the eight gaps they closed. The honest answer at most of them is some of one and a piece of another. The complete picture lives nowhere.

Attackers do not have this problem. The Trinity of Chaos crew (ShinyHunters, Scattered Spider, Lapsus$ in a merged Telegram channel since August 2025) shares pretexts, lookalike domain templates, OAuth flows, and IOCs across operators. Each victim teaches them. The lesson persists.

Defenders run the opposite trade. Each victim learns alone. The lesson dissipates.

This is what makes ShinyHunters look unstoppable. They are not unstoppable. They are compounding while defenders restart.

What I think KTLYST is for

I run KTLYST Labs. We are not a Salesforce security tool. We are not a SOAR. We are not an XDR. We do not sell a fix for ShinyHunters.

What we believe is that the silo model is the bug. Sixty security tools per enterprise. Sixty muscles, no nervous system. Tools optimize execution. None of them own learning. AI is making the silos faster, which makes the chasm between teams deeper.

Memory > more tools. That is the bet.

I am not pitching that here. The point is the worldview. If the worldview is right, ShinyHunters is the predictable consequence. If the worldview is wrong, ShinyHunters is an aberration that better tools will eventually catch up to.

I think the worldview is right. The eight companies at the top of this post agree by their own disclosures. They had the tools. They had the research. They had the budget. They got hit anyway.

Because the gap is not between the attack and the toolset. The gap is between the toolset and the rest of the company.

Why ShinyHunters win

Defenders chase shinies. Attackers run the boring layer. The advisories that would close the boring layer become a tax on already-overstretched teams, where each advisory dilutes across nine owners and rots into a Slack thread.

ShinyHunters is named after Pokémon. They could have been named for what they do. Defenders watch the front door. They walk in through the helpdesk, the OAuth grant, the third-party token, the unsexy default that nobody owns.

Boring beats shiny. That is why they win.

The fix is not a better tool. The fix is owning the boring layer like it matters. With memory. With nervous system. With one accountable person who reads every advisory and turns it into deployed defense across nine teams.

Until that exists in your company, ShinyHunters has not stopped winning. They have only not gotten to you yet.

— -

• Sources cited in this piece include published research from Mandiant, FBI IC3, Varonis, Obsidian Security, Mitiga, Krebs on Security, and the corporate disclosures of Cloudflare, Palo Alto Networks, Zscaler, Tenable, Proofpoint, Tanium, PagerDuty, SpyCloud, Qualys, and Rubrik. The named-victim register, attack-path technical detail, and eight-gap synthesis stand on those sources.
• The “boring beats shiny” frame and the perimeter-fallacy reading are mine.*

Another critical auth bypass. Another Progress Software advisory. Another Monday where security teams across the industry open their inboxes and see a CVE that needs immediate action.

Most of them will patch it. Some will do it fast. A handful won’t.

But here’s the thing nobody talks about in the post-mortems: the teams that patch fast still get breached. Not because the patch didn’t work. Because patching is one response out of four that needed to happen simultaneously.

— -

I spent years at LinkedIn, Meta and Google watching this same failure repeat across every major advisory cycle.

An advisory drops. The SOC lead forwards it to the right people. Everyone nods. The patch gets applied.

Three weeks later, during a post-incident review, someone asks: did we audit who had access during the exposure window? Did compliance check the notification timeline? Did endpoint do a sweep for indicators of compromise?

Silence.

Not because the teams are incompetent. They’re not. They’re excellent. But each team got the same one-line Slack message and was expected to independently derive what that advisory meant for their specific domain. SOC speaks in detection rules. IAM speaks in access grants and audit logs. Compliance speaks in regulatory timelines. Endpoint speaks in agent telemetry.

One advisory. Four languages. Zero translation infrastructure.

— -

The 2023 MOVEit exploitation wave hit hundreds of organizations. Some of them had the patch installed within 48 hours. They still ended up in the breach list.

Why? Because the patch closed the door. But attackers had already walked in during the exposure window. And the IAM team didn’t know they needed to look for lateral movement in that window. The compliance team didn’t flag that the notification clock had started. The executive team had no talking points ready when customers started calling.

The vulnerability closed. The coordination gap stayed open.

— -

Here’s the assumption the industry got wrong: that a well-staffed security organization would naturally self-coordinate around a critical advisory.

That assumption made sense when teams were small, when the same person ran SOC and did IR and handled compliance questions. It broke completely when orgs grew past 50 people, split into specialized teams, and bought 60 different tools to manage 60 different surfaces.

At that point, every advisory requires a translation step. Someone has to read the raw CVE or intelligence report and rewrite it four times: once for detection, once for identity, once for compliance, once for the executive briefing. That translation step is a 40-hour manual job. It usually falls on a senior engineer who has twelve other things burning.

The result: the patch gets prioritized because it’s concrete. The downstream coordination doesn’t happen because it’s ambiguous. The ambiguous thing is usually the one that lets attackers persist.

— -

I’ve described this problem to a lot of CISOs over the last year. Almost all of them say the same thing: “That’s exactly what happens here. Every time.”

The interesting part isn’t that they recognize the problem. It’s that none of them have a systematic fix for it. Most orgs have a runbook that says something like “when a P1 advisory lands, notify these teams.” The notification happens. The team-specific actions don’t.

Because a notification isn’t a work package. “You should know about this MOVEit CVE” is not the same as “here are the three IAM queries you need to run, here is the access audit scope, here is the regulatory notification checklist pre-filled with what we know so far.”

The gap isn’t awareness. It’s translation. It’s the work of turning raw intel into team-specific, tool-specific, actionable packages for each function.

— -

The defenders I respect most, have some version of a personal system for this. They’ve built their own templates over years. They know from experience that a MOVEit-class advisory means IAM runs a specific access audit, compliance opens a specific checklist, SOC deploys a specific detection rule set.

That institutional knowledge lives in their head. It doesn’t transfer when they leave. It doesn’t scale when their team doubles. It doesn’t run at the speed of an advisory that drops at 6am Monday.

The problem isn’t that we lack smart defenders. We have plenty. The problem is that their hard-won knowledge stays locked up as folklore instead of getting codified as repeatable process.

The best security orgs I’ve seen treat every incident and advisory response as an opportunity to build that institutional record. They debrief. They document what each team did. They build the translation map over time.

Most orgs don’t. They patch. They move on. The next advisory finds them starting from zero again.

— -

MOVEit will show up again. Different CVE, same coordination failure. The advisory will land on a Monday. Four teams will need four different packages by Tuesday. Someone will manually translate it. Some things will get missed.

The question isn’t whether this breaks. It’s whether we’re building systems so that when it breaks, the right information reaches the right team automatically, with provenance, before the window closes.

That’s not a detection problem. It’s an institutional memory problem.

And the industry hasn’t built that infrastructure yet.

I’ve run investigations for over a decade. Threat actors, fraud rings, coordinated inauthentic behavior, insider threats. At LinkedIn, Google, Meta, ElevenLabs. Different companies, different threat models, same workflow.

Pull data. Cross-reference. Profile targets. Build timelines. Write the brief. Close the case.

Start from zero on the next one.

That last part always bothered me.

The Problem Isn’t the Analyst. It’s the Amnesia.

Investigations are expensive. Not just in hours, but in context. By the time an analyst finishes a case, they’ve built a mental model of dozens of data points, relationships, timelines, and behavioral patterns.

Then the case closes. The mental model evaporates.

The next analyst on a similar case starts cold. Rebuilds the same context. Asks the same questions. Misses the same patterns the last person eventually caught.

I watched this happen at every company I worked at. The team learns. The learning disappears. I started calling it “investigation amnesia.” It’s not a tooling problem. It’s a structural one.

What I Built

When I started my consulting practice at ASK Consulting, I decided to build the system I wished I’d had.

Q is an investigation operating system. It runs inside Claude Code, which means it has access to the filesystem, shell, browser, and a growing set of external APIs through MCP servers.

It’s not a chatbot that answers questions about investigations. It’s a structured system with defined operating modes, persistent memory, and enforced intelligence standards.

Here’s what that means in practice.

Structured, Not Conversational

Q operates in four modes. COLLECT gathers data on targets. ANALYZE connects dots and surfaces patterns. BRIEF generates client-ready reports. INTAKE processes new information into the investigation structure.

Each mode has specific commands. Each command has defined inputs, outputs, and file destinations. Nothing is freeform.

When I say “collect,” Q checks its collection plan, identifies the highest-priority gaps, suggests what to gather and from where, and tags each action with effort level and time estimate. When I bring data back, it routes findings to the right files, cross-references against existing targets, and flags new leads.

This isn’t autocomplete for investigations. It’s project management with an intelligence framework baked in.

Evidence Chains, Not Chat History

Every investigation case gets its own folder with a fixed structure. Scope. Collection plan. Target profiles. Findings. Evidence. Timelines. Session memory. Output.

The structure is enforced. Every claim cites its source. Every assessment carries a confidence level. Every target profile tracks what we have and what we still need.

Between sessions, Q writes a handoff note. When I come back, it reads the handoff, loads the case state, and tells me exactly where we left off and what to do next.

That’s the part that matters. The system remembers. Not the analyst.

Real Numbers From a Real Case

On a recent investigation, Q processed over 375 forensic evidence files across 18 device and account categories. Screenshots, spreadsheets, PDFs, account logs.

It identified 8 subjects, profiled each one, and mapped the relationships between them. It traced malware domains through threat intelligence databases. It built a timeline of 90+ confirmed events spanning 9 years.

It produced two client-ready reports with full source citations, linking every finding back to specific evidence files. 158 citation groups. 114 unique source documents referenced. Zero unresolved citations.

I didn’t build the reports. Q did. I steered the investigation.

OSINT, but Systematic

Q has a collection toolkit wired into it. Threat intelligence lookups (VirusTotal, URLhaus, ThreatFox, certificate transparency). Social media scraping through Apify actors. Search APIs for reconnaissance. Domain and DNS tools.

But the toolkit isn’t the point. Any analyst can run a VirusTotal lookup.

The point is that Q knows what it hasn’t looked up yet. It maintains a collection plan. It tracks which sources have been tapped and which gaps remain. When collection stalls, it drafts questions for the client, because the client often knows the answer to something that would take 50 tool calls to research.

That’s investigation management. Not just data pulling.

Why This Connects to KTLYST

My co-founder Stephan and I are building KTLYST on the same thesis. When security teams investigate threats, they produce intelligence. That intelligence should compound. It should make the next investigation faster, the next detection better, the next response sharper.

Q is the consulting-scale version of that idea. One analyst, one system, persistent memory.

KTLYST is the enterprise-scale version. Multiple teams, shared learning, institutional memory that survives analyst turnover.

The structural problem is the same. Investigations produce value. Organizations let that value evaporate.

What I Didn’t Build

Q doesn’t replace an investigator. It doesn’t make decisions. It doesn’t send anything to a client without me reviewing it.

It also doesn’t do magic. When it hits a wall, a password-protected file or a subpoena requirement or a question only the client can answer, it stops and tells me. That’s by design. I built a fail-stop rule into the system because the worst thing an investigation tool can do is quietly skip something important.

The analyst still drives. Q keeps the road from disappearing behind us.

The Bigger Question

We’ve spent years building security tools that detect and respond. SIEMs, SOARs, EDRs. Fast reflexes.

But what system remembers what you learned? What system makes sure the next investigation benefits from the last one?

That’s the gap. Not more tools. More memory.

If your investigation workflow resets to zero every time a case closes, you don’t have a program. You have a treadmill.

Not because prompts don’t work. Because they don’t survive.

A 100-turn conversation decays. Instructions from turn 3 are gone by turn 40. Context dilutes. The model drifts toward the nearest plausible completion, not the one you actually need. Anyone who’s worked with long-context models has felt this. You re-explain, you repeat, you watch the quality drop. So I stopped fighting it. I built a system instead.

The core idea: markdown files are the prompt

Everything Claude Code needs to know lives in structured markdown files. Not in conversation history. Not in a mega-prompt I paste every session. In files on disk that the model reads when it needs them.

I call these “canonical files.” They hold the current state of whatever I’m working on. Positioning, decisions, relationships, competitive landscape, known objections, proven language. When something changes, I update the file. The file is the source of truth. The model reads it. Done.

This means I never re-explain context. I never lose instructions between sessions. The model doesn’t need to remember anything because the files remember everything.

Token discipline: the model should read less, not more

Here’s where most people get it wrong. They dump everything into context and hope the model figures out what matters.

It won’t.

Large files kill performance. A 2,800-line reference file is ~45K tokens. The model reads the whole thing, buries the critical constraints under walls of text, and the output drifts. I’ve watched it happen repeatedly.

So I built a step-loader. Instead of loading a massive file, it extracts the specific section I need. ~940 tokens instead of 45K. The model sees only what’s relevant to the current task.

Rule: if a file is over 200 lines, the model reads only the section it needs. No exceptions. This alone fixed most of my context dilution problems.

Time-stratified memory

Memory was the hardest part to get right.

The problem: some information is relevant for 24 hours. Some for a week. Some permanently. Treating it all the same means either stale context (kept too long) or lost context (cleaned too early).

Three tiers:

- Working memory. Expires in 48 hours. Session-scoped, ephemeral. Today’s meeting notes, a draft I’m iterating on, a thread I need to follow up on.

- Weekly memory. 7-day rolling window. This week’s priorities, active conversations, things I said I’d do.

- Monthly memory. Persists until I remove it. Key relationships, strategic decisions, proven approaches.

Session start auto-cleans the expired stuff. The model never wastes context on information that’s no longer relevant. Fresh session, clean memory, tight context.

Structured handoffs: zero drift between sessions

Every session ends with a handoff command. It writes a state file to disk. Not a summary of what happened. A summary of what the next session needs to know to keep going.

The distinction matters. A conversation summary says “we discussed X, Y, Z.” A handoff file says “X is decided, Y is blocked on this specific thing, Z changed in this specific file and here’s what that means for tomorrow.”

Next morning, the startup command reads the handoff file. The model picks up exactly where I left off. No re-explanation. No drift. No “as we discussed yesterday” because it already knows.

I’ve been running this for months. Zero instruction drift between sessions.

Custom skills for repeatable workflows

Some things I do every day. Some things I do every week. Writing them from scratch each time is waste. So I built skills. Each skill is a markdown file that encodes specific knowledge and a specific process. Voice consistency for written output. Content review against guardrails. Meeting debrief extraction. Engagement workflows.

35+ skills now. The model loads only the skill it needs for the current task. A debrief doesn’t load the content review skill. A LinkedIn comment doesn’t load the meeting prep skill. Each skill is self-contained, tested, and tight.

This is where it compounds. Every skill I build makes the next session faster. Every edge case I encode means I don’t hit it again. The system learns even when the model forgets.

Fail-fast with audit trails

Complex workflows break. That’s a given. The question is whether you know they broke.

Every step in my morning routine logs its completion status to a JSON file on disk. Not in conversation context. On disk. Even if the model’s context degrades, the log is accurate.

If something fails, the system stops immediately. No partial runs. No “let me try to work around it.” Stop, report what broke, fix it, re-run.

After the routine finishes, a Python audit script reads the log and gives me a completion verdict. Steps completed, steps failed, steps skipped. I never have to wonder if something ran or not.

What I actually learned

The insight that took six months to internalize: Claude Code isn’t a chatbot you prompt. It’s infrastructure you configure.

The quality of your outputs is directly proportional to how well you architect what the model sees and when it sees it. Shorter prompts help. Clearer instructions help. But what helps most is building a system where the right information is available at the right time, stale information is automatically cleaned, and every session starts from a known state instead of a blank conversation.

I’m not sharing the repo because it’s built around my specific workflow. But the patterns are general. Canonical files, token discipline, time-stratified memory, structured handoffs, composable skills, audit trails. None of this requires

special tools. Just markdown files and a willingness to treat your AI workflow like infrastructure instead of conversation. The long-context problem is real. The fix isn’t “write less.” It’s building better systems for what the model sees and when.