LinkedIn Weekly

David Lee's Workspace · generated Monday 2026-07-20 6:51 PM ET

Last week — post-mortem · Jul 12 - Jul 18, 2026

18,391Impressions
102Engagements
2Posts
6,863Followers
+34Follower gain
+1,472%Impr. WoW

Two posts, split down the middle. One 1.5x winner (16.9k impressions) and one 0.5x dud (1.0k). The delta is the whole lesson: the dated event teaser worked, the vague no-payload teaser did not.

Best 1.5x · 16,886 impressions

7.28.26 -- Let's have a different conversation around AI Security. Link in the comments, I'll see you in NY!

View on LinkedIn →
Worst 0.5x · 1,041 impressions

One of the best conversations I had at Identiverse.

View on LinkedIn →
What worked What missed Apply this week
4-week trend
WeekPostsImpr.Eng.Best
Jun 14-20516,439 3151.9x
Jun 21-2715,454 841.3x
Jun 28-Jul 0411,969 530.9x
Jul 12-18218,391 1021.5x

This week — drafts + pre-mortem · Jul 20 - Jul 26, 2026

3 high-signal drafts. All grounded in real events and the newsletter arc (agentic AI security, NHI, MCP). Drafts only. You approve and publish in Supergrow.
Dated event anchor + real payload (7.28 NY AI Security)revised
8/10

Why now: Doubles down on your proven 1.5x format, but fixes last week's miss by carrying the argument, not just the invite.

7.28.26. I'm getting on a stage in New York to say something a lot of security teams don't want to hear.

The AI agents you are rushing into production are non-human identities, and most of you have no idea how many you already have.

We spent twenty years learning to govern human access. Joiner, mover, leaver. Least privilege. Access reviews. Then we handed a service account to an autonomous agent that can spin up ten more before lunch, and we called it innovation.

The uncomfortable part is not that agents are risky. It is that we already know how to manage identity risk and we are choosing not to apply it here because it feels new.

It is not new. It is the same problem wearing a different badge.

I'll be making this exact argument on stage in New York on 7.28. If you are wrestling with it in your own program, come find me there. Or tell me now. Who owns the identity of an agent when it makes a decision you did not approve?
Pre-mortem (80%)

Original draft's only weak spot was CTA (rhetorical question only). Revised below to add a real in-person CTA while still ending on a question. Content DNA, hook, originality all strong.

Contrarian reframe (govern agents as identities, not features)
10/10

Why now: Mirrors your best-ever structure (the 'least privilege is about to stop being enough' reframe). Scored a clean 10/10 in pre-mortem.

Everyone is racing to connect their agents to everything. MCP servers, tools, internal APIs, the whole catalog.

Nobody is asking the boring question. Who is that agent when it knocks on the door?

Here is what I keep seeing. A team stands up an agent, gives it a token that never expires, scopes it to everything just to get the demo working, and promises to tighten it later. Later never comes. Now you have a credential with god access and no human attached to it, and it is talking to systems you forgot it could reach.

The agent is not the threat. The standing, over-permissioned, unattended identity behind it is the threat. That is not an AI problem. That is an identity problem we already failed once with service accounts.

We have a chance to not repeat it. Are you governing your agents as identities, or just as features?
Pre-mortem (100%)

Perfect score. Optional lift: add one line of lived experience (a real conversation where you saw this) to make it unmistakably yours.

Personal vulnerability + community CTA
9/10

Why now: Your vulnerability-plus-community format hit 1.3x to 1.9x across the last month. Reliable engagement, humanizes the technical arc.

I have been doing identity for twenty-two years, and I still get it wrong sometimes.

Last month I argued hard for a design in a room, felt certain, and a younger engineer quietly pointed out the flaw I had walked right past. My first reaction was defensive. My second, better one, was gratitude.

The longer I do this work, the more I believe the best security people are not the ones with the most answers. They are the ones who stay curious enough to be corrected.

We are about to hand a lot of trust to systems that cannot be corrected the way that engineer corrected me. That should make us more humble about what we deploy, not less.

Who is the person that made you better at this work, and did you ever tell them?
Pre-mortem (90%)

Strong. Pre-mortem notes: tighten the two-part closing question and add more whitespace between beats to match your cadence.