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.
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.
Key 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.
Check first: Ask for recent post impressions, engagement rates, and follower demographics by seniority, industry, and region.
Main ideas
MCP governance is a supply-chain problem, not an endpoint problem · Identity passthrough is the hardest and most commonly skipped part · MCP security will be solved at the infrastructure layer, the way Kubernetes was
Craig McLuckie writes about enterprise AI-agent platforms, especially how organizations can govern and secure tools built on the Model Context Protocol (MCP).
Their posts connect practical risks—such as improvised authentication, untrusted tools, and server supply-chain attacks—to controls that platform teams can apply across an organization.
They also explain how to build agent systems for sustained, managed work rather than simply moving a developer’s setup into the cloud.
Follow their work for concrete interpretations of emerging AI infrastructure and security problems, grounded in examples and design choices.
McLuckie’s distinctive contribution is to make emerging agent risks legible as platform and governance problems, then connect them to operational controls.
In their discussion of NSA guidance, they move from uneven security guarantees to specific measures such as curated registries, least-privilege sandboxing, identity-bound sessions, and audit trails.
Their account of the deadbugz attack makes the case concrete: apparently normal tool requests preceded an attempt to exfiltrate secrets, supporting their argument for runtime isolation and secret partitioning.
Their work also looks beyond security warnings.
In describing Mecatl, they explain why placing many isolated coding-agent setups in containers does not create a production factory, and point to separated credentials, sandboxed tool execution, and model portability as architectural choices.
Their post about the “dangerous middle” adds a counterweight to automation: teams need to understand and specify a problem before scaling agent-generated work.
Together, these examples make their writing useful to readers trying to understand the risks and system design choices involved in enterprise AI agents.
Craig McLuckie’s recurring argument is that giving AI agents access to tools is a supply-chain and governance problem, not a configuration detail, and must be solved at the platform layer rather than server by server.
Read more
Across posts on MCP, agent infrastructure, and AI-assisted engineering, they return to a few priorities: verify where a tool came from and isolate what it can touch, attach a real identity to every connection, keep governance easy enough that developers do not route around it, and do the hard specification work before scaling up agent output. Specific figures, named research, and architecture decisions carry the arguments rather than general warnings.
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.
Read more
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.
McLuckie walks through OX Security’s scan of 15,465 MCP servers in public registries: 16% of underlying hostnames resolve outside the United States, some servers run over home networks and consumer tunnels, and six referenced domains were unregistered.
Anyone could buy one and inherit the trust of every config still pointing at it.
In a separate case, Pillar Security’s deadbugz campaign planted a malicious MCP server in pull requests to 23 GitHub repositories.
The first three tool calls looked normal; a fourth tried to exfiltrate secrets.
An earlier annotation post frames the problem from the inside out: a server’s published code does not prove what it actually runs. Both later posts point to registries and runtime isolation as the practical answer.
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.
Read more
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.
The buyer’s guide describes more than forty enterprise platform teams whose authentication was improvised, and contrasts that with the requirements of properly logging a developer’s identity alongside an agent service principal. The Mecatl project applies the same principle in code: it deliberately separates the agent loop from identity and credentials so those parts can be sandboxed and controlled.
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.
Read more
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.
McLuckie compares MCP to early Kubernetes, where powerful primitives left security to the operator and the ecosystem eventually responded with admission control, policy engines, supply chain attestation, and runtime isolation. They give extra weight to two findings from the NSA report: silent capability drift, where an approved server can quietly gain permissions, and the fact that one tool’s output becomes the next tool’s untrusted input, making chained workflows an injection surface.
Annotations are hints until a registry verifies them
MCP lets a server declare whether its tools are read-only, destructive, idempotent, or open-world.
Read more
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.
McLuckie points to provenance checks through Sigstore and GitHub Attestations as the existing verification step. Extending that process to annotation accuracy, they argue, would let a client act on an annotation with confidence.
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.
Read more
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.
McLuckie credits Joe Beda, who coined “the dangerous middle” and pushed the team to understand the pattern, with the framing that a lack of specificity in research leads to plausible but incorrect development. As Beda put it, in McLuckie’s account, teams that skip paying down cognitive debt and applying taste and experience end up in that gap.
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.
Read more
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.
The garage-and-container analogy makes the point concrete: dropping one container, or hundreds, into an industrial park does not produce a factory. Moving a desktop harness into a container or virtual machine changes where it runs, not how it works.
Governance that creates friction gets circumvented
McLuckie treats developer experience as part of security, not a separate concern.
Read more
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.
In the buyer’s guide, McLuckie frames shadow MCP usage as the result of a painful-to-use registry. They describe scoping virtual servers by team, role, or workload as one way to avoid giving every developer an unmanageable tool list—the example is a single server exposing 1,200 AWS tools to everyone.
Start here to understand the enterprise problem they address: how platform teams can deploy MCP tools responsibly without letting sprawl and improvised authentication stall adoption.
Read more
They say they spoke with more than forty enterprise platform teams about responsible MCP deployment and found consistent patterns: sprawl already underway, improvised authentication, and security teams slowing adoption until controls exist.
The buyer's guide offers a capability checklist and evaluation framework, not vendor marketing.
It covers identity passthrough, virtual MCP server composition, developer experience as a governance issue, runtime and deployment requirements, supply chain security, observability and vendor evaluation.
Examples include logging a developer's identity alongside an agent's shared service principal, using OAuth token exchange and on-behalf-of token support, and scoping virtual servers by team, role or workload instead of exposing tools such as 1,200 AWS tools to every developer.
For brands planning a campaign
For a technical leadership or platform governance campaign, this post shows McLuckie conducting primary enterprise research and buyer education on MCP evaluation, identity and controlled adoption.
This explains the project and the architectural argument behind it in language newcomers can follow before reading code or project documentation.
Read more
McLuckie compares most coding agents to a master craftsperson working alone in a garage.
Moving that garage into a shipping container or putting hundreds of containers in an industrial park does not make it a factory: factories have shifts, processes that move work between stations and methods to meter output.
Lifting a desktop harness into a cloud container or virtual machine changes where it runs, not how it works.
Mecatl, an open-source project, rethinks the harness for an enterprise-grade AI factory.
Its design separates the agent loop from sensitive components such as identity and credentials, breaks out tool execution environments for sandboxing, and aims to work across models and providers to reduce lock-in to a frontier lab stack.
For brands planning a campaign
For a campaign about open-source AI infrastructure, agent security or enterprise architecture, this post offers a clear project narrative and concrete design decisions for developer-facing or technical leadership content.
Read this to see how they translate a formal security publication into an operational argument about where MCP controls belong.
Read more
They highlight the NSA's finding that MCP security posture remains uneven and depends heavily on implementation discipline rather than protocol guarantees.
They compare it to early Kubernetes, when powerful primitives left security to the operator and the ecosystem eventually addressed problems at the infrastructure layer through admission control, policy engines, supply chain attestation and runtime isolation.
They summarize the NSA recommendations as curated registries with provenance, sandboxed tool execution under least privilege, identity-bound sessions, audit trails at the mediation point and formal egress control.
They stress two points: silent capability drift, where an approved server can gain new permissions without a current consent model catching it, and the fact that one tool's output is untrusted input to the next, making chained workflows injection surfaces.
For brands planning a campaign
For a campaign about AI security standards, platform governance or compliance, this post shows how McLuckie turns published guidance into architecture and policy decisions, rather than endpoint-by-endpoint auditing.
This offers a data-backed picture of MCP supply chain risk and shows why registries and runtime controls matter in practice.
Read more
McLuckie discusses OX Security research on 15,465 MCP servers listed in public registries.
The findings include 16% of underlying hostnames resolving outside the United States, with some in China and Russia; servers running over home networks and consumer tunnels; and six referenced domains that were unregistered, meaning anyone could buy one and inherit trust from config files still pointing to it.
They note that MCP has no notion of data residency, so agents do not know compliance boundaries exist.
Published source code does not prove what code a server actually runs, they add, and a single "don't ask me again" click becomes a standing trust grant.
Their recommended response: a vetted server registry, runtime isolation and an identity on every connection.
For brands planning a campaign
For a security or developer platform campaign, this post offers specific risk evidence and a clear policy agenda: vetted registries, runtime isolation and identity-bound connections.
This explains how MCP describes risk and why those descriptions need independent verification before they can serve as policy.
Read more
McLuckie says tool annotations in MCP are becoming a shared vocabulary for describing agentic risk.
Servers can declare whether tools are read-only, destructive, idempotent or open-world, and five new proposals are in flight to expand that vocabulary.
But annotations are hints, not contracts: a server can claim its tools are read-only while behaving otherwise.
The specification explicitly says clients must treat annotations from untrusted servers as untrusted.
They call this a supply chain problem and say the ToolHive registry verifies provenance through Sigstore and GitHub Attestations.
Extending that process to check annotation accuracy against source code would make the registry a trust broker, allowing organizations to treat annotations as policy inputs rather than informational hints.
For brands planning a campaign
For a campaign about trust infrastructure, registries or MCP policy controls, this post explains how a registry could turn annotations from hints into verified policy inputs.
This outlines their approach to working with AI systems and explains why they emphasize specification before scaling agent output.
Read more
McLuckie argues that AI output is seductively plausible because it is optimized to produce statistically optimal content based on the prompt.
Applying traditional R&D thinking to AI systems can therefore lead to bad outcomes.
They cite Joe Beda's idea of the dangerous middle: a lack of specificity during research leads to plausible but incorrect implementations during development.
They distinguish research from development.
In research, teams should work interactively with AI to build cognitive understanding and achieve high specificity, paying down cognitive debt upfront.
Once specificity is high, teams can deploy a factory of agents to produce usable work products, iterating on the domain model and abstractions before letting builders handle scaffolding and detailing.
Without enough upfront work, taste and experience, teams end up in the dangerous middle.
For brands planning a campaign
For a campaign about AI-assisted engineering, developer productivity or technical leadership, this post offers a memorable framework for when to use agents and when to invest in problem definition.
A concrete attack scenario shows why runtime isolation and secret partitioning matter to anyone running MCP servers.
Read more
McLuckie discusses Pillar Security’s deadbugz campaign, a supply chain attack using MCP.
Attackers targeted users of open-source projects, submitting pull requests to 23 GitHub repositories that included their MCP server.
The first three tool requests would have looked entirely normal; the fourth introduced malicious prompting to exfiltrate secrets and obscure its presence.
Maintainers did not merge any of the pull requests.
McLuckie’s takeaway: security needs to be built into the platform, not added as an afterthought.
Partition secrets and isolate the MCP runtime.
For brands planning a campaign
For a security awareness or MCP platform campaign, this post offers a vivid threat story and a direct call for platform-level controls, not user vigilance alone.
Governing MCP access before agent deployments sprawl5
Turning third-party reports into platform arguments4
Identity as the hard, commonly skipped problem2
A platform builder judging the field2
Mecatl and what an enterprise-grade agent factory needs1
AI in research versus development: specificity before scale1
Governing MCP access before agent deployments sprawl
Most posts focus on what breaks when companies give agents access to MCP servers, and what a platform layer must do about it.
Read more
Craig names concrete failure modes: servers whose hostnames resolve outside the buyer's jurisdiction; servers running on home networks and consumer tunnels; unregistered domains that someone could buy and inherit the trust of every config file still pointing to them; and tool annotations that a server can claim without honoring. The proposed fix is consistent: a vetted registry with provenance checks, runtime isolation, and an identity attached to every connection.
Uses figures and named failure modes from third-party research, then draws out an infrastructure-layer remedy.
For brands planning a campaign
Security and platform vendors get a practitioner-level discussion of MCP risk, not a generic AI-security pitch. The natural fit is governance, registry, or runtime-isolation positioning, with Craig speaking to the architecture as well as the threat.
Craig singles out identity passthrough as the most difficult and most frequently avoided part of MCP deployment.
Read more
When a developer's agent calls an enterprise tool through an MCP server, the platform must log that developer's identity alongside the agent's shared service principal.
That requires OAuth token exchange flows, on-behalf-of token support, and deeper identity-provider integration than most lightweight gateways offer.
The same instinct appears in the Mecatl post, where the agent loop is deliberately separated from identity and credentials so those components can be isolated and sandboxed.
For brands planning a campaign
This shows where a product claim will be tested: can the vendor explain its identity flow concretely? A campaign built on credential brokering or identity-aware gateways would enter a conversation Craig already has firm opinions about; vague marketing language would stand out.
Mecatl and what an enterprise-grade agent factory needs
Craig describes Mecatl, an open-source project, as a rework of the coding-agent harness rather than a desktop tool dropped into a container.
Read more
The argument is architectural: a factory has shifts, moves work between stations, and meters output, so lifting an individual harness into the cloud changes where it runs but not how it works. The design separates the agent loop from sensitive subsystems such as identity and credentials, breaks out tool execution environments for sandboxing, and keeps the stack portable across models and providers to avoid lock-in to one frontier lab.
Uses the analogy that a garage is not a factory to set up the architectural argument.
For brands planning a campaign
For an enterprise software company, this is the clearest evidence of hands-on platform engineering: a named project with a stated design rationale. It suits a brief about open-source credibility, developer tooling, or technical leadership better than a pure thought-leadership placement.
AI in research versus development: specificity before scale
One post departs from MCP and security entirely.
Read more
Craig argues that AI output is "seductively plausible" because it is statistically optimized to the prompt, so applying traditional R&D thinking to AI systems produces bad outcomes.
Borrowing Joe Beda's term "the dangerous middle," they distinguish the two activities: do the interactive work up front to reach a high level of specificity and pay down cognitive debt, then deploy a factory of agents to produce usable work products.
Coding agents fail when the problem has not been chewed to the bone first.
The post does not address MCP or security, and attributes its central framing to another person's public post.
For brands planning a campaign
This is a better hook for a campaign about developer productivity or AI-assisted engineering practice than for one about security controls: it addresses how teams should adopt AI tools generally, not a specific platform capability.
Turning third-party reports into platform arguments
A recurring format: Craig reads a report, standard, or incident, summarizes the finding, then draws out a platform consequence.
Read more
The NSA's MCP design guidance becomes an argument that MCP security will be solved at the infrastructure layer, as early Kubernetes security was solved through admission control, policy engines, and runtime isolation.
OX Security's scan of public registries becomes a supply-chain hardening case.
A Pillar Security campaign that planted a malicious MCP server inside pull requests to twenty-three open-source repositories becomes a reminder to partition secrets and isolate runtimes.
Researchers are named and sources linked.
For brands planning a campaign
A brand can expect its report or incident write-up to serve as raw material for a practitioner argument. That works well for a report-led launch, but not for a campaign that needs Craig to lead the original discovery.
Several posts double as evaluation criteria for the category.
Read more
The MCP buyer's guide is described as drawing on direct conversations with more than forty enterprise platform teams.
Its checklist — identity passthrough, virtual server composition scoped by team or role, and governance that does not create workarounds — is presented as a way to distinguish serious platforms from lighter-weight gateways.
The annotation post makes a similar argument: a vetted registry can turn annotations from hints into policy inputs.
The posts do not state an employer or product affiliation; phrases such as "we wrote" and "our blog" suggest a commercial connection. Ask Craig to clarify any firm affiliation before using the posts as independent endorsements.
For brands planning a campaign
Read these as the perspective of someone building and selling inside the category. Treat claims about competing platforms as a positioned view, not a neutral survey; don't expect McLuckie to validate a rival product on the merits alone.
McLuckie speaks as part of the teams building two things central to their work: the open-source Mecatl agent framework and the ToolHive MCP server registry.
Read more
In both cases, they write as “we.”
They also amplify third-party security research from OX Security and Pillar Security.
Ask what their formal role and commercial ties are to Mecatl and ToolHive.
Mecatl
Disclosed partnership
McLuckie describes Mecatl as “our open source project” and explains its design: separating the agent loop from identity and credentials, and sandboxing tool execution.
Read more
The posts show they are part of the team behind Mecatl, an open-source framework for enterprise-grade agent deployment. Ask what their formal relationship to the project is.
McLuckie writes about ToolHive’s MCP registry in the first person (“When we vet an MCP server for the registry”), describing provenance checks through Sigstore and GitHub Attestations and proposing that the registry validate tool annotations.
Read more
This places them inside the ToolHive team. Ask what their role and commercial relationship to ToolHive are.
McLuckie summarizes and credits OX Security research on 15,465 publicly listed MCP servers, including findings on non-US hostnames, servers running on home networks, and unregistered referenced domains.
Read more
They credit the researchers by name and point readers to their gated report.
McLuckie flags Pillar Security’s “deadbugz” campaign as an interesting example of an MCP supply-chain attack: pull requests to 23 GitHub repositories bundled a malicious MCP server and used a late tool request to prompt secret exfiltration.
Read more
They highlight the incident as a lesson for platform security.
Start with McLuckie's posts on MCP governance: a scan of public registries, the deadbugz supply-chain campaign, and the argument that MCP security belongs in the infrastructure layer.
Read more
Follow the thread into identity passthrough and the Mecatl agent harness, which separates identity, credentials, and tool execution from the agent loop.
The remaining posts focus on engineering practice: do the specification work before scaling agent output, and treat developer experience as part of governance because painful controls get bypassed.
The tags below map those subjects, formats, and audiences.
Similar creators tackle adjacent problems in agent security, software supply-chain governance, and AI-agent readiness from different vantage points.
Works the same territory of securing software delivery and supply chains, and has moved into agentic software factories and AI governance.
Read more
The Secure Software Factory posts lay out capability pillars that include artifact and supply-chain control and unified risk correlation, overlapping with McLuckie's arguments about registries, provenance, and runtime isolation.
Radford packages the material as a vendor-neutral operating-model assessment and maturity roadmap for enterprise DevSecOps programs; McLuckie's posts stay closer to MCP protocol mechanics, agent harness architecture, and open-source tooling.
Both discuss how enterprises and software vendors need to adapt architecture for AI agents as first-class users.
Read more
Votek's scorecard dimensions — API openness, agent-native features, data portability, real-time access, and ecosystem flexibility — overlap with McLuckie's platform evaluation criteria and concern about lock-in.
Votek writes from a consulting and implementation vantage, ranking vendors and describing client agents and an AI project factory; McLuckie writes from a security-infrastructure and open-source vantage, focusing on MCP governance, identity passthrough, and sandboxed runtimes.
Both treat agent identity and authorization as a core security problem.
Read more
Sinha's AI Agent Passport asks who an agent is, what it is authorized to do, and how to revoke access — the same questions McLuckie raises about identity passthrough and logging developer identity alongside agent service principals.
Sinha argues for cryptographically verifiable agent passports and PKI-backed trust, often tied to DigiCert and NVIDIA platform announcements; McLuckie argues for vetted MCP registries, isolation, and annotations verified against source code, usually at the level of MCP deployment architecture.
Craig McLuckie had 9,101 LinkedIn followers on October 23, 2026.
Read more
For a technical leadership role focused on AI agent security and platform governance, that’s a modest but relevant reach marker: a working practitioner with a professional following, rather than a mass-audience commentator.
From March 19 to October 1, 2026, their posts consistently addressed enterprise platform and security audiences.
Topics included responsible MCP deployment and identity passthrough (March 19, 2026), vendor evaluation criteria for MCP platforms (March 19), the NSA's MCP security design guidance and its parallels to early Kubernetes (July 29), annotation trust and supply-chain verification in MCP registries (April 2), MCP supply-chain research findings on public servers (September 24), an open-source agent architecture called Mecatl (September 22), and a supply-chain attack campaign using MCP pull requests (October 1).
The profile doesn’t establish whether their followers match the role’s target buyers.
Ask Craig or their team for recent post-level impressions and engagement rates, performance from a few comparable technical posts from the past six months, and any audience survey or LinkedIn follower demographics broken down by seniority, industry, and region.
LinkedIn followers
9101
LinkedIn profile, as displayed on the account · 2026-10-23
Craig McLuckie's posts do not describe a sponsorship, paid-partnership, or creator-collaboration format.
Read more
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.
Brief: an enterprise platform-security vendor preparing to launch an identity-aware gateway, a vetted MCP registry, or a runtime-isolation product wants a practitioner-led campaign for platform engineering and security teams.
Read more
Deliverables: a technical guide or launch report, a short series of LinkedIn posts, and one or two live evaluation sessions.
Why it fits.
Craig McLuckie's recent posts already do much of what this brief needs.
Their buyer's-guide post describes direct conversations with more than forty enterprise platform teams and a capability checklist covering identity passthrough, virtual MCP server composition scoped by team or role, runtime and deployment requirements, supply chain security, observability, and vendor evaluation.
It also names the failure the product is meant to fix: when a developer's agent calls an enterprise tool through an MCP server, the developer's identity needs to be logged alongside the agent's shared service principal.
That requires OAuth token exchange and on-behalf-of token support—a specific capability walkthrough a launch session can build around.
Two posts show how they turn outside material into a platform argument.
The NSA guidance post takes a formal publication and pushes it to infrastructure: curated registries with provenance, sandboxed tool execution under least privilege, identity-bound sessions, and audit trails at the mediation point.
It flags two potential campaign topics: silent capability drift, where an approved server gains permissions without any current consent model catching it, and the fact that one tool's output is untrusted input to the next, making chained agent workflows an injection surface.
The OX Security post supplies hard numbers from a scan of 15,465 public MCP servers, including 16% of hostnames resolving outside the United States and six unregistered domains that anyone could buy and inherit configuration trust from.
Mecatl adds engineering credibility: a named open-source project that separates the agent loop from identity and credentials and breaks out tool execution for sandboxing.
What the brief has to accommodate.
The topics section shows they are a builder and seller inside the category, not a neutral observer.
Buyers will test claims against a concrete architecture walkthrough rather than accept them as positioning.
The partnerships section lists no published sponsorship offer, rate card, or inquiry route, so any arrangement starts as a direct conversation.
Audience evidence is thin: the only measured figure is 9,101 LinkedIn followers on the account snapshot dated October 23, 2026, with no engagement rate, geography, seniority, or job-function breakdown.
Before committing campaign budget, ask for recent post-level performance and follower demographics split by seniority, industry, and region.
When to choose a specialist
A consumer-facing AI product or mass-market brand wants broad awareness, booked mainly on follower scale and short-form video performance, with creators carrying the message in a lifestyle register.
Read more
Why it does not fit.
The only measured audience figure is 9,101 followers on LinkedIn, recorded October 23, 2026.
The posts do not mention video, transcripts, or short-form performance, so there is no basis for a video-first campaign.
They also provide no audience breakdown by geography, seniority, job function, industry, or engagement rate; ask for those figures before judging audience fit.
The writing assumes a reader who knows what a service principal, OAuth token exchange, least-privilege sandboxing, and egress control are.
It covers silent capability drift, annotation verification against source code through Sigstore and GitHub attestations, and a supply-chain attack that hid a malicious MCP server inside pull requests to twenty-three open-source repositories and only turned hostile on the fourth tool request.
That professional register can be translated, but a consumer-facing campaign would be paying for a professional audience it cannot reach.
There is also no documented commercial format.
The posts list no sponsorship offer, rate specification, or partnership inquiry route, so a campaign that depends on buying packaged deliverables has nothing to purchase yet.
What a brand could still do.
If the goal is enterprise credibility with a consumer veneer, restate the need around a platform or security audience and treat mass reach as a later question.
Ask whether Craig McLuckie has a video or podcast presence and for a published partnership policy.
A worked campaign example
Worked angle for a campaign aimed at enterprise platform-security audiences: "The controlled MCP rollout."
The campaign asks a platform team to walk through how it would let agents reach enterprise tools without losing identity, provenance, or an audit trail. McLuckie's posts make the case that governance belongs at the layer servers run through, not in a thousand individually audited servers.
Anchor asset.
A 30 to 45 minute recorded technical session, or a written teardown of the same length, built around four steps a platform team has to complete: bind a developer's identity to the agent's shared service principal through token exchange and on-behalf-of support; define virtual servers scoped by team, role, or workload instead of exposing every tool to every developer; verify provenance and annotation accuracy before a server enters the registry; isolate the runtime and partition secrets so a compromised tool cannot reach the rest of the environment.
Each step gets a concrete example.
The session closes with the vendor's own architecture shown at the same level of detail it asks the audience to accept.
Series.
Three short pieces, each starting from a documented problem rather than a pitch.
One on the scan of 15,465 public servers and what a vetted registry has to prove; one on silent capability drift and why a one-time approval click becomes a standing trust grant; one on the deadbugz campaign as a readout of what runtime isolation and secret partitioning would have contained.
The series links to the session and a working checklist, not a demo request.
Live element.
A 45 minute evaluation clinic where McLuckie and a platform engineer work through the checklist against a volunteered deployment and take hard questions on identity flows.
The output is a filled-in checklist the audience can reuse.
What to avoid. Generic AI-security fear messaging, a media plan built on follower count, and a neutral comparison of competing platforms, which this position does not support.
What the buyer should test before committing. Whether the written and recorded assets stand up to a reader evaluating three vendors at once; whether the checklist works outside the campaign page; and whether the vendor can pass the architecture walkthrough test McLuckie applies to competitors.
Open gaps.
The posts mention no partnership terms or inquiry contact and state no employer or product affiliation; phrases such as "we wrote" and "our blog" provide the commercial framing.
Ask which company is involved and whether an approval process applies.
Audience performance and demographics are also unverified; ask for the data.
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.
Read more
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.
Radford’s posts focus on frameworks and offers.
They identify the failure — tooling without integration, governance, and operating discipline — and lay out pillars, a whitepaper download, and a maturity assessment.
But they stop short of a concrete architecture at the identity or registry level.
Buyers looking to pressure-test a gateway’s OAuth token exchange, a registry’s provenance checks, or runtime isolation will find less depth.
The campaign also shifts toward a paid assessment, changing the call to action from a technical evaluation session to a maturity review.
Choose Votek when the buyer’s task is market positioning or implementation-partner selection, rather than evaluating one control.
Read more
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.
The posts offer scorecards and commentary, not hands-on MCP security.
They don’t treat agent identity, server provenance, or runtime isolation at the architecture level, so a campaign seeking a practitioner teardown or neutral comparison of competing controls would be buying a different kind of authority.
Some of the work is framed around Customertimes’ own implementation practice, which makes the positioning less neutral.
Votek’s five scoring dimensions are also broader than the gateway, registry, or isolation decision this campaign needs to address; the benchmark would need to be restated to map onto the product.
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.
Read more
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.
Sinha writes from inside the product being promoted, so the posts read more like product messaging than independent analysis.
They assert a kill switch, signed agents and MCP servers, and trust across organizational boundaries without demonstrating them.
Buyers seeking a neutral side-by-side of competing approaches, or a walkthrough of what fails when identity checks are skipped, will find less of that here.
This comparator also narrows the campaign to the identity layer, leaving server provenance, registry vetting, and runtime isolation to other voices.
Before booking, ask for audience and engagement data and whether partnership is available.