James Berthoty writes about cybersecurity, with a focus on AI security, software supply chains, and protecting developers and their tools. His posts explain security tradeoffs and offer practical guidance for security teams.
James Berthoty is useful for explaining AI security and software supply chain tradeoffs for security teams.
Best for
AI security or software supply chain vendors seeking a briefing or joint written piece.
Not for
Traditional endpoint detection and response vendors wanting co-branded content telling developers to install an agent.
Key takeaways
AI raises the speed of security work, not the fundamentals.
Fix security at the source instead of adding another layer after it.
Package registries, not scanners, are the place to fix supply chain attacks.
Check first: Ask for recent post performance and any audience data on job role, seniority, or company size.
Main ideas
AI raises the speed of security work, not the fundamentals · Fix security at the source instead of adding another layer after it · AI security use cases are still forming, and names should not outrun capability
James Berthoty writes about cybersecurity, especially AI security, software supply chains, and protecting developer tools and environments.
His posts explain how security teams can weigh competing approaches: for example, he distinguishes controls for employees using AI from protections for AI features built into products, where developer and runtime tools can show what an agent actually did.
The supplied work establishes these themes, but does not establish whether a book, show, business, or earlier work is also central to why people search his name.
Berthoty connects security claims to operational tradeoffs rather than treating tools as interchangeable.
In his AI security posts, he lays out three still-evolving use cases—securing the AI supply chain, enforcing runtime guardrails, and governing approved tools—and explains what each is meant to address.
In other posts, he argues that package security is stronger when protections reach maintainers and publishing workflows, and that AI-generated code raises the pace of review more than it changes security fundamentals.
This combination of market framing and concrete implementation questions makes his work useful to readers trying to understand what a security approach covers, what it misses, and where it fits.
James Berthoty writes about cybersecurity with a focus on AI security, software supply chains, and the security of developer machines.
Read more
Across the retained posts, a few positions repeat.
Berthoty argues that AI changes the speed of security work rather than its fundamentals, that security problems are best fixed at their source rather than with another layer of scanning, and that the AI security market is still forming, so use-case names should not run ahead of what tools can actually do.
Berthoty also treats where a control is deployed as a buying question: guardrails and endpoint protections work better when they sit where the workload or the developer tooling already is.
Guests and outside data are cited for support, not as Berthoty's own claims.
AI raises the speed of security work, not the fundamentals
Berthoty's central recurring claim is that AI-generated code is not inherently more insecure or lower quality than human-written code; defect and vulnerability rates are roughly the same, but the volume of new code has jumped sharply.
Read more
Security teams therefore need processes that keep pace, which Berthoty calls a second DevOps revolution.
The same frame reappears in coverage of a week of remote code execution disclosures: teams should already have been ready for supply chain breaches, fast patching, and credential rotation, and what AI changes is the speed and sophistication required.
Berthoty does not treat AI as a new category of risk so much as an accelerant applied to familiar ones.
In the Spotify post, Berthoty reads the company's engineering blog alongside GitHub data and names four developments that matter: AI static analysis with far fewer false positives and more useful findings; flexible pull request reviews that keep guardrails interactive and adjustable; AI-based software composition analysis reachability that scales function-level analysis and adds context; and threat models and security priorities written so agents can pull them in when needed. The closing point is adoption realism: failing pipelines on CVE scans will not scale.
The vulnerability-disclosure post applies the position to industry drama, stepping past arguments about Wiz's marketing, Chainguard's embargo miss, and Railway's incident to argue these episodes are the new normal and to offer preparation guidance instead of commentary.
Fix security at the source instead of adding another layer after it
Berthoty repeatedly argues that downstream controls are weaker than upstream fixes.
Read more
In the package registry post, providers differ only in details such as cooldown delays and malware scanning, and without upstream work scanners can be bypassed or marketplaces overwhelmed; the real fix is giving maintainers better tools and giving security teams better validation of which projects to trust.
The developer endpoint post makes the same move: instead of buying another detection layer, scope and minimize developer access to production, monitor their keys, and protect their workstations against phishing and malicious package installs.
The pattern is to change the conditions that let an attack succeed rather than to detect it later.
Berthoty walks through GitHub's npm maintainer tools as concrete upstream work: more flexible OIDC with a human verification step before a version publishes, which stops a compromised action from auto-publishing; publish-time malware scanning; a 72-hour hold on new versions after a recovery-code sign-in to blunt phishing; staging-only npm tokens that separate review from publishing; and a continued move to remove bypass-2FA tokens.
AI security use cases are still forming, and names should not outrun capability
Berthoty argues that the core AI security use cases are still in flight and that the field tends to coin acronyms before it understands the capabilities tools need to solve for.
Read more
Based on practitioner and buyer interviews, Berthoty names three: securing the AI supply chain, where MCPs and skills behave like packages and scripts, with defenses running from governance to runtime protection to removing tools altogether; enforcing runtime guardrails, which have shifted from blocking prompt injection toward baselining agent activity with small language models to catch deviations from an intended goal; and governing approved tools, the shadow AI problem of enforcing approved accounts, tools, and models on behalf of a governance committee. Each is presented as unsettled, with teams still deciding what to invest in.
Berthoty concedes the framing is a hot take while calling the market hot, and notes that needs are so new and undefined that teams are still working out what to buy and how it will hold up as new risks appear.
Guardrails belong where workload visibility already lives
Berthoty treats control placement as an architecture decision rather than a feature checklist.
Read more
Guardrail integrations from dedicated AI security vendors largely work through network inspection or API integration and concentrate on prompt injection, content filtering, and keeping agents on goal, but the same abilities now come from gateways, model providers, SDKs, and agent builders, which is why the options multiply.
For an organization's own application agents, Berthoty argues the better fit is developer tooling or cloud application detection and response, because those see consequences rather than prompts.
Deployment through an SDK or an existing runtime provider gives broader workload coverage and easier maintenance, while dedicated AI security providers offer an integrated policy engine and deeper red-teaming but are usually bought and run by IT rather than cloud or product security teams.
The distinction Berthoty draws is between seeing a prompt injection and seeing it lead to a workload takeover, or seeing a malicious MCP call and knowing which files it wrote to disk. Those consequences are visible to tools that already sit on the workload.
Developer laptops hold the keys, and EDR does not protect them
Reacting to the Binance incident, Berthoty argues that installing endpoint detection and response is not enough.
Read more
Developer endpoints rank behind only production environments and CI/CD runners in what they expose because they hold access keys to cloud infrastructure, yet teams grant them generous security-tool exemptions, since ordinary developer activity such as running code, starting processes, and touching registries and packages looks like attacker behavior. The recommendation is more granular visibility, control, and protection aimed at employee devices rather than a generic EDR replacement.
Berthoty points to investment that followed Palo Alto Networks' acquisition of Koi, naming startups Glow, Pluto Security, Neo, and Bloom Security alongside product security platforms Wiz, Upwind Security, Aikido Security, and Cycode as options that protect developer machines with fewer traditional productivity tradeoffs.
Market economics are pushing every security company into an AI story
Berthoty connects AI security demand to the money concentrated around OpenAI and Anthropic.
Read more
Hundreds of billions of dollars are going into data centers, with over a trillion dollars in compute committed and expectations of trillions in revenue, which forces every company, security vendors included, to define its place in the AI era.
Berthoty cites Steve Eisman's point that risk is concentrated in two companies, along with figures on how much hyperscaler AI revenue comes from those labs, as evidence that the pressure is structural rather than fashionable.
The conclusion is that every security company will present itself as an AI security company, whether or not the underlying shift arrives as promised.
Berthoty cites buyer demand for AI security rising from 8% to 37% in a single year, from Berthoty's own AI Security Report, and predicts 2027 will be the year every security company becomes an AI security company if it is not already. The Eisman observation and the revenue figures are attributed to their sources rather than presented as Berthoty's own measurements.
Start here if you need the vocabulary this person uses.
Read more
It is the clearest, most compact statement of how Berthoty splits the AI security market, and later posts build on it.
Berthoty argues the core AI security use cases are still in flight and that the field's habit of coining acronyms runs ahead of understanding the capabilities.
Based on practitioner and buyer interviews, the post names three: securing the AI supply chain, where MCPs and Skills behave like packages and scripts and defenses run from governance through runtime protection to removing tools entirely; enforcing runtime guardrails, which have moved from blocking prompt injection toward baselining agent activity with small language models to catch deviations from an intended goal; and governing approved tools, the so-called shadow AI problem of enforcing approved accounts, tools, and models on behalf of an AI governance committee.
Berthoty frames all three as unsettled, not settled, and says teams are still working out what to invest in and how it holds up as new risks appear.
For brands planning a campaign
This gives a vendor a ready-made three-part frame for a briefing or content collaboration. A vendor whose product covers only one bucket can say so directly and use the conversation to argue why its slice matters most; a vendor covering all three can ask Berthoty to pressure-test whether its packaging matches how buyers actually split the problem.
This is the best example of how Berthoty answers a live buying question.
Read more
It shows the reasoning he applies when a team is weighing two tools, not just which features exist.
A team asked whether the same tool should enforce AI guardrails across employee devices and first-party AI features in their own applications.
Berthoty separates the two cases.
Guardrail integrations from AI security vendors mostly work through network inspection or API integrations and focus on prompt injection, content filtering, and keeping agents on goal, but the same capabilities now come from gateways, model providers, SDKs, and agent builders, which is why the option list explodes.
For first-party application agents, he says most teams use developer tools or cloud application detection and response instead, because those see the consequences: a prompt injection that leads to a workload takeover, or an MCP call that writes files to disk.
Dedicated AI security providers offer an integrated policy engine and deeper red-teaming, he notes, but they are usually bought and run by IT rather than cloud and product security teams.
His recommendation is to treat first-party guardrails as part of the cloud and product security strategy and deploy through an SDK or an existing runtime security provider.
For brands planning a campaign
A vendor pitching an all-in-one AI security platform should expect this question and should be ready to explain who inside the customer runs it and what it sees at the workload level. For a briefing, this post is the natural opening for a discussion about where a product sits relative to developer tooling and runtime security.
Read this for a concrete example of a position Berthoty returns to: fix the source rather than add another layer after it.
Read more
It is also one of the few posts where he works through specific vendor features in detail.
The secure package registry market is hard to navigate because approaches differ in ways that carry real tradeoffs, Berthoty writes: some providers add only a cooldown delay, others add malware scanning, and other differences are smaller still.
His argument is that the real fix sits upstream, giving maintainers better tools and giving security teams better validation of which projects to trust, because otherwise scanners can be bypassed or marketplaces overwhelmed.
He then walks through GitHub's launch of maintainer tools for the npm ecosystem: more flexible OIDC including a human verification step before a version publishes, which stops a compromised action from auto-publishing; publish-time malware scanning; a 72-hour hold on new versions after a recovery-code sign-in to blunt phishing; staging-only npm tokens that separate review from publishing; and a continued move to remove bypass-2FA tokens.
For brands planning a campaign
This is the argument to meet or counter in a supply chain vendor briefing. A registry-level vendor can build on it; a scanner-based vendor should come prepared to explain bypass and marketplace-overload concerns on Berthoty's terms rather than avoid them.
This shows Berthoty connecting a public incident to a structural gap and then naming the vendors working on it.
Read more
It is the fastest way to see the developer security lane he tracks.
Reacting to the Binance incident, Berthoty argues that installing endpoint detection and response is not enough.
Developer endpoints rank behind only production environments and CI/CD runners in what they expose, because they hold access keys to cloud infrastructure, yet teams give them generous security-tool exemptions since normal developer activity, such as running code, starting processes, and touching registries and packages, looks like attacker activity.
He notes the investments that followed Palo Alto Networks' acquisition of Koi, listing startups Glow, Pluto Security, Neo, and Bloom Security alongside product security platforms Wiz, Upwind Security, Aikido Security, and Cycode as options that protect developer machines with fewer productivity tradeoffs.
His prescription: scope and minimize developer access to production, monitor their keys, and protect their workstations against phishing and malicious package installs.
For brands planning a campaign
The vendor list here is a map of the competitive field in developer endpoint security, and Berthoty's framing sets the bar any new entrant has to clear: fewer traditional productivity tradeoffs plus real visibility into keys and installs. Useful for positioning a briefing around incident response or developer risk.
Read this if you want Berthoty's view on reviewing AI-written code.
Read more
It is a close reading of another company's engineering blog with a clear, testable set of implications.
Working from a Spotify engineering blog and GitHub data, Berthoty argues that AI's contribution to security and quality problems is not that generated code is inherently worse, but that defect and vulnerability rates are roughly the same as human-written code while the volume of new code has jumped sharply.
Security processes have to keep up, which he calls a second DevOps revolution.
He highlights four developments: AI static analysis with far fewer false positives and more useful findings than traditional tools; flexible pull request reviews that make guardrails interactive and adjustable; AI-based software composition analysis reachability that scales function-level reachability beyond hand-built detections and adds context; and threat models and security priorities written so agents can pull them in when needed.
His closing point is adoption realism: failing pipelines on CVE scans will not scale.
For brands planning a campaign
A vendor selling AI-assisted review, SAST, or SCA gets a specific, quotable frame here: same rate, higher velocity, and tooling that must fit developer habits. It is a good anchor for a joint piece on review workflows rather than a general AI security pitch.
Read this for how Berthoty handles a week of industry drama without joining it.
Read more
It is an example of turning several incidents into practical preparation guidance.
After a run of remote code execution disclosures and security incidents involving open and closed source providers, Berthoty steps back from the community arguments about Wiz's marketing, Chainguard's embargo miss, and Railway's incident to argue that these episodes are the new normal, with core definitions and expectations shifting under AI and private initiatives.
The post covers what the new normal of disclosure means and gives security teams practical guidance for an increase in vulnerability and incident discovery.
His conclusion is deliberately unflashy: AI does not change the fundamentals, teams should already have been ready for supply chain breaches, fast patching, and credential rotation, but the speed and sophistication required have changed.
For brands planning a campaign
This is a natural hook for a crisis-response or vulnerability-management offering, and a reminder that Berthoty's value in a briefing is context and preparation guidance rather than commentary on the day's controversy. A vendor should bring a concrete preparation workflow for him to examine.
Berthoty outlines three core AI security use cases drawn from practitioner and buyer interviews: securing the AI supply chain, such as MCPs and skills; enforcing runtime guardrails by baselining agent activity and looking for deviations from intended goals; and governing approved tools, sometimes called blocking shadow AI.
Read more
The post warns against creating new acronyms before the market understands the capabilities and use cases tools need to solve for.
Berthoty frames the three use cases as provisional and based on interviews, not settled market categories.
For brands planning a campaign
A vendor can use these three buckets to structure an analyst briefing or content collaboration: supply chain protection, runtime guardrails, and approved-tool governance. The stronger pitch maps specific product capabilities to those jobs rather than making a general AI security claim.
Guardrails for employee devices versus first-party AI features
Berthoty describes a common buyer question: whether the same tool should enforce AI guardrails across employee devices and an organization's own AI features.
Read more
The post separates options including dedicated AI security vendors, AI gateways, frontier providers, SDKs, agent builders, developer tools, and cloud application detection and response.
Berthoty suggests first-party AI guardrails are usually better treated as an extension of cloud or product security, often deployed through an SDK or an existing cloud runtime security provider, because those tools have broader workload visibility.
Dedicated AI security providers offer an integrated policy engine and deeper AI red-teaming, but are often managed by IT rather than cloud or product security teams.
Berthoty notes the right choice depends on goals, architecture, and understanding why feature overlaps exist.
For brands planning a campaign
Vendors should be clear about the buyer and deployment path.
Employee-use guardrails may sit with IT; first-party application guardrails often sit with developer and cloud security budgets.
A briefing should address integration model and workload-level visibility, not just prompt-injection coverage.
Runtime guardrails are shifting from prompt injection to agent behavior
In the AI security use-case post, Berthoty says runtime guardrails historically focused on preventing prompt injection, but have shifted toward baselining agent activity and detecting deviations from an agent's intended goal using small language models.
Read more
The goal is to prevent agents from taking unintended actions in an environment. The employee-device post adds that guardrails commonly cover prompt injection, content filtering, and aligning agents to their goals.
For brands planning a campaign
A vendor should show whether its product blocks known bad prompts, detects abnormal agent behavior, or both. For content and analyst briefings, agent-activity baselining is a more differentiated capability claim than generic prompt-injection filtering.
Berthoty argues that the secure package registry market is hard to navigate because providers differ in cooldown delays, malware scanning, and other technical approaches.
Read more
The real fix, in this view, is upstream: giving maintainers better tools to protect projects and giving security teams better validation of which projects are trusted. The post highlights GitHub's NPM maintainer tools, including more flexible OIDC with a human verification step before publishing, publish-time malware scanning, a 72-hour hold after recovery-code sign-in, staging-only NPM tokens, and continued removal of bypass-2FA tokens in January.
Berthoty notes that without upstream fixes, malware scanners can be bypassed or marketplaces overwhelmed.
For brands planning a campaign
Supply chain offerings should speak to both maintainer-side protections and buyer-side validation. Concrete controls such as publish-time scanning, OIDC changes, token staging, and publishing holds carry more weight than a broad claim about stopping package attacks.
Berthoty uses the Binance incident to argue that installing EDR is not enough.
Read more
Developer endpoints are described as holding cloud access keys and ranking behind only production environments and CI/CD runners in importance.
Security tools often grant these endpoints generous exemptions because developer activity can resemble threat-actor activity through running code, starting processes, and changing registries and packages.
The post lists companies investing in protecting developer machines, including Koi at Palo Alto Networks, Glow, Pluto Security, Neo, Bloom Security, Wiz, Upwind Security, Aikido Security, and Cycode, and recommends more granular visibility, control, and protection for employee devices.
Berthoty identifies a competitive set and recommends controls rather than a single product category.
For brands planning a campaign
Endpoint or platform security vendors can target the developer-machine gap rather than a generic EDR replacement. Messaging should lead with reducing productivity tradeoffs while protecting access keys, scoping developer production access, monitoring keys, and preventing phishing and malicious package installs.
AI-generated code and the second DevOps revolution
Berthoty reads a Spotify engineering blog as reflecting broader industry news about security and quality incidents in AI-generated code.
Read more
The core argument is that AI code is not necessarily more insecure or lower quality than human code; the rates are similar, but the velocity of code generation has increased dramatically.
Security teams therefore need to adapt processes.
The post names four developments: AI SAST with fewer false positives and more impactful findings; flexible PR reviews with elastic organizational guardrails; AI-based SCA reachability that scales function-level analysis; and threat models and security priorities designed to be accessible to agents.
Setting up pipeline failures on CVE scans will not scale.
For brands planning a campaign
Vendors can connect AI code security to workflow fit: false-positive reduction, interactive PR review, reachability analysis, and agent-accessible policy. Avoid the broad claim that AI writes insecure code; the more credible angle is helping security keep up with shipping velocity.
Market economics are pushing every security company into AI security
Berthoty ties AI security demand to the broader economy around OpenAI and Anthropic.
Read more
The post describes hundreds of billions of dollars going into data centers, over a trillion dollars in committed compute, and expectations of $3 trillion in revenue over four years.
Berthoty cites Steve Eisman's point that risk is concentrated in two companies and notes that about 70% of hyperscalers' AI revenue comes from those two labs.
The implication is that every company, including security vendors, is being pushed to define its place in the AI era.
Berthoty says buyer demand for AI security jumped from 8% to 37% in a single year and predicts 2027 will be the year every security company becomes an AI security company.
For brands planning a campaign
AI security is becoming table stakes, so vendor differentiation should focus on buyer demand and concrete use cases rather than simply having an AI story. Category-education content can use the demand shift to explain why specific capabilities matter.
Berthoty contextualizes a week of major RCE vulnerability disclosures and incidents, including reactions to Wiz's marketing approach, Chainguard's embargo miss, and Railway's security incident.
Read more
The argument is that these moments represent a new normal as core definitions and expectations change in light of AI and private initiatives.
The accompanying post covers what the new normal of vulnerability disclosure means and gives practical guidance for security teams to prepare for more vulnerability and incident discovery.
AI does not radically transform the fundamentals, in this view: teams should already be prepared for supply chain breaches, rapid patching, and credential rotation, but AI changes the speed and sophistication teams need to handle.
For brands planning a campaign
Vendors can avoid fear-based AI marketing and instead sell preparedness: supply chain breach readiness, faster patching, credential rotation, and incident response. An analyst briefing can tie product value to vulnerability and incident workflows rather than an abstract AI threat.
No sponsorship, employment, client, affiliate, investment, or owned-business relationship is stated in the retained posts.
Read more
Companies such as GitHub, Spotify, OpenAI, Anthropic, Oracle, Binance, Wiz, Palo Alto Networks, and others appear as industry examples or subjects of commentary, not as disclosed commercial relationships.
James Berthoty is worth following if you want a working view of how AI is changing security practice rather than a vendor pitch about it.
Read more
The most useful entry point is the post that names three emerging AI security use cases, because it sets up the vocabulary Berthoty uses elsewhere.
From there, read the two posts on guardrails and on software supply chains to see how Berthoty separates where a control is deployed from what it claims to block, then the developer endpoint post for the argument that laptops holding cloud keys need more than endpoint detection.
The market and vulnerability-disclosure posts show how Berthoty connects those practitioner problems to the economics pushing every security company into an AI story.
Follow for concrete controls, named alternatives, and a habit of fixing security at the source instead of adding another scanner.
Plumridge also writes practical cybersecurity guidance on LinkedIn, turning a specific incident or prediction into a short checklist a reader can act on.
Read more
The scam-call post walks through who is calling, why older people are targeted, and five concrete steps, which is the same format Berthoty uses for package registry and endpoint controls.
Plumridge aims at the general public and personal safety, covering phone scams, passwords, phishing links, and zero-trust predictions for ordinary users and their families. Berthoty writes for security teams, developers, and buyers, discussing AI use cases, workload visibility, and how security tooling should be deployed.
Francia shares Berthoty's view that software supply chain security is best addressed at the source, around maintainers and foundational projects.
Read more
The post about Cobra and Viper joining the GitHub Secure Open Source Fund covers threat modeling, secure supply chain management, incident response, and tooling, which matches Berthoty's argument that maintainer-side protections beat downstream scanning.
Francia writes from the maintainer and programming-language side, drawing on leading the Go team and on running widely used open source projects, and frames security as part of language and ecosystem design. Berthoty writes from the practitioner and buyer side, mapping the AI security market, tooling categories, and what security teams should deploy.
Riccardo also gives technical practitioners concrete, checklist-style security guidance.
Read more
The developer job scam post lays out the recruiter bait, the private repository, the install step, and the indicators of compromise, and the healthcare post gives a numbered architecture blueprint, both of which read like Berthoty's numbered lists of controls and named alternatives.
Riccardo focuses on web and Web3 developers and on HealthTech compliance work such as the NHS Data Security and Protection Toolkit and ISO 27001, often around a specific client engagement. Berthoty focuses on enterprise AI security, software supply chains, and how security tooling and markets are developing.
Placement decision: the supplied evidence gives a clear yes on topic alignment and one reach figure, but not enough to judge whether a cybersecurity vendor's actual buyers sit in this audience.
Read more
Berthoty's LinkedIn following stood at 22,358 on 8 October 2026.
That is a reach number, not a composition number.
The seven supplied posts show what that following is being asked to engage with: the three AI security use cases Berthoty proposes (securing the AI supply chain, runtime guardrails, governing approved tools), the secure package registry market and GitHub's maintainer tooling, developer endpoint security after the Binance incident, and agent-native code review.
A vendor selling AI security or software supply chain products is asking for attention on ground this creator already covers repeatedly, which is the strongest audience argument in the packet.
What the evidence cannot answer is who is listening.
No geography, age, gender, employer, job function, seniority, or company-size data was supplied, and neither was engagement or impression data for any post.
Different accumulated views, if they existed here, would not establish who viewed or why.
Follower count alone does not verify that followers are security practitioners, and it says nothing about whether they hold budget or evaluation responsibility.
Concrete next step before committing to a collaboration or analyst briefing: ask for recent performance on posts closest to your brief — the AI security use case taxonomy, supply chain and package registry coverage, and developer endpoint security — over a comparable time window, and ask whether an audience survey or any documented source covers job role, seniority, or company size.
Those requests answer the professional-attribute question; follower demographics would not.
The seven reviewed LinkedIn posts explain cybersecurity ideas and cite outside articles, but do not describe sponsored content, partnership formats, deliverables, or a partnership inquiry route.
Read more
They provide no basis for planning a specific collaboration; brands would need to ask James Berthoty directly. This does not establish that he never accepts partnerships.
Yes for the brief on file, with one condition: pitch a briefing or a joint written piece against named use cases, not a general sponsorship.
Read more
The vendor wants to position AI security and software supply chain offerings.
That is the ground Berthoty already covers.
The clearest anchor is the post where they name three core AI security use cases drawn from practitioner and buyer interviews: securing the AI supply chain, where MCPs and skills behave like packages and scripts; enforcing runtime guardrails, which they say have moved from blocking prompt injection toward baselining agent activity with small language models to catch drift from an agent's intended goal; and governing approved tools, the shadow-AI problem of enforcing approved accounts, tools, and models.
They mark all three as unsettled rather than settled, and warn against coining acronyms before the market knows what the tools must do.
That is unusually useful for a vendor: it is a ready-made spine for a briefing, and it invites the vendor to say which of the three it actually covers.
The second asset is that Berthoty answers live buying questions rather than restating product categories.
In one post a team asked whether the same tool should enforce guardrails on employee devices and on first-party AI features.
The answer separates the two cases, lays out where guardrails come from (dedicated AI security vendors, gateways, model providers, SDKs, agent builders, developer tools, cloud detection and response), recommends treating first-party guardrails as an extension of cloud and product security deployed via an SDK or existing runtime provider, and notes that dedicated AI security tools usually offer a stronger integrated policy engine and deeper red-teaming but are typically bought and run by IT rather than cloud or product security teams.
A vendor prepared to be questioned on buyer, deployment path, and workload-level visibility will get a substantive conversation.
A vendor with a one-line 'we do AI security' claim will not.
The supply chain half of the brief has an equally specific hook.
Berthoty argues the secure package registry market is hard to navigate because approaches differ in real ways, and that the real fix sits upstream, giving maintainers better tools and giving security teams better validation of trusted projects, because otherwise scanners get bypassed or marketplaces get overwhelmed.
They then work through GitHub's npm maintainer features in detail.
A registry-level or maintainer-side vendor can build on that argument; a scanner-based vendor should arrive ready to defend itself on Berthoty's terms rather than avoid them.
Two limits belong in the decision.
First, the fit argument rests on topic alignment and one reach figure, a LinkedIn following of 22,358 observed 8 October 2026.
Who those followers are, and whether they hold budget or evaluation responsibility, is not established by the evidence reviewed.
Second, no partnership formats or inquiry route are documented in the reviewed material, so the practical first step is direct contact and a request for recent performance on the posts closest to this brief, not a proposal built on assumed formats.
When to choose a specialist
No for a traditional endpoint detection and response vendor that wants a co-branded piece telling developers to install its agent.
Read more
Berthoty's position on that category is already stated and it cuts against the pitch.
Reacting to the Binance incident, they argue that installing EDR is not enough.
Developer endpoints rank behind only production environments and CI/CD runners in what they expose, because they hold cloud access keys, yet teams give those machines generous security-tool exemptions since normal developer activity, running code, starting processes, and touching registries and packages, resembles attacker activity.
The prescription is narrower and different: scope and minimise developer access to production, monitor their keys, and protect workstations against phishing and malicious package installs.
A vendor whose message is that its agent closes the gap would be arguing against the creator's stated view in the creator's own channel.
The realistic version of that collaboration, if it exists, is the vendor submitting a workload-visibility or key-monitoring workflow for Berthoty to examine, which is a smaller and more technical piece than an EDR demand-generation post.
The same pattern rules out two adjacent pitches.
A vendor selling AI coding assistance purely on speed and developer experience has no purchase in this material: Berthoty treats AI-generated code through security process, arguing that defect and vulnerability rates are roughly the same as human-written code but that volume has jumped sharply, which they call a second DevOps revolution, and they point to AI static analysis with fewer false positives, flexible pull request review, reachability analysis, and agent-readable threat models.
That is a security-workflow conversation, not a productivity-message one.
A fear-led 'AI writes insecure code' campaign fails for the opposite reason: Berthoty explicitly rejects that framing.
One further caution applies to any of these.
Because the reviewed material documents no partnership formats and no inquiry route, and gives no audience composition data, a vendor in a mismatched category cannot be rescued by proposing an unusual format.
The mismatch is in the argument, not the packaging.
A worked campaign example
Brief: an AI security and software supply chain vendor wants Berthoty to help position its offering and map its capabilities to the three AI security use cases.
Angle: a two-part collaboration.
First a paid analyst-style briefing, roughly an hour, with a written pre-read.
Then, if the briefing holds up, one joint written piece published by the vendor and shared by Berthoty, framed as a capability map against the three jobs rather than a product announcement.
Pre-read the vendor sends Berthoty, kept to about four pages. For each of the three use cases (securing the AI supply chain, runtime guardrails, governing approved tools) the vendor states: which one or ones it covers; the buyer who signs, IT or cloud and product security; how it is deployed, standalone platform, SDK, or through an existing runtime or developer tool; what it sees at workload level; and two concrete capabilities with evidence, such as publish-time scanning, a holding period before a version goes live, or activity baselining that flags deviations from an agent's stated goal.
Briefing agenda, about an hour.
Ten minutes for Berthoty to restate the three use cases as they defined them and note which remain unsettled.
Twenty-five minutes for the vendor to walk the pre-read, capability by capability, with one live example or demo per claim.
Twenty minutes of pressure-testing, where the vendor should expect three questions drawn from Berthoty's own published positions.
Where does this sit for a team deciding between a dedicated AI security provider, an SDK deployment, and an existing cloud runtime security tool, and who inside the customer runs it.
What is the difference between blocking a known bad prompt and catching an agent drifting from its goal.
For the supply chain claim, why this approach survives the bypass and marketplace-overload problem they raised against scanner-only tools.
Fifteen minutes to agree the shape of the written piece, or to conclude that a briefing note is the right and sufficient output.
The vendor must bring a named practitioner, not a marketing lead, and one honest limitation per use case.
If the product covers only runtime guardrails, the vendor says so in the first ten minutes.
That honesty is what makes the written piece credible, and it is also how the vendor gets the argument that its slice matters most.
Written output: 1,200 to 1,600 words under both names.
Structure: what buyers are actually trying to solve, the three jobs in plain terms, which job this product addresses and how, where it sits relative to the alternatives a team is already weighing, the honest boundary, and a short checklist a security team can run this week.
Berthoty supplies the buyer framing and the pressure-test; the vendor supplies product specifics and approves nothing that overstates coverage.
What success looks like six weeks later: the vendor can point to inbound conversations that name one of the three use cases in their own words, and Berthoty's post carrying the piece gets substantive practitioner replies rather than vendor-boosting engagement.
Two open items shape the next step.
Audience composition is unverified, so before any paid commitment the vendor should request recent performance on the posts closest to this brief and ask whether any survey or documented source covers job role, seniority, or company size.
No partnership formats or inquiry route are documented, so this has to be proposed directly rather than chosen from a rate card.
Choose Plumridge when the same vendor goal is awareness and education rather than a buy-side technical evaluation.
Read more
For a campaign built on plain-language protection advice, the reviewed posts show a working format: a first-person account of a scam call, followed by five numbered steps (verify the caller, use strong passwords, think before clicking, check links, keep devices updated) written for a general audience, including older relatives.
For a seasonal or prediction-led piece, the second post shows a "what awaits in 2024" structure that flags AI as a double-edged sword, walks through AI-assisted phishing and deepfakes, and lands on zero trust.
A vendor whose message is phishing resistance, employee awareness, or digital-wellbeing would be speaking in the register this material already uses, and could reuse the step-by-step shape directly.
The depth is shallower against the same vendor brief.
The reviewed posts stay at general advice and prediction level: they do not discuss the three AI security use cases the brief turns on, agent runtime guardrails, package registry mechanics, or how a security team picks between a dedicated AI security platform, an SDK, or an existing cloud runtime tool.
A vendor positioning an AI security or supply chain platform would get reach into a generalist audience instead of practitioner pressure-testing, and no equivalent to Berthoty's buyer-demand figure or use-case framework.
The subject matter that makes the brief substantive is absent from what was reviewed.
Choose Francia when the supply chain half of the brief is the whole brief and the audience is developers and maintainers rather than security buyers.
Read more
The reviewed material gives maintainer-side credentials that are hard to manufacture: Cobra and Viper were selected for the GitHub Secure Open Source Fund, the post names the training the program covered (threat modeling, secure supply chain management, incident response, CodeQL, Dependabot), and it names downstream dependents including Kubernetes, Docker, Hugo, and GitHub CLI plus Cobra and Viper users inside the same program.
The second post extends that into a language-ecosystem argument, contrasting Go's integrated security tooling and curated module system with an npm ecosystem described as vast but carrying deprecated, insecure, and abandoned packages.
A vendor selling dependency security, secure defaults, or maintainer tooling gets a credible voice with named projects behind it, and a ready argument about where supply chain risk actually sits.
The framing is open-source project security and language economics, not commercial AI security platform selection.
The reviewed posts do not evaluate vendors, buying committees, or the AI use cases in the brief, and the audience leans toward Go developers and maintainers rather than the security and product teams who sign AI security contracts.
A vendor with an AI security platform would have to restate its offering in dependency and ecosystem terms to fit this creator's demonstrated range, and the reviewed material offers no market-demand or buyer evidence to support a positioning claim.
Choose Riccardo F. when the brief turns into a concrete threat or a compliance implementation story.
Read more
The first post is a developer-targeted malware alert with the full playbook spelled out: the recruiter lure and inflated rate, the demand to review a private repository, the npm install payload, typosquatted dependencies, the requested screenshot, and named indicators (a fake recruiter name, a GitHub username, a repository name), closing with sandbox and cloud-development-environment advice.
For a vendor whose message is developer-targeted supply chain attacks, that is a ready-made worked example with defensive instructions.
The second post supplies the regulated-industry lane: an NHS DSPT and ISO 27001 blueprint built on a logical air-gap between research compute and the corporate network, encrypted sync of model weights to WORM storage, and identity-first controls with MFA and device health checks, framed as a 12-week path from non-compliant to audit-ready.
A vendor selling into healthtech or another audited sector gets an architecture-level hook that Berthoty's market-level posts do not provide.
Both posts run in an advisory or checklist register aimed at developers and healthtech staff, so a vendor positioning across the whole AI security landscape is confined to one threat pattern or one sector.
There is no category-level analysis, no buyer-demand data, and no equivalent to the three-use-case framework the brief asks to map against.
Identity-first architecture and scam-alert formats also carry less weight with a buyer comparing platforms than with a practitioner looking for an implementation checklist.
Seven LinkedIn posts by James Berthoty were read in full for this profile, covering AI security use cases, guardrails for employee devices and first-party applications, software supply chain and package registries, developer endpoint security, AI-generated code review, market demand for AI security, and vulnerability disclosure.
The account snapshot dates to 8 October 2026.
The posts carry no publication dates in the material reviewed, so the development of these positions over time cannot be placed in order.
Three other creators — Tim Plumridge, Steven Francia, and Riccardo F. — were reviewed from two posts each to support the similar-creator comparisons.
No transcripts, talks, longer articles, or partnership formats for Berthoty were supplied, and the reviewed material does not establish whether a book, show, business, or earlier career work is also central to why people search the name.
That gap in name-search coverage of off-LinkedIn work is flagged rather than filled.
The campaign-fit and partnership sections work from topic alignment and stated positions; audience composition beyond a follower count, engagement, and reach data were not available in the reviewed material.
Recent engagement
Across their last 9 LinkedIn posts, the median post got 43 reactions and 6 comments. Checked 2026-11-02.
