The Battle for Path

The Battle for Path

Under the surface of the explosion of AI companies and products there is an infrastructure battle taking place – it is a battle to control access to your content and make it a part of an AI company’s training data.  It is a battle to control the path of your information.

There is a spectrum of AI usage types today:

  • Individual users on a chat product using a web browser for chatgpt.com or claude.com or similar.
  • Individual users moving to the desktop client of one of these vendors now packaged as “unified” desktops incorporating chat, coding and work features
  • The enterprise account equivalents of either of the first two, with account controls, budgeting, etc.
  • Token/consolidation products like software development tools which let you pick AI endpoints for coding.  Some of these are configured with your individual API keys to your different accounts and others provide an API token to their service and charge an “uplift” as they route your traffic, basically token re-selling.
  • More comprehensive model routers like OpenRouter (just acquired by Stripe) which let you multiplex and set workflows for where to send different types of queries, and let users pick AI targets dynamically as well.

All of these are trying to ensure that they are in path to your interactions with the LLMs, including potentially your own private LLMs.  Why?  Because they want to capture your users’ interactive sessions with the LLMs.

Hot in the recent news is it appears that mathematicians who spent countless hours independent of LLMs pursuing a significant mathematical challenge, applied their domain and research knowledge to guide and direct their “interrogatory sessions” with an LLM – only to have the LLM company take that synthesized knowledge as their own and claim to have solved the mathematical problem.

The business enterprise stakes are perhaps smaller but omnipresent.

The user might be an expert lawyer, with a deep capable memory, depth of experience in industrial operations litigation, who is using LLMs in their work.  The captured, iterative conversation stream from that person, as they ‘leave’ an LLM session satisfied with the result of the interactions, is likely to be valuable.  The human user directed a synthesis of the knowledge available to the LLM, and the person’s knowledge and lived actions.  This synthesis is likely to have never been captured in the training set.  UNTIL NOW.

The user might be a software designer who through the LLM interactions has that ‘aha’ moment about how to tackle a problem, creating new knowledge.  Even if the LLM tried to “one shot” a response to the designer’s initial prompt, let’s assume the person responded with critique and re-direction.  This interrogative stream likely contains, if not entirely new knowledge to the LLM, then curated knowledge, which adds to the value of the LLM provider.  IF CAPTURED.

Everyone wants you in-path to use your knowledge synthesis as the new training data.  Every day the AI services are being fed “AHA” moments that experts have had while making use of the LLMs as a super knowledge base – but in fact shaping, guiding, let’s say providing, much of the intelligence.

Which leads me to repeat “Kerpan’s Law of AI”:

There are two types of AI companies:

  1. those that tell you the are using your content
  2. those that declare they are not, but are lying

 

If you do not control your path to LLMs this will be your forever situation.  At Cohesive Networks we think organizations are on a journey from early adoption of LLM’s as a Service (ChatGPT, Claude, Kimi, etc.) and over time will gradually migrate many of these interactions to self-hosted AI (regardless of in-cloud, hosting provider or on-premise).  The key point will be explicit decisions of how much to share with the “as a service” players.

In the past most of us have been too busy, too introverted, too scared, too worried about HR and Legal, to post detailed interactive transcriptions of our thoughts, of team brainstorms, of the fragment of solutions which are not the heart of a product or service, but provide insight and capabilities to products and services.  BUT, in the confessional of the chat interface, given access to something in many ways worse than search, but in other ways better, a more comprehensive knowledge base, we type, guide, shape, drive to new knowledge and give it away.  No, in fact pay for the privilege.

I am not privy to any such fact, but, the LLM as a Service companies have to have a scoring mechanism in place for queries or users, perhaps both.  I would surmise that users whose primary usage is ‘What’s the best cat food for Calicos in February?’ or ‘How do I clean oil stains off my garage floor?’, while perfectly fine customers, might have a low score for bringing “additive knowledge” to the training data.  But there are some users who you might argue should be paid for interacting with the LLMs.

This is why they want your interactions to flow through their path.  Some subset of those interactions are worth their weight in gold as higher quality training material than much of what has been trained on from Reddit, Stack Overflow, etc. Maybe “better” is even the wrong word.  It is at the very least tapping into to the knowledge creation capabilities of a vastly larger number of people.

 WHAT DO YOU DO?

Our belief is that there are the technical components and policy elements to this situation.

In summary, you will need to have corporate policies that define acceptable AI usage.  This will include approved vendors, tools, and modes of usage.  I am not sure what the “carrot” will be, but the “stick” could be something like “violating this policy is grounds for termination, and possibly further ramifications”.  Frankly there will be a number of cases where you will be “catching the cows just out of the barn”, but at least quickly and not long after.  Your policy might allow OpenAI and Anthropic but only via a manged corporate account, maybe browser-based usage only, whilst their desktop applications are not allowed (unless perhaps on an sterile desktop with limited connectivity).  Of course there needs be strictures against feeding PII or PCI data, details of secret projects, corporate actions (possible acquisitions/divestitures).  These details will have to be stated in policy for the protection of your company, the employees (clear expectations, no surprises), and your customers.

You will need technical guardrails and enforcement.  For example, at Cohesive we have had controls like virus scanners and device management.  Moving forward we will be implementing even stricter controls so that many of the AI wrapper applications can be prevented from running on our laptops/desktops.  (My personal view is ‘Only in a container in a VM on a Linux host, in the cloud’).

So far we have proposed policy of “don’t do that or you will get in trouble” and “we won’t let you do that on your work machine”, but what about everything else?  What are the technical components?

At Cohesive we have created an in-path AI Firewall in a virtual appliance that we call WaiF™.

It works in conjunction with our VNS3 Network Platform.  Overall, we think a network virtualization platform is a prerequisite to meet the challenges in a world of LLMs.  While an entire class of vendors have declared the VPN as dead, we are an outlier, put everyone on a VPN, essentially an AI-VPN, at least for accessing LLMs.  Our WaiF solution integrates to your DNS, collaborates with your WAF if you have one, and creates both alert-in-the-wire and block-in-the-wire capabilities while capturing all of the traffic to your approved LLMs, sending the data to object storage, multi-modal databases, data lake infrastructure, etc. that you already have in place.  A simple place to start is getting it all into object storage with a lifecycle retention policy and auditable/browsable by a self-hosted ElasticSearch dashboard.

Aren’t we at Cohesive just trying to get in your path too?  No, we are letting you control your path, we aren’t in control of this infrastructure you are.

This path gateway approach is the beginning of the inference/intelligence/AI journey every organization is embarking on.  Where any given organization ultimately arrives is “to-be-determined”.  There are businesses where using LLMaaS maybe fine, without ever moving to private or local AI.  BUT, even these organizations need an audit trail, need the best practice of having observability, and in large part visible controls over the usage of AI for their business.

For other organizations the AI Firewall with a network platform is the junction point, the place to hook in additional elements, semantic scoring for example.  You can use your organization’s knowledge of itself to score interactive sessions, determining content which just went off to an LLMaaS, but should now be captured separately as knowledge for your private AI.  As the technology evolves you will be able to “front run” specific users and query types to go immediately to local AI as the frontier model capabilities of today become the local AI of tomorrow.  The accomplishment will be keeping more of your specific intellectual property and accumulated intellectual capital in-house.

As the technology is moving so quickly in multiple dimensions, our primary advice is “start”.   You can’t wait for the final “all singing, all dancing” product as it is unlikely the industry is going to be stable anytime soon.  Have joints, junctures, hooks to be in control, and among these, control your path.

Security Compliance: Discipline, Not a Checkbox

Security Compliance: Discipline, Not a Checkbox

Cohesive Networks has completed its 5th consecutive Type 2 SOC 2 examination. Another full operating year of controls examined and confirmed: same auditor, same standard, no exceptions. We publish this every year not because customers ask for a badge, but because we operate in regulated industries where proof of practice matters more than proof of intent.

Examination Details

  • Selected SOC 2 Categories: Security
  • Examination Type: Type 2
  • Review Period: May 1, 2025, to April 30, 2026
  • Service Auditor:  Schellman & Company, LLC

Built Security-First, Before it was Cool

Cohesive Networks spun out of Cohesive Flexible Technologies in 2014 after a clear-eyed assessment: we weren’t a cloud migration company that happened to do security. We were a security and networking company. That distinction shaped how we built everything that followed — internal systems, controls, and architecture all designed to a standard that’s still overbuilt by today’s measure.

VNS3 itself dates to 2008, built originally to secure our own infrastructure, first our Elastic Server Image Factory cluster, then to provide IP address control and isolation in EC2-classic’s open 10/8 network environment. We didn’t build a security product and then figure out how to run it. We ran it ourselves first, on our own production systems, and we still do — internal Overlay Networks for production and support engineering, PeopleVPN for our distributed team.

That history matters.

No Access…

…By design, Cohesive has no access to customers’ VNS3-provided networks. Access and visibility are entirely in the hands of the owner. VNS3 has no backdoor, only Access URLs, API Tokens, and Remote Support multi-party authentication that customers control directly.

For customers using our SecurePass managed service, we extend that same principle rather than suspend it. When our engineers manage a customer’s environment, we do so through a dedicated secure overlay network using the same architecture we build for customers, applied to our own operations. Total network accountability, in both directions.

Looking Ahead

AI is moving into network infrastructure fast, and the compliance frameworks are running to catch up. We’re not waiting. As we build AI-assisted capabilities into the VNS3 platform (look for Connection Advisor with AI Diagnostics beta availability starting in version 7.1.1), we’re engaged with our auditors now on how SOC 2’s existing Trust Services Criteria apply, specifically to AI-assisted operations, not just human-driven ones.

The questions we’re working through are practical ones: What does change management look like when an AI agent is proposing or applying a network configuration change? What evidence do we need to show that AI-assisted access to customer network state is bounded by the same no-backdoor principle as everything else? What does a defensible audit trail look like for CC7 and CC8 when the actor in the log isn’t a person?

We don’t have all the answers yet, and we won’t publish governance claims ahead of the controls that back them up. What we can say is that we’d rather be raising these questions with our auditor while AI features are still being adopted, building governance in from the start rather than retrofitting it after the fact. That’s the same approach we took in 2008, and again in 2014, and again in 2022. It hasn’t changed.

Crab Boil

Crab Boil

Who is boiling whom?

AI Agents making a human stew.

I feel compelled to defensively say, “I use LLMs every day”.

As I see it there are two extremes at the moment: people who don’t use AI and those who are speed-running OpenClaw, Hermes, et. al..

I am in the middle, allowing Claude Code read permissions on specific private source code repos, asking questions leading to assistance, and then creating pull requests based on the interaction. Maybe “left of center” LLM usage if you will.

I do admire the moxie and spirit of adventure as you get to the speed-running end of the spectrum.  But what is the “quid-pro-quo” of agentic AI?  What mix of artificial intelligence versus “artificial life”?

By artificial life I am referring to the seminal “Game of Life” by John Conway and the subsequent generations of a-life research. Wikipedia has a good overview and some visualizations of the a-life entities moving through 2-dimensional space.  This paper from MIT gives a bit more of thought behind these generative experiments.

My favorite work in this space was the work done by Thomas Ray quite a number of years ago.

From: Tom Ray, “Tierra Photoessay,”

These experiments show life-like characteristics without much of what would be called intelligence. Simple organisms, in a defined space, and a fairly small number of rules controlling the evolution. At the heart of organism success is the ability to claim space and replicate.

I see this behavior happening in agentic AI. The agents are always driving for more resources, essentially the ability to reproduce. Look at what you get done with 2 agents, what if 10, what if 20? Look what you get done with Claude Pro, how about Claude Max, how about $2k per month in Anthropic API tokens. 2 Mac minis, 5 Mac minis, 10 Mac minis. 10 docker containers, 100, 1000!

The process becomes the product.

Lots of code and apps and blogs and videos come out of these agentic flows, certainly some utility. I myself don’t need calorie or fitness trackers, nor digital servants to make meeting or restaurant reservations, but I see the appeal.

However, I don’t see minimization efforts. No mere ‘satisficing’.

I don’t see the refusals.

The agent saying “Let’s not go down that rabbit hole”.

Maybe I am one of the village elders on the ice floe drifting away, but I resonate with the apocryphal quote from Michelangelo about sculpting “Every block of stone has a statue inside it and it is the task of the sculptor to discover it.”

Part of the ‘uncovering’, part of creation is all the things you don’t do.

Likewise, I believe a good piece of software is the result of all the times you said, ‘NO’.

Now that the cost of “doing” is approaching zero, what is the value of the person or process that has the ability to say “don’t do”?

The problem is “Don’t do” flies in the face of “I want more”.

Agentic AI, OpenClaw and its evolutionary relations entreating our friends, families and employees with “Feed me Seymour!” do present opportunities and costs that we will mature in our understanding of, but do create tangible risks today.

Owning our mistakes, “mea culpa” from Cohesive’s CEO

Owning our mistakes, “mea culpa” from Cohesive’s CEO

We owe our customers an apology as a several issues were recently found by the Trend Micro Zero Day Initiative.

Two of them had a high score because of the potential for an unauthenticated user to trigger remote code execution.

(Note: Like with other recent industry exploits, if your control plane access is limited as we advise, then the risks are significantly lower.)

If you follow the CVEs that are released every day, we are not alone, but that is still not an excuse.

While our engineering management and company management are intimately involved in all code changes and releases, as our solution footprint has grown and our responsibilities to our customers have grown, we did not expand some of our processes comensurately.

We have worked with customers since the disclosure getting them patches and new cloud images.

We have added additional code review tools and processes to our releases.

Thank you to Trend Micro ZDI and Mehmet INCE @prodaft for the discovery and working us through the disclosure process. We are grateful for the help from the community to make our products and customers more secure.

Any users of the VNS3 Network Platform who need assistance can always reach us via support@cohesive.net and we will assist with patching and upgrades.
https://cohesive.net/support/security-responses/

– Pat Kerpan
CEO, Cohesive

To agent or not agent, the CrowdStrike question

To agent or not agent, the CrowdStrike question

Some thoughts on the CrowdStrike events at a broad level. We don’t provide the type of capabilities they do, so I don’t feel comfortable inveighing on what happened and how it happened.  But, we do have some thoughts on when to take the risk of deploying agents into your systems.

At Cohesive we have a standard response to customers wanting to install <fill in the blank agent> into our VNS3 Network and Security platform virtual appliances. It is always a difficult situation as it is being pushed by the security team and CISO, at what tends to be our larger, more revenue significant customers. It is difficult because our answer is a polite, yet vehement “no”.

The VNS3 control plane should only be open to an allow-listed operations ingress address. The data plane should be open to the ports and services you use our platform for. (We are often a cloud edge firewall, people vpn, data center vpn, waf, and more.) The biggest liability to the security and operational integrity of our devices would be to add an agent that can be exploited or can itself cause an outage. This has happened in the industry (but not to us) numerous times over the recent years via things like SolarWinds, Microsoft OMS agent, and now CrowdStrike to name a few.

One of the oft-used phrases at Cohesive is “horses for courses” and we use that British idiom as part of our approach to making architectural and deployment security recommendations. With respect to the panoply of agents that vendors and security teams alike argue to be installed in all your systems, we think it is quite apropos. We think you need to look at what the purpose and placement of the computing devices is in order to make this decision.

Seinfeld - His father was a mudder, his mother was a mudder

If it is a computer used by a person, especially hybrid use or remote use, how are are you going to protect it? For the most part you can’t protect the network it is on, since it is running on networks you don’t control.

There are some options outside of agenting, for example if using Windows operating system you could use group policy to force the machine onto a virtual network with no ability to access the Internet other than through your VPN’s edge, but it is bad user experience and expensive to have acceptable points of presence.

And even if forcing users onto a VPN, what about email phishing links and attachments, what about Microsoft Office macro exploits that leak into your shared drives? Super tough, and I am glad we aren’t in that business.

People make mistakes. Even well-trained, diligent people can make mistakes in where they browse to or what they click on, and you need to be able to address possible exploits there at the point of attack. So I can’t really blame someone for wanting to believe these types of products are the answer.

At Cohesive which admittedly is not a huge company, our answer has evolved from ‘Microsoft Office is disallowed’, to now ‘Windows is not allowed’. Right there the “people attack surface” is minimized. However, that is a long migration or a “never migration” for many companies. In these cases, I think “agent away” and be judicious in the vendor you choose.

What about business servers, the computers that are not the personal device of an end-user, but rather are there to perform a function like database or API serving or message queuing? Again, for Cohesive, easier in that Windows is not allowed, business services are built on Linux. That said, whether Windows or Linux, in these scenarios why are you ‘protecting’ the computer instead of the network? Those business servers are not going to click on links, browse bad websites, or download malware. They are automatons performing specific, repetitive operations.

This is where we are skeptical of the agent approach and will not allow it for our network appliances, and as applicable would not allow for business services. (CrowdStrike apparently created a similar issue previously on some Linux distributions: https://www.theregister.com/2024/07/21/crowdstrike_linux_crashes_restoration_tools)

In these cases the VNS3 Network Platform (or similar vendor offerings) is there to protect and monitor ingress and egress to the network, along with other elements of what should be thought of as a security lattice. Using cloud or data center virtualization, you have your cloud network security groups and network ACLs, along with your OS firewall, both of which should be working in tandem with network appliances like VNS3. You can then run WAF or IPS at these ingress/egress points as well – run them inside VNS3 or run them via an appropriate cloud service offering.

We think these are the rules to follow:

  • Computer primarily used by human and it has to be Windows, agent it and anti-virus it.
  • Computer primarily used by human and is Mac or Linux, anti-virus it.
  • Computer used by computers, both micro-segment and protect the network, use a security lattice. The risk from any agents are too high.
  • (OPTIONAL) Computers used by computers are ideally Linux servers using the distributions’ minimal install with at least some elements of CIS hardening.

But then you loudly proclaim, “we need visibility into the VNS3 (or other) appliances for our <DataDog, Syslog Server, SumoLogic, AlertLogic, etc..>!”

OK – you got us. We DO allow visibility to logs, network configuration and statistics, netflow, and some API calls for system status to plugins that run inside VNS3 – but don’t have full host access.

When you are running VNS3 controllers, whether a single one or a larger cluster, you are running a mini “docker cloud” inside your virtual network. We have a set of pre-built plugins as well as a published set of elements needed to make any open source, proprietary source, or commercial source that can be containerized, into a compliant plugin. This gives you the ability to put analysis and monitoring INTO the network, yet not be able to disrupt the network security device; observability with security.

(And now the sound of Cohesive patting itself on the back for this balanced approach to agenting.)

Apple VisionPro – No security issues yet!

Apple VisionPro – No security issues yet!

Cohesive Networks VNS3 6.0 - Clientpacks Page

This front image of the Apple VisionPro augmented reality headset is apt at the moment.

It is dark and we can’t see clearly yet, which is OK, because it allows us the opportunity to prognosticate.

In addition, no network or security issues yet!
We still have time to panic.

Although devices are not a normal topic for us at Cohesive Networks, as CTO, I thought I would ruminate a bit at LinkedIn in a post on The Apple Impact (2023).

Whilst the future is a bit murky, the AI breakout and VisionPro for AR (augmented reality) will combine in interesting ways: compelling, practical, frightening, and unanticipated.

From a Cohesive point of view, as we provide over-the-top networks and security to, through and across the clouds, both of these trends are going to have an impact with Large Language Models deep in the clouds, and augmented reality as the lens from below, piercing the cloud cover.

From a personal point of view:

“Vision Pro emerges at the same time as the artificial intelligence breakout. What will these gods of unknown intention be whispering in our ears? I can’t quite yet imagine these two emergent technologies combined and how it could bring about completely new social environments – with all the good and all the terrible amplified.”

We would love to hear what you think.