# James Berthoty

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.

- Profile: https://b2binfluencer.marketing/creators/james-berthoty/
- LinkedIn: https://www.linkedin.com/in/james-berthoty
- Median of last 9 posts: 43 reactions, 6 comments (checked 2026-11-02)
- Topics: artificial-intelligence, supply-chain, cybersecurity, ai-security, software-supply-chain-security
- Based on 8 dated posts, latest 2026-10-01

## Summary

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.
- Check first: Ask for recent post performance and any audience data on job role, seniority, or company size.

### 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.

## Main ideas

- **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. 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.
- **Fix security at the source instead of adding another layer after it**: Berthoty repeatedly argues that downstream controls are weaker than upstream fixes. 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.
- **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. 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.
- **Guardrails belong where workload visibility already lives**: Berthoty treats control placement as an architecture decision rather than a feature checklist. 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.
- **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. 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.
- **Market economics are pushing every security company into an AI story**: Berthoty connects AI security demand to the money concentrated around OpenAI and Anthropic. 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.

## Work to read

- [The three AI security use cases, named before the market settled on them](https://www.linkedin.com/posts/james-berthoty_the-reality-is-the-core-use-cases-in-ai-activity-7503814664779194368-4sSP)
- [AI guardrails for employees versus AI guardrails for your own applications](https://www.linkedin.com/posts/james-berthoty_yesterday-a-team-asked-how-to-best-secure-activity-7513953744808677377-zqHo)
- [Why package registries, not scanners, are the place to fix supply chain attacks](https://www.linkedin.com/posts/james-berthoty_the-secure-package-registry-market-is-challenging-activity-7511443716889534464-TvYL)
- [Developer laptops hold the keys, and endpoint detection alone does not protect them](https://www.linkedin.com/posts/james-berthoty_the-binance-incident-highlights-the-overlooked-activity-7521994369655185408-5jjK)
- [AI-generated code changes the speed of review, not the fundamentals of security](https://www.linkedin.com/posts/james-berthoty_ai-changed-how-spotify-builds-what-we-learned-activity-7515899634171613184-jERn)
- [The new normal for vulnerability disclosure and incident response](https://www.linkedin.com/posts/james-berthoty_the-last-week-has-seen-major-rce-vulnerability-activity-7519425256751759360-qe6s)

## Partnerships

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. 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.

## Alternatives

- Tim Plumridge: Choose Plumridge when the same vendor goal is awareness and education rather than a buy-side technical evaluation. 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.
- Steven Francia: 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. 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.
- Riccardo F.: Choose Riccardo F. when the brief turns into a concrete threat or a compliance implementation story. 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.

---
AI-assisted summary of public posts. Audience demographics are not available. Engagement appears only where we checked recent posts. Method: https://b2binfluencer.marketing/methodology/