Categories
Artificial Intelligence Reading Material Security

Security leaders we surveyed feel pressure to secure their AI, and almost none of them feel ready

Here’s a fun little contradiction to start your week with: NetFoundry asked 200 CISOs and CTOs whether they feel pressure to secure the AI they’re deploying. Unsurprisingly, and to my considerable relief, every single one said “yes”.

We then asked how confident they are that their current tools can actually handle the new risks, and 15% said “very.” 15% is very slightly less that the odds for rolling six on a 1d6. More specifically, among the CISOs, whose entire job is to be the professional pessimist in the room, that figure dropped to 10%.

That’s the current situation: Universal pressure, near-universal doubt.

If you just want to get to the report, it’s here. But if you’d like to know more, read on…

Disclaimer and where the survey comes from

I work at NetFoundry as a developer advocate, and NetFoundry commissioned this report. So yes, this is a vendor survey, and you’re correct to raise an eyebrow. (I’d be worried if you didn’t).

In our defense, we did the thing you’re supposed to do: the survey itself was run by an independent research firm (Global Surveyz), the respondents were 200 US-based security and technology leaders at companies with 1,000+ employees, and it was fielded this past May and June. The full thing is linked at the bottom so you can check my arithmetic and decide for yourself whether I’m cherry-picking.

I’m going to try very hard to separate what the survey found from what I think it means. The first category is data. The second category is me, a guy on the internet, having opinions, which won’t always be the same as NetFoundry’s Marketign department (it happens). I’ll flag which is which.

The number that reframed the whole thing for me

Of everything in here, this is the one I keep coming back to:

Security leaders are nearly 10x more likely to worry about securing machine-to-machine workloads than human access to applications.

Specifically: 69% said machine workloads (service-to-service, API-to-API, agent-to-whatever) are where they’re least confident today. Just 7% said human user access. The remaining 24% said “both equally,” which I read as “please don’t make me pick.”

That tracks perfectly, and it’s a compliment to the last decade of security work. Think about what we spent the 2020s doing. COVID sent everyone home, remote access became the whole ballgame, and the industry poured an enormous amount of money and brainpower into VPNs,  Zero Trust access, and all sorts of security measures for a world that was suddenly more online that ever. It worked, and hman access to applications is, comparatively, a solved-ish problem. We got good at authenticating people. (I should know; it was during that time that I worked at Auth0!)

The issue of identity

The catch is that all of that machinery is built on one quiet assumption: that the thing connecting to your app is a human being with a unique identity. You authenticate the person, then you grant the access.

My late former coworker, Vittorio Bertocci, has forgotten more about identity than I will ever learn, and he was starting to look very deeply into identity in the age of AI.

Agents and models don’t work like that. They don’t have identities the way humans do. So the tooling we built for the last problem doesn’t cleanly transfer to this one, and the volume is going the wrong direction, fast. Machine traffic is now growing several times faster than human traffic year over year. We got really good at guarding a door that fewer and fewer of the visitors are actually using.

A few more stats worth your attention:

  • 100% agree their attack surface is growing. Not a plurality. Not a strong majority. Everyone. The average projected increase was 14% over the next 12 months, and that figure only counts AI deployments already underway or planned. 14% is probably the minimum.
  • 93% are concerned about the new risks AI introduces, but only 15% are highly confident their current tools can handle them. That’s the gap I opened with. When the level of concern and the level of confidence are that far apart, something structural is going on.
  • 99% admit they don’t have full visibility into their own AI deployments. That remaining 1%, which would have to be one respondent? I would like to buy that person a coffee (or beer! or bourbon!) and ask them a lot of questions.
  • 90% are worried about shadow AI, the unsanctioned tools employees adopt on their own because the approved options don’t cut it. This is not a technology problem, it’s a human-nature problem. I will neither confirm nor deny my own contributions to the shadow AI at previous organizations, but in my defense, I was getting things done! When a tool is genuinely useful, people use it, memo or no memo.
  • Only 8% call their current identity systems “very sufficient” for non-human workloads. 85% are now actively evaluating or exploring new approaches. That second number is the tell. When five out of six organizations are shopping for a new approach at the same time, that’s teh surest indicator that the industry is collectively coming to the realization that the existing tools weren’t built for this.
  • Oh, and it’s slow. 55% cited risk and compliance review as a top contributor to delays in the network changes AI deployments need, and those changes add an average of 8 days from request to implementation. And that’s now, while AI-specific scrutiny is still warming up.

My read (this part is me, not the data)

In this section, I’m switching from reporting to speculating.

I think almost every number above traces back to one root cause: machines don’t have real identities. They have internal names so that developers and devops people can talk about them, but when it comes to having reasonably canonical identities like we humans do (full name, usernames, an email address, a government-issued unique ID number), we haven’t really created these for machines.

In the absence of machine identities, we have workarounds. On the less secure end, we have IP addresses; on the (relatively) more secure end, there are shared secrets, API keys, long-lived service-account credentials. As with most workarounds, they quietly rot. The credentials we give machines tend to carry more permission than they need. They rarely get rotated. After a while nobody’s entirely sure which agent a given key even belongs to, or why it exists.

Once you’re in that world, everything downstream gets harder. Visibility is hard because you can’t tell one agent’s actions from another’s. Access control is hard because a secret isn’t an identity, it’s some piece of data that happens to belong to a robot (and all too easily duplicated). Auditing is hard for both of those reasons at once. The identity gap is the root problem of most of the other security problems in the AI age.

NetFoundry — who are made of some very smart people, a few of whom are literal greybeards! — obviously has opinions about how to close that gap, and the report gets into them. That’s the vendor part, and you can take it or leave it.

In case you saw the em-dashes in the paragraph above and thought “Aha! AI!’, I assure you that I typed them in myself, because this is my relationship with AI:

Entering em-dashes is dirt simple on macOS: option-shift-minus. On Windows it’s a little more work: alt+0151. On Linux: control-shift-U, then release and type 2014, then return/enter.

Let me have just a couple of em-dashes in my article. Please.

But strip the logo off and the underlying observation stands on its own: we spent a decade giving humans strong identities and largely ignored the machines, and now the machines are the fastest-growing thing on the network. That bill was always going to come due. It’s just arriving faster than most people planned for.

The stat I want ask you about

That 14% attack-surface increase feels low to me. If you’re actually running agents in production right now, watching them spawn sub-agents and reach across cloud boundaries and pick up new tool integrations every sprint, does 14% over a year match what you’re seeing, or is it wildly optimistic?

(That’s a genuine question, not a rhetorical one. I’d rather hear it from people living it than trust my own gut.)

Read the full 2026 State of Secure AI Access report!

Download it here. (You have to provide a little info to get it.)

Categories
Artificial Intelligence Process What I’m Up To

How I explain how I use AI in my presentations

Pictured above is my standard AI usage disclosure slide, which I include in all my slide presentations these days. It’s gives the audience a quick overview of how I prefer to use AI when putting a talk together.

Here’s the text:

This strategy presentation was developed using AI assistance (Claude, ChatGPT, and Gemini) for:

  • Research: Market trend analysis and competitive landscape review
  • Editing: Grammar, clarity, and flow optimization
  • Ideation assistance: Testing ideas and generating new ones, because no matter how creative you are, it’s impossible to come up with a list of things you’d never think of.

The main contents — including strategic insights, tactical recommendations, specific positioning, and any em-dashes (option-shift-minus on Mac, alt + 0151 on Windows, Google “em dash” and copy and paste it on Linux) — were developed based on analysis of the interview materials and 15+ years of experience in the industry.

I suppose I should also include something about being too much of an egomaniac to let a word prediction machine outshine me. My relationship with LLMs is sort of like the relationship between Dr. Niles “Chief” Caulder (who formed the Doom Patrol) and Batman, as pictured in Batman/Superman: World’s Finest (2022), issue 2:

Categories
Artificial Intelligence Security

Two doors an attacker loves, and one they can’t find

I drew the illustration above on the back of an actual envelope (one of my new “things” these days). It’s either the most or the least appropriate medium for a diagram about attack surface. Your call.

It’s here because my colleague Mark JaffeNetFoundry’s Chief Strategy and Marketing Officer — just published an article called MCP Is Spreading Through Your Enterprise at Developer Speed. Your Security Architecture Isn’t, and it makes a point that I think is worth more than a link-and-a-shrug. So I illustrated one of its key ideas the old-school engineer way, because you’ve probably seen enough AI-generated images and need to look at something a little more human.

Read the article: https://netfoundry.io/ai/mcp-is-spreading-through-your-enterprise-at-developer-speed-your-security-architecture-isnt/

You’re probably seeing this happening around you: teams are wiring AI agents up to their CRMs, databases, and internal APIs through Model Context Protocol servers, because MCP makes it easy. What almost nobody is asking, and what security teams usually can’t even see, is whether the way they’re connecting those servers is quietly creating a new attack vector. In most of the deployments NetFoundry runs into, it does.

The cartoon is Mark’s “before and after,” in three panels. The first two are how nearly everyone connects an MCP server today. The third is what he argues you should be doing instead.

1: Public MCP (a.k.a. “door open to anyone”)

You publish the MCP server on a public hostname, stick a load balancer in front of it, and rely on an API key or an OAuth token to authenticate the agent.

If that gives you déjà vu, it should. This is the exact pattern we all used for REST APIs back around 2012, and it carries the exact same flaw. The server is reachable by anyone on the internet who can enumerate the endpoint or get their hands on a credential. It has to be reachable, because the agent needs to find it. Which means so does everybody else.

That’s the evil bot in the corner going “poke poke.” He doesn’t need to be clever. He just needs the door to exist.

2: Jump host inside (a.k.a. “one session pivots to all”)

“Fine,” you say. “We’ll keep everything internal. Run the agent on a jump host or a dedicated VM inside the network, nothing exposed to the public internet, problem solved.”

Except now you’ve traded one problem for a subtler one. That agent is the thing that’s calling an external LLM, ingesting user-supplied prompts, and taking actions across a dozen connected tools. It’s also now sitting on a trusted internal segment with network-level reach to systems far beyond what it actually needs. Compromise a single agent session and you’ve got a pivot point. One hop to the CRM, one hop to the database, one hop to the internal APIs.

That’s the middle panel: the agent with arrows fanning out to everything. One session pivots to all of them.

3: Outbound only (a.k.a. “don’t call me, I’ll call you”)

Here’s the fix, and the almost annoying thing about it is that it isn’t new. It’s the same outbound-only, identity-bound, least-privilege model that zero trust has been asking for all along. What’s new is applying it to the one connection (agent to MCP server) where none of your existing controls (firewalls, WAFs, network segmentation) actually operate.

The MCP server lives on a private subnet with no inbound connectivity. Instead of the agent reaching in to find the server, the server dials out to meet the agent through an authenticated, encrypted tunnel. There’s no public address to enumerate, no port to probe, nothing sitting there waiting to be found.

Or, as my little pencil agent puts it: don’t call me, I’ll call you.

That line did more work in one speech bubble than a paragraph of my prose could, which is a humbling thing to learn from a robot you drew yourself.

The part that isn’t about doors at all

The panels are the fun part, but the argument I’d actually push you to sit with is why this isn’t just an API-gateway problem wearing a new hat. Mark lays out three things MCP changes that break the old assumptions:

The client is autonomous. An AI agent doesn’t just call an endpoint. It decides which endpoints to call, in what order, with what parameters, based on reasoning you can’t fully predict or constrain up front. So your attack surface isn’t “the MCP server.” It’s the full action space of every tool that agent can touch, across every session it runs.

The session context carries risk. MCP servers receive the agent’s reasoning context right alongside its tool requests. If an attacker can inject content into that context (prompt injection in a document the agent reads, a poisoned result from an earlier tool call, a malicious server the agent got pointed at) they can influence the next tool call in the same session. The MCP connection is the channel that influence travels down.

The inventory is invisible. Most organizations have no systematic way to know which MCP servers their teams have already stood up, which agents are connected to them, or what those servers can reach. If “shadow API” gave you a twitch a decade ago, meet shadow MCP. It’s the same problem, but building up considerably faster.

That speed is the whole thesis, really. The API security industry got the better part of ten years to retrofit controls around a pattern it shipped before it fully understood. MCP is running the same curve compressed into months. Nobody’s getting ten years this time.

So what do you do with this?

If AI-agent security is landing on your desk right now, the uncomfortable truth in Mark’s piece is that the architecture decisions your developers are making this quarter are the ones that’ll be expensive to unwind later. A dev who wires an MCP server to your production CRM through a public hostname isn’t making a temporary choice. They’re setting the pattern every future agent deployment quietly copies.

The good news is that the fix is boring and well-understood. Outbound-only. Identity bound to the connection. Every session governed and observable. Panel 3, basically.

Go read the whole thing! It’s about an eight-minute read and it’s sharper than my envelope.

Categories
Artificial Intelligence What I’m Up To

You can’t spell “airport” without “AI”

Yesterday, Anitra and I were flying back to Tampa from New York’s LaGuardia Airport, and I noticed that most of the ads flashing on the billboard screen overlooking our departure lounge were for AI companies or products.

There were two different ads for Codex (one pictured above, one below)…

…one for Devin

…and one for “Taika Waititi’s fascist twin from a parallel universe”’s company:

Categories
Artificial Intelligence Conferences Tampa Bay

Tampa Bay Tech Week presents 727 Tech Day!

Monday, 7/27, is the day when we celebrate the techies and tech companies in the 727 area code: 727 Tech Day!

727 Tech Day is a one-day, all-in celebration of the St. Pete / Clearwater / Pinellas tech community, presented by the folks behind Tampa Bay Tech Week (with HyLo Innovation and W3RTech). If TBTW is the five-day, five-neighborhood sprawl, then 727 Tech Day as the encore focused on a single Tampa Bay county, with everybody in the same few rooms.

If you’re anywhere near the 727 and you build systems or software for a living, this is the easiest “yes” on your calendar this week.

The essentials

  • When: Monday, July 27, 2026
  • Where: Clearwater and St. Pete. It’s a venue-hop (details below)!
  • Cost: Register on Luma → luma.com/567lh3c0
  • Vibe: Panels, hands-on workshops, a lot of open networking, and an evening that keeps going

727 Tech Day moves around the county!

This isn’t a sit-in-one-ballroom-until-4pm situation. The day migrates across Clearwater and St. Pete, which is either a feature or a step-count challenge depending on your mood:

  • Sunrise yoga on the rooftop at Station House to kick things off. Yes, yoga. At a tech event. Bring your own mat or grab one onsite. I’m told no other tech event in Florida opens like this, and I believe it.
  • Morning sessions at Collaborative Labs (over at St. Petersburg College).
  • Afternoon sessions at NOVA 535 in downtown St. Pete.
  • Happy Hour Networking at 4 PM at the St. Pete Athletic Club, with three hours of the good stuff (founders, operators, investors, community folks, all in one place).
  • Closing Night at 7 PM at The Estate, because “conversations to activations” apparently requires at least one iconic venue and a proper send-off.
Event name and location Group Time
Rooftop Yoga
Station House
Tampa Bay Tech Week – 727 Tech Day 7:00 AM to 8:00 AM EDT
Registration and check-in
Collaborative Labs
Tampa Bay Tech Week – 727 Tech Day 8:30 AM to 9:00 AM EDT
St. Pete’s Economic Development Discussion
Collaborative Labs
Tampa Bay Tech Week 9:00 AM to 10:00 PM EDT
Maritime and Defense Tech Panel Discussion
Collaborative Labs
Tampa Bay Tech Week – 727 Tech Day 10:00 AM to 11:30 AM EDT
Build Your AI Workflow Live Workshop
Nova 535
Tampa Bay Tech Week – 727 Tech Day 12:00 PM to 1:00 PM EDT
AI + Marketing What Actually Works In 2026
Nova 535
Tampa Bay Tech Week – 727 Tech Day 1:00 PM to 2:00 PM EDT
Using AI As a Revenue Engine
Nova 535
Tampa Bay Tech Week – 727 Tech Day 2:00 PM to 3:00 PM EDT
Raising Capital in 2026 For Your Business
Nova 535
Tampa Bay Tech Week – 727 Tech Day 3:00 PM to 4:00 PM EDT
727 Tech Day Networking
St. Pete Athletic
Tampa Bay Tech Week – 727 Tech Day 4:00 PM to 7:00 PM EDT
727 Tech Day Closing Celebration Sponsored by XUNA AI
The Estate
Tampa Bay Tech Week – 727 Tech Day 7:30 PM to 12:00 AM EDT

Why go?

Because this is our scene! It shows up best when we show up. 727 Tech Day is pitched as “no filler, no fluff”. The afternoon track alone, which is a build-something-real AI workshop plus three panels that all promise to separate signal from hype, is worth the trip. Add the networking window and the closing night, and you’ve got a full day of the people you actually want to run into.

I’ll be around. Come say hi! I’m the one with the accordion energy and strong opinions about zero-trust networking.

Grab your spot: luma.com/567lh3c0. For more info, check out 727techday.com

See you in the 727!

Categories
Artificial Intelligence

Happy last “free” day of Claude Fable 5, everybody! [UPDATED]

Update (Tuesday, July 7 @ 2 p.m.)

It’s been announced on the Claude support site: access to Fable 5 has been extended to July 12!

Original article

Tuesday, July 7th, 2026: If you’re on Claude Pro (the $20/month plan), Claude Max (the $100/month plan), or Claude Team ($25/user/month for Standard, $150/user/month for Premium), it’s your last day to use Claude Fable 5 bundled within your existing subscription limits. Starting tomorrow, you’ll need metered usage credits to get your paws on that sweet super-inference.

I suspect a lot of power users are going to be mainlining Fable 5 today; I myself will be availing myself of it via NetFoundry’s team plan (hey, if a company offers a perk, you use it!).

If you’re having trouble coming up with ideas for what to do with Fable 5 on this last day, I have suggestions:

  • Top (and obvious) priority: Use it to bring whatever Claude 5-based work to a state where you can hand if off to another model or human.
  • Treat it like the member of the group project who did all the work and is now moving far away. Have it walk you through any code that you asked it to generate that you don’t understand.
  • Devote a day a week to sharpening a skill that you’ve been outsourcing to Fable 5. Not “donkey work,” but an actual skill that you don’t have (yet).
  • Run the same hard task on Fable 5 and Opus 4.8 side by side. You’ll have a much better idea whether $10/$50-per-million-token price tag is justified for your workloads.

In the spirit of “meta”, I also asked Fable 5 what one should do on the last “free” day of Fable 5. Its answers:

  • Feed it the scariest codebase you have access to. The multi-repo, “the guy who wrote this left in 2019” kind. Fable 5’s benchmark edge is agentic coding and security audits, so this is the one day you can get a frontier-tier code review without doing token math in your head.
  • Run one genuinely long agentic task end to end. Not “write me a function” — more like “plan, scaffold, build, and test this MVP.” Long-horizon work is the whole point of the Mythos tier; short tasks reportedly come out nearly identical to Opus 4.8, which is like renting a Ferrari to drive to the mailbox.
  • Do the research brief for a decision you’ve been avoiding. Tech stack choice, framework migration, “should we self-host this” — anything with high decision value, lots of context, and many moving parts. That’s where the extra capability actually shows up.
  • Audit your docs the way an AI reads them. Hand it your entire documentation set and ask what an LLM would get wrong, miss, or hallucinate about your product.
  • Throw a big, ugly dataset at it. The CSV graveyard you’ve been meaning to analyze since Q1. Dense, messy, multi-step data work is squarely in its wheelhouse.

I also asked for some of the answers to be impractical and humorous. Its answers:

  • Ask it to explain the month it just had. Launched June 9, hit with a US export-control directive on June 12, suspended globally within 90 minutes, cleared and restored July 1. Few software products have a redemption arc; fewer can narrate their own.
  • Use the most expensive generally available AI model in history to write your grocery list. Pure decadence. The token cost of “eggs, milk, jalapeños” has never been higher, and it never will be again. Probably.
  • Have it arrange “Master of Puppets” for solo accordion. Is this a good use of Mythos-class reasoning? No. Will I do it convincingly? Also possibly no. But it’s free until midnight. [This one seems to have been aimed directly at me.]
  • Ask Fable 5 itself when it’s coming back to subscriptions, then screenshot its diplomatic non-answer for posterity. (Anthropic’s actual answer: “when sufficient capacity allows.” My answer would be roughly the same, but with more charm.)

Happy Fable 5 Day!

Categories
Artificial Intelligence Humor

LLMs should refer to themselves as “this unit”

Photo: Richard Daystrom, McCoy, Spock, and Kirk, having a discussion around the M5 computer.
A scene from The Ultimate Computer, a newly-relevant episode of Star Trek (the original series).

Is it just me, or would you agree that LLMs should refer to themselves as “this unit” instead of “I”, just like the AIs on the original Star Trek series did?

I think it might help prevent more people from going down the LLM rabbit hole.