They Didn't Give the AI Your Endpoints. They Gave It Your Operator.

You create a token by opening an elevated command prompt on your BigFix root server, running BESAdmin.exe /createtokenkey, then going into the Console under Tools, Manage Tokens, and clicking Add New. The dialog asks for a name and a duration. The example everyone is working from puts 365 in the duration field. There is a checkbox underneath it labeled Non-expiring token.

Then the token appears once, in a box, with a Copy Text button and a warning that this is the only time you will ever see it.

That string is now the answer to a question nobody in the workflow asks out loud: how much of your environment is the AI allowed to touch? Not the model's answer. Not the MCP server's answer. The answer is whatever that operator identity could already do, because the token is that operator, and the entire security posture of this integration rests on which operator you picked at a moment when the dialog box in front of you was asking about names and dates.

I have spent nearly 30 years in endpoint management, six of them at HCL Software, and I can tell you exactly what most shops are going to type into that box. They are going to use the account that already works. They always do.

What Actually Shipped

On August 5, 2026, the BigFix Platform team announced the BigFix Platform MCP Server, version 1.0.0. The Model Context Protocol is an open standard for letting a language model call real tools instead of hallucinating about them. In practice it means an AI client can now retrieve data from your BigFix environment and help you author and run actions on your endpoints using plain English.

The mechanics: it runs as a standalone service, streamable HTTP over HTTPS, normally on port 9494. It requires BigFix Platform 11.0.6 or later, because it depends on the REST API bearer token support that shipped in that version. You install it with Task 6073 out of the BES Support site, on Windows Server 2022 or later or Red Hat Enterprise Linux 9 or 10, either on the root server itself or on a separate box that can reach the root server on 52311.

Understand the stakes here, because they are not the stakes of a chatbot that summarizes your email. BigFix is the thing that patches your fleet. It is the thing that can push an arbitrary action to every machine in the enterprise before lunch. When I was on the KREM team at Kroger during WannaCry, the reason we were not on the news was that we could reach every endpoint we owned, quickly, on purpose. That capability is the point of the product and it is also the reason this particular integration deserves more scrutiny than most.

You are not connecting an AI to a reporting tool. You are connecting it to the remote execution layer.

Credit Where It Is Actually Due

I want to be plain about this, because I came into the research expecting to find security theater and I did not find it.

Read-only mode is enforced at execution time. The documentation says so explicitly, and it goes out of its way to say it is not merely an instruction in the tool description or a suggestion to the AI model. The server compares the requested operation against generated tool metadata and blocks anything classified as create, update, retry, stop, or otherwise write-capable before a single byte reaches the root server.

Better, it is a double negative by default. Writes require the server config to have read-only off and the client to send X-Bes-Mcp-Read-Only: false on the request. Missing header, invalid header, malformed anything: read-only by restrictive default. That is fail-safe design, and plenty of much larger vendors do not bother.

Human-in-the-Loop is real, and it is not a prompt. In most vendor AI integrations, “human in the loop” means a line in the system prompt politely asking the model to check with a person first, which is a control in the same sense that a sign is a fence. Not here. The server stages the exact request, computes a SHA-256 binding over the tool name, the operation, and the exact JSON payload bytes, ties the approval to the current session and a fingerprint of the caller, gives it a five-minute lifetime, makes it single use, and revalidates every one of those conditions immediately before execution. Change one byte of the payload and the approval is void. Time out and it fails closed. If the AI client does not support MCP Form Elicitation at all, the server blocks the write rather than proceeding without approval.

There is an audit trail with distinct events for pending, approved, denied, expired, executed, bypassed, blocked, and state error. There is an automatic IP lockout after five consecutive failed requests.

And underneath all of it, the architecture is right: the MCP server is a token-forwarding gateway, not a service account. It does not create a shared privileged identity and it does not bypass BigFix permissions. Your token goes through to the root server, which validates it, identifies the operator, applies RBAC, and makes the final call. The documentation states flatly that human approval and MCP security controls do not grant additional BigFix permissions and that root server RBAC remains authoritative.

That is a good design. I have reviewed a lot of vendor AI integrations this year and most of them are a service account with god rights and a paragraph of marketing about responsible AI. This is not that. Say it out loud before you say anything else.

Now here is the part that keeps me up.

The Tool Families Nobody Put in the Announcement

The August 5 forum post lists what you can do with it: action lifecycle management, custom action authoring, Fixlet and Task deployment, computer listing, Fixlet discovery, Session Relevance evaluation. Reasonable. Operational. Roughly what you would expect.

The actual product documentation lists something the announcement did not. Under currently implemented tools, alongside the action and computer and Fixlet families, sits this line: identity and access management, including identity providers, LDAP, Operators, and Roles.

The write-capable tools you can selectively disable are named in the config reference:

manage_bigfix_action · manage_bigfix_analyses · manage_bigfix_baselines · manage_bigfix_computers · manage_bigfix_fixlets · manage_bigfix_idp · manage_bigfix_ldap · manage_bigfix_operators · manage_bigfix_query · manage_bigfix_roles · manage_bigfix_session · manage_bigfix_sites · manage_bigfix_tasks

Read those four bold entries again. With writes enabled, the surface area of this integration includes the identity system that governs the integration. Operators. Roles. LDAP. Identity providers.

To be scrupulously fair on the mechanics: this is not a bypass. Every one of those calls still lands against root server RBAC with your token, and if your operator cannot modify roles, neither can the model. That is exactly how it should work. And read_only_tools: [] exists precisely so you can leave manage_bigfix_computers writable and slam the door on manage_bigfix_operators, which is a well-designed knob that I am glad someone thought to build.

The engineering is fine. The disclosure is not.

An announcement is a scoping document. It is the thing a director reads before approving a pilot, the thing that gets pasted into a change request, and in most organizations it is the only artifact anyone above the operator level will ever read about this product. HCL's announcement described action lifecycle management and computer listing. It did not mention that the same integration can reach identity providers, LDAP configuration, operators, and roles.

Nobody builds a read_only_tools knob for manage_bigfix_operators unless writing to operators is a thing that happens. The capability is real, the risk is real, and the security-relevant half of the tool inventory was left out of the document written to be read and put into the document written to be referenced. That is not a bug and it is not an accident of drafting. It is a choice about what a launch post is for, and it means a shop can approve this integration on the basis of an accurate announcement and still have no idea what they just authorized.

The Gap Is Not the Lab. The Gap Is the Trip Out of It.

Here is where I have to talk about a walkthrough, and where I want to be very careful about who deserves the criticism, because it is not the author.

The day after the announcement, Brad Sexton, a BigFix Technical Advisor at HCL Software, published the first practical end-to-end guide to standing this thing up and wiring it to Gemini CLI. It is a good piece of work. It filled in gaps the release notes left open, and I could not have written this article without it. If you are deploying this, go read it.

His screenshots show 59 computers, six operators, twenty roles, one Windows 11 box, one RHEL 8.3 box, one lonely macOS machine. That is a lab. Obviously it is a lab. Nobody demos a new integration against production, and anyone who says otherwise has never had to explain an outage to a change advisory board.

And in a lab, everything in that walkthrough is correct. That is the whole problem.

Three examples.

One: the certificate. The MCP server generates a self-signed certificate in its workspace if you do not give it one. Predictably, a client that validates TLS properly will refuse to talk to it. The walkthrough's solution is a line of shell:

set NODE_TLS_REJECT_UNAUTHORIZED=0

That disables certificate validation for the entire Node process, not just the BigFix connection. And what is traveling over that now-unverified channel is a bearer token with a 365-day life that maps to a real BigFix operator identity.

On a lab VM talking to a self-signed cert on the same subnet, that is a shrug. In production it is a credential moving over a channel with no way to know who is on the other end.

The vendor documentation, for its part, says the right thing. It tells you to confirm certificate trust when prompted and to ensure the listener certificate is trusted by the environment opening the connection. Nobody at HCL told anybody to turn off TLS validation.

They just shipped a default that makes turning it off the fastest way to a working demo. A self-signed certificate generated into the service's own workspace is not a neutral convenience. It guarantees that the first thing a new user experiences is a TLS failure, at the exact moment they are trying to prove the product works, with a one-line workaround sitting in every search result. Predicting that outcome does not require a threat model. It requires having watched one person install software.

If you are going to put a bearer token on the wire, the install Fixlet should refuse to start without a trusted certificate, or it should generate one and tell you in bold that it is for lab use and will break real clients. It does neither. The official guidance and the practical guidance say opposite things about the same step, and the reason is a default that HCL chose.

Two: the checkbox. Task 6073's deployment screen has a section titled Service Execution (Least Privilege) with a checkbox reading Run service as unprivileged user. Directly above it, under Security Settings, Enable Read-Only Mode is checked by default.

Run service as unprivileged user is not checked by default.

Somebody made two different decisions about defaults inside the same dialog box, which means the safe default was clearly available as a pattern and was not applied here. A heading that says “Least Privilege” over a control that ships off is worse than no heading at all. It launders the appearance of the control. An auditor screenshotting that dialog sees the words. A CAB reviewer skimming the change request sees the words. The words are doing work the checkbox is not.

Three: the header. X-Bes-Mcp-Disable-Hitl: true. All that SHA-256 payload binding, the session fingerprint, the five-minute single-use expiry, gone, because the client asked. The documentation's own description of this control is the most revealing sentence in the entire manual:

Treat this as a trusted client control.

Sit with what that sentence concedes. The server cannot verify that the client is trustworthy. It has no mechanism to. The client is the untrusted half of this architecture by definition, sitting outside the security boundary the docs themselves draw, and it has been handed a header that switches off the server's strongest control.

I understand why it exists. Somebody needs unattended automation, and a five-minute human approval window does not survive a scheduled job. But the honest way to ship that is a server-side allowlist: named clients, pinned by certificate or mutual TLS, permitted to bypass. Instead the bypass is a string in an HTTP request, and the documentation discharges the risk by telling you to trust the thing it cannot check. That is not a security control with a caveat. That is a caveat wearing a security control's clothes, and it means the real enforcement boundary for writes is whoever edited a config file on a workstation.

None of these three things is a bug. Every one of them is a documented, deliberate, defensible option. And every one of them is a correct choice in a lab and a catastrophic one at fleet scale, with nothing anywhere in the chain that tells you which one you are in.

That is the actual finding. Not that HCL built it badly. That the artifact which will define how most shops deploy this is not the security architecture page. It is the first good tutorial, and the first good tutorial was written on a 59-endpoint lab box, as it should have been, and it carries that box's assumptions invisibly into every environment that copies it.

Six months from now somebody inherits that runbook. They will not know it was a lab. It will just be the thing that works.

Two Security Cultures, Five Weeks Apart

Now hold the Platform team's work next to something else with the same logo on it.

The BigFix AEX 12.1 Agentic AI Studio documentation covers connecting MCP endpoints through a Gateway client. Its installation instructions walk you through the Windows protection warning by telling you to click More Info, then Run anyway. Its worked examples for MCP server URLs are http://0.0.0.0:3001/mcp and http://0.0.0.0:3001/sse. Plain HTTP. Bound to every interface on the machine.

Take those one at a time, because both are worse than they look.

“Run anyway” is published security guidance. Not a forum post, not a blog, not a support agent improvising. Official product documentation, from a security company, instructing customers to click past the operating system's warning that this binary is not trusted. Every phishing simulation your organization runs teaches people not to do that. Every awareness module you have ever bought is about that exact moment of hesitation. HCL's own documentation spends it, in writing, to save the cost of a code-signing certificate.

0.0.0.0 over plain HTTP is not a typo, it is the example. Someone will copy it, because that is what worked examples are for. An MCP endpoint bound to all interfaces with no transport encryption, in a product line whose sister component just shipped mandatory HTTPS and token forwarding, is not a nuance. It is a component that would fail any internal review it was actually put through.

Compare all of that to a Platform team that shipped double-negative read-only defaults, payload-bound approvals, and an IP lockout.

Same brand. Weeks apart. One team clearly had a security reviewer in the room and the other clearly did not.

I know how this happens, because after nearly 30 years around enterprise software I have sat in the meetings where the roadmap date is the only thing that cannot move. Version 1.0.0. One day between the announcement and the first community walkthrough. A documentation set still visibly catching up to a product that is already installable, to the point that the “Using” page contains an editorial note to its own authors about not relying on the model to explain the product, shipped to customers as part of the manual.

But understanding how it happens is not the same as excusing it, and I want to be careful not to slide from one into the other. HCL is not a startup. BigFix holds Common Criteria certification and sits inside federal environments. The Platform team demonstrated, in the same release window, that this organization knows exactly how to do this correctly. Which means the AEX documentation is not evidence of a company that does not know better. It is evidence of a company that knows better and shipped anyway, because the AI-integration race is on and the deployment path is the part customers do not evaluate until after they have bought.

The security engineering got the attention. The deployment path got what was left over. And the deployment path is the only part most customers will ever experience.

Wiring It to Claude Code

For those of you who, like me, live in a terminal. Claude Code supports remote streamable HTTP MCP servers with custom headers, which is exactly the shape the BigFix MCP Server needs.

Untested. I do not currently have an 11.0.6 environment to run this against. This is derived from the BigFix client configuration reference and Claude Code's MCP documentation, not from a working deployment. Verify every line before you point it at anything that matters.

claude mcp add --transport http --scope user bigfix \
  https://YOURBIGFIXMCPSERVER:9494 \
  --header "Authorization: Bearer $BIGFIX_TOKEN" \
  --header "X-Bes-Mcp-Read-Only: true" \
  --header "X-Bes-Mcp-Disable-Hitl: false"

Three things about that block.

The token comes from the environment, not the command line. $BIGFIX_TOKEN gets resolved at connection time. Pasting the literal string in puts a year-long credential into your shell history and then into a config file in plaintext. Credit where it is due: Brad's walkthrough does not make that mistake. The bearer token in his screenshots is a deliberate placeholder, with an Easter egg buried in the string for anyone who reads it closely, so the flow gets demonstrated without a real credential ever landing on screen. That is the habit to copy: resolve the token from the environment and keep the live value off the page.

Both guardrail headers are stated explicitly even though the defaults are already safe. Restrictive default means a missing header is read as read-only, so strictly speaking you can omit them. Write them anyway. A config file that states its own security posture out loud survives handoff. A config file that relies on someone's memory of what the default was does not.

Form Elicitation is the compatibility question that decides whether writes work at all. The server blocks HITL-protected writes outright if the client cannot render the approval form. The documentation names GitHub Copilot in VS Code as a validated client. I have not verified which other clients advertise elicitation support, including the one in the command above, so treat that as an open question rather than something I am asserting.

One more practitioner note: there is an open report against Claude Code describing configured --header values not being attached on some tool-call paths, producing Unauthorized responses even when claude mcp list shows connected. If you hit that, it is a client bug, not a BigFix misconfiguration, and you will save yourself a very unpleasant afternoon by knowing that in advance.

What Actually Protects You

Four things. None of them require you to distrust HCL, and none of them are exotic.

• Cut a dedicated operator identity for the AI, before you cut the token. Not your master operator. Not the account that already works. A purpose-built operator scoped to exactly the sites and computer groups the use case needs, with the token's duration set to the length of the pilot and not 365 days. The token is the blast radius. Every other control in this stack is downstream of a decision you make in a dialog box that never mentions the word blast radius.
• If you disable read-only, disable it by tool, not globally. read_only_tools: [] exists. Use it. There is no operational scenario where a patching workflow needs manage_bigfix_operators writable. Leave the identity and access management family locked even when you open up actions and Fixlets.
• Fix the certificate instead of the client. The moment a tutorial tells you to turn off TLS validation, that is the signal that the deployment skipped a step, not that the tutorial found a shortcut. Issue the MCP server a certificate your clients already trust. It is thirty minutes of PKI work against a bearer token traveling over an unverified channel for as long as that token lives.
• Write down which environment your runbook was built in, at the top of the runbook. This one is free and it is the only defense against the actual failure mode in this post. Every deployment doc should open with the fleet size, the environment class, and an explicit line saying which shortcuts in it are lab-only. The tutorial is going to outlive its author's context. Give the next person the context in writing.

The controls in this thing are good. That is not the comforting fact it sounds like, because good controls are the ones people feel safe turning off. Nobody bypasses a security measure they think is load-bearing. They bypass the one that is in the way of a demo working on a Tuesday afternoon.

Get the Deployment Kit

Not ready to reach out? Fair. Everything load-bearing in those PDFs is already in this post. The kit is the organized version, not the secret version.

Disclosure

I worked at HCL Software for over six years and left in late 2024 over a compensation dispute. I hold multiple BigFix certifications. I have no current relationship with HCL Software, no reseller or partner agreement, and I was not compensated, contacted, or consulted by anyone at HCL in connection with this article. Brad Sexton and I were colleagues; I did not coordinate this piece with him, and nothing in it should be read as his position.

This is not a product review and it is not a ranking. BigFix appears here because it is the platform I know at depth and because it is the one that shipped an MCP server this month. The pattern in this article is not specific to BigFix and I would expect to find versions of it in every competing product that ships an agentic integration in the next two quarters.

I am an independent consultant. If your organization is evaluating this, I do that work. That is a disclosure, not a pitch.

Sources & Further Reading

• BigFix Forum: “The BigFix Platform MCP Server is now available!” August 5, 2026, the source for the release scope, version requirements, Task 6073, and the supported-target list.
• HCL Product Documentation: BigFix MCP Server Guide, Introduction and Security Architecture Flow, the source for the token-forwarding architecture, trust boundaries, and port flow.
• HCL Product Documentation: Using BigFix Platform MCP Server, the source for execution-time read-only enforcement, the full HITL flow including the SHA-256 payload binding, the tool family list, the read_only_tools reference, the header table, and the IP lockout.
• HCL Product Documentation: Installing and configuring BigFix Platform MCP Server, the source for the Fixlet configuration options and the disable_hitl semantics.
• Brad Sexton (HCL Software): “AI Meets Endpoint Management: Integrating BigFix with your LLM via MCP (Claude, Gemini, CoPilot, or ChatGPT)” August 6, 2026, the first practical end-to-end walkthrough and the source for the installation flow, the token creation steps, and the deployed tool list.
• HCL Product Documentation: BigFix AEX 12.1 Agentic AI Studio, MCP Client Functionality, the source for the Gateway installation flow and the endpoint URL examples.
• Anthropic: Connect Claude Code to tools via MCP, the source for the HTTP transport syntax and header handling.

Sourcing note: everything I say about the security controls comes from HCL's own published documentation, quoted or paraphrased, with links above. I have not run this against a live BigFix 11.0.6 deployment, and I say so in the Claude Code section rather than implying hands-on validation I do not have. The Claude Code configuration block is derived, not tested. Whether Gemini CLI and Claude Code advertise MCP Form Elicitation support is an open question I could not resolve from public documentation, and I have flagged it as open rather than guessing. Brad's article is cited for what it documents about the installation flow; the criticism in this piece is aimed at defaults and documentation gaps, not at him. Verify anything you plan to repeat, and verify twice before you enable writes.

Connect with Casey

If this resonated, or if there's a topic you want me to take on next, reach out. I read everything.

Casey writes about economic policy, nomadic life, cybersecurity, and navigating the world as a late-diagnosed AuDHD adult. New posts drop on my professional website.