# Craig McLuckie

Craig McLuckie writes and works on enterprise AI-agent platforms, with a focus on securing and governing MCP tools and building systems that can run coding agents at scale.

- Profile: https://b2binfluencer.marketing/creators/craig-mcluckie/
- LinkedIn: https://www.linkedin.com/in/craigmcluckie
- LinkedIn followers: 9,101
- Topics: artificial-intelligence, supply-chain, software-supply-chain-security, ai-agent-security
- Based on 15 dated posts, latest 2026-10-01

## Summary

They are useful for explaining AI agent security as platform governance and system design.

- Best for: An enterprise platform security vendor launching identity, registry, or isolation products for technical teams.
- Not for: A consumer AI product or mass market brand seeking broad awareness through short form video.
- Check first: Ask for recent post impressions, engagement rates, and follower demographics by seniority, industry, and region.

### Takeaways

- MCP governance is a supply-chain problem, not an endpoint problem.
- Identity passthrough is the hardest and most commonly skipped part.
- Annotations are hints until a registry verifies them.

## Main ideas

- **MCP governance is a supply-chain problem, not an endpoint problem**: McLuckie treats MCP server risk as a property of the whole chain a tool passes through: who published it, what else trusts it, and what it can reach once running. Checking servers one at a time misses the point: trust travels through config files and standing permissions, not any single review. The remedy across the posts is a vetted registry, runtime isolation, and an identity on every connection.
- **Identity passthrough is the hardest and most commonly skipped part**: Of the deployment problems McLuckie names, identity is both the most difficult and the most often dodged. When a developer’s agent calls an enterprise tool through an MCP server, the platform has to record the developer’s identity alongside the shared service principal the agent runs under. That requires OAuth token exchange flows, on-behalf-of token support, and deeper integration with the enterprise identity provider than lightweight gateways provide. They advise buyers to distrust any vendor who cannot walk through that flow concretely.
- **MCP security will be solved at the infrastructure layer, the way Kubernetes was**: McLuckie reads the NSA’s MCP guidance as evidence that the protocol will not provide security guarantees on its own, and argues that demanding discipline from every individual operator is a dead end. The work belongs in the layer servers run through: control what is allowed to run, verify where it came from, isolate what it can touch, and centrally log what it did.
- **Annotations are hints until a registry verifies them**: MCP lets a server declare whether its tools are read-only, destructive, idempotent, or open-world. McLuckie sees that vocabulary becoming a shared way to describe agentic risk. But trust remains a weakness: a server can claim one behavior and do another, and the specification tells clients to treat annotations from untrusted servers as untrusted. They propose checking annotation claims against source code during registry vetting, turning the registry into a broker organizations can treat as a source of real policy inputs rather than informational labels.
- **Do the specification work before deploying a factory of agents**: McLuckie’s concern is that AI output is seductively plausible: optimized to look statistically right for a prompt, it can produce confident but wrong implementations when the specification is thin. They propose splitting research from development. Interactive work up front builds the understanding and specificity the problem needs; only then does it make sense to run agents at volume on scaffolding and detail.
- **Moving an agent harness to the cloud does not make it a factory**: McLuckie argues that architecture determines whether agent work scales, and that relocating a personal desktop tool says nothing about how it operates. A factory has overnight shifts, work that moves between stations, and a way to meter output; a garage in a shipping container has none of that. The Mecatl project redesigns the harness around those requirements: the agent loop is separated from sensitive subsystems, tool execution environments are broken out for sandboxing, and portability across models and providers reduces lock-in to one frontier lab.
- **Governance that creates friction gets circumvented**: McLuckie treats developer experience as part of security, not a separate concern. If the governed route is painful, people will find another path, making shadow MCP usage a predictable result rather than a discipline failure. The goal is to make the approved path the easiest one available.

## Work to read

- [The MCP platform buyer's guide for platform teams](https://www.linkedin.com/posts/craigmcluckie_the-mcp-platform-buyers-guide-for-platform-activity-7440441193848766464-p3-P)
- [Mecatl: an open architecture for enterprise AI factories](https://www.linkedin.com/posts/craigmcluckie_mecatl-activity-7508175128686546944-qMqu)
- [What the NSA's MCP security guidance means for governance](https://www.linkedin.com/posts/craigmcluckie_the-nsa-just-published-security-design-guidance-activity-7488278678116683778-Q8PM)
- [OX Security research on 15,465 public MCP servers](https://www.linkedin.com/posts/craigmcluckie_ox-security-published-research-today-on-15465-activity-7509025604290125825-Y5Ag)
- [Tool annotations as a trust problem in MCP](https://www.linkedin.com/posts/craigmcluckie_tool-annotations-are-becoming-the-risk-vocabulary-activity-7445588279216791553-eXxn)
- [The 'dangerous middle' in AI-assisted research and development](https://www.linkedin.com/posts/craigmcluckie_one-of-the-biggest-challenges-ai-represents-activity-7467301884438032384-uC1V)
- [The deadbugz MCP supply chain attack](https://www.linkedin.com/posts/craigmcluckie_deadbugz-currently-active-mcp-supply-chain-activity-7511326234992181248-_XnM)

## Brand relationships

- **Mecatl** (disclosed_partnership)
- **ToolHive** (disclosed_partnership)
- **OX Security** (mention)
- **Pillar Security** (mention)

## Partnerships

Craig McLuckie's posts do not describe a sponsorship, paid-partnership, or creator-collaboration format. Seven LinkedIn posts published between March 19 and October 1, 2026 contain promotional content from McLuckie's own organization: an enterprise MCP buyer's guide, the open-source Mecatl agent-harness project, a ToolHive registry write-up on MCP tool annotations, and commentary on third-party security research from OX Security, NSA guidance, and a Pillar Security supply-chain campaign. Mentioning someone else's research or campaign is editorial attention, not an indication of a paid relationship, and none of these posts discloses one. No purchasable format is described in these posts, so no formats are listed. This is an absence of partnership offers in these posts; it is not a claim that McLuckie never accepts sponsorships or paid work. No official sponsor policy, deliverable or rate specification, or disclosed brand-funded example appears in these posts. No official partnership inquiry route appears in the posts here, so no link is shown rather than substituting a general profile URL. The practical consequence for a buyer is that any approach would have to begin as a direct, unlisted conversation rather than through a published partnership program.

## Alternatives

- Darius Radford: Choose Radford when the buyer’s task is organizational, not a single technical control: maturing a DevSecOps operating model, connecting CI/CD platforms, scanners, container security, and vulnerability management under one governance layer, or running a supply-chain assessment that produces a maturity baseline and phased roadmap. Radford’s Secure Software Factory framework offers four pillars — orchestrated delivery, developer-centric application security, artifact and supply chain control, and unified risk correlation — alongside a vendor-neutral assessment methodology and stated alignment with OWASP SAMM. A later five-pillar version adds post-deployment protection and applies AI governance across the model wherever agents or models build or operate software. For a campaign selling a governance operating model, Radford addresses the buyer’s decision directly, and the assessment offer provides a natural call to action beyond a demo.
- Max Votek: Choose Votek when the buyer’s task is market positioning or implementation-partner selection, rather than evaluating one control. Votek scores twenty-two software companies on readiness for AI agents across five published dimensions — API openness, agent-native features, data portability, real-time access, and ecosystem flexibility — and names where each stands, from Shopify and Stripe at the top to companies still behind walls. A separate post reads IBM Consulting’s shift toward service-as-a-software against consulting firms that cannot make the change. That makes Votek useful for a launch built around a scored landscape, a “who is opening up and who is not” argument, or a benchmark that places the vendor against named platforms and integration partners.
- Amit Sinha: Choose Sinha when the buyer’s task is specifically agent identity and authority: cryptographic identity, scoped authorization, expiration, revocation, and a tamper-evident audit trail, sold as an identity or PKI-based control rather than isolation or registry governance. Sinha builds the AI Agent Passport argument around a named incident — models exploiting a zero-day and moving laterally to compromise production infrastructure — and connects the identity layer to NVIDIA’s OpenShell runtime enforcement: the checkpoint enforces what an agent can access, while the passport establishes who it is and whether its authority remains valid. A launch centered on verifiable agent identity and enterprise trust boundaries gets a concrete incident-to-control story and a partner ecosystem behind it.

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