Dots are persistent, always-on AI agents that have their own cloud computer and browser and can continue working toward a user’s goals even when that person is not actively sitting in front of ChatGPT. In practical terms, this starts moving us away from the idea of AI as something we simply “chat with” and much closer to AI as something that actually works alongside us.

There are two things about this announcement that immediately stand out to me.

The first is the incredible rate of progress taking place right now across the frontier AI labs. We are no longer talking about new features being introduced every few months in the traditional software-development sense. We are watching the way we interact with AI fundamentally change over periods of weeks and months.

The second is what this means for the growing ecosystem of independent AI agent platforms such as OpenClaw and Hermes, which were built in large part to bridge the gap between a conversational interface like ChatGPT and an always-on intelligent agent that could access the internet, operate a computer, connect to applications, and take actions on your behalf.

I have been experimenting extensively with these kinds of systems over the past several months, and dots makes me wonder how much of that separate agent layer we will ultimately need.

The Speed of Progress Is Hard to Overstate

I have worked in technology for more than two decades, and I cannot remember another period when the capabilities of a major technology platform were changing this dramatically in such short periods of time.

This is not simply a faster software-release cycle. The underlying interaction model is changing.

Only a short time ago, most people thought of ChatGPT as a chatbot. You typed something into a box, it generated a response, and the interaction ended there. Since then, we have seen increasingly capable reasoning models, multimodal interfaces, browsing, coding, tool use, enterprise integrations, computer use, long-running tasks, and now persistent agents.

What makes this particularly striking to me is that I am seeing the progression firsthand in everyday use.

I have been using this technology heavily for the past several years across all kinds of workflows, including research, writing, coding, website maintenance, strategy, analysis, troubleshooting, and automation. One of the things I find most interesting is going back to something I attempted six months earlier and asking a newer model to do the same task.

The difference can be dramatic.

I have used AI to refresh old website code and content, troubleshoot problems, reason through decisions, build tools, and create new material. When I revisit those same kinds of tasks months later, the model often approaches the problem completely differently. The reasoning is stronger, the conclusions are better, the output requires less correction, and the system is capable of handling work that previously required much more guidance.

That is what makes the progress feel so real to me. It is not a benchmark chart or a research paper. I can see the difference directly in the quality of the work.

Why I Started Experimenting With OpenClaw and Hermes

Over the past several months, I have been sharing some of the experimentation I have been doing with OpenClaw and Hermes, using cloud LLMs from OpenAI, Anthropic, and Google to power different kinds of agents.

The attraction of these platforms was that they could do things that a traditional chat interface could not.

I could create agents that behaved more like persistent digital workers. I have experimented with using them as:

• a coder
• an executive assistant
• a brand manager
• a research assistant
• a digital tutor for my kids

I have also experimented with connecting them to messaging platforms such as Telegram, and I have been working on a similar setup through Discord.

The idea is compelling because instead of opening ChatGPT and starting another conversation, you can have an agent that is always available, has access to specific tools and instructions, and can perform work independently.

For a while, that represented a meaningful difference between an external agent platform and ChatGPT itself.

But something interesting has started happening in my own workflow.

I Have Already Started Moving Work Back Into ChatGPT

Even before the dots announcement, I had gradually started using my OpenClaw agents less for certain kinds of work and moving more of that activity back into ChatGPT.

One reason is that OpenAI has been steadily adding capabilities that previously required a separate agent platform.

Google Workspace integration is a good example. I created a dedicated Google account that I connected to ChatGPT, and I share documents into that environment from my primary account. That allows me to work with ChatGPT directly on documents, research, drafts, and other materials stored in Google Drive.

In practice, it increasingly feels like collaborating with an always-available member of staff.

OpenClaw was already capable of doing similar things, but as ChatGPT has added more integrations and tools, I have found myself asking a very practical question: why introduce another layer if the platform I already use every day can do the same work more easily?

There is also another advantage ChatGPT has that is much harder for a newer agent to replicate: history and context.

I was one of the early ChatGPT users, signing up within the first few days after it launched, and I have been using it heavily ever since. Over that time, ChatGPT has accumulated years of context around how I think, how I write, the kinds of work I do, my preferences, my strengths, and even some of my weaknesses.

That makes a huge difference.

If I ask ChatGPT to help me write about a topic, think through an idea, or challenge an assumption, I do not have to start from zero. It already understands a great deal about how I approach things.

My OpenClaw agents do not have that same depth of history.

I can export summaries, create markdown files, give them context documents, and keep feeding them more information, but it still is not quite the same.

The analogy I keep coming back to is the difference between asking for advice from a friend you have known since high school and asking someone you met at a networking event six months ago. Both people may be intelligent and capable, but one of them simply knows you better.

I think this idea of accumulated personal context is going to become one of the most important competitive advantages in AI over time.

This Is Where Dots Gets Really Interesting

Up until now, there were still some things that my external agents could do that felt fundamentally different from the ChatGPT experience.

They could remain active. They could operate in their own environment. They could continue performing work when I was not there. They could monitor systems, interact with applications, and behave more like persistent digital workers than conversational tools.

Dots goes directly after that gap.

That is what makes this announcement so important.

OpenAI is taking a model of computing that technically inclined users have been building themselves using tools like OpenClaw and Hermes and turning it into something that can potentially be used by a much broader audience.

If OpenAI can make that experience simple enough, the question changes from:

Can I build my own autonomous AI agent?

to:

Why would I build and maintain one separately if my primary AI platform already gives me one?

That does not mean platforms like OpenClaw or Hermes suddenly become irrelevant. They will still have advantages for people who want more control over the infrastructure, different underlying models, specialized integrations, custom orchestration, or the ability to operate in environments they completely own.

But the competitive line is clearly moving.

And it is moving fast.

Personal AI Context May Become More Important Than the Model Itself

There is another aspect of this evolution that I think gets less attention than it deserves.

For the past several years, much of the AI conversation has focused on model capability. Which model is smartest? Which one codes best? Which one scores highest on a benchmark? Which one has the largest context window?

Those things matter, but I think another factor will become increasingly important: how well the AI knows the person using it.

Imagine an AI assistant that has worked alongside you for ten or twenty years. It understands how you communicate, how you make decisions, what you value, what you struggle with, what you have tried before, and what has worked or failed in the past.

That kind of accumulated knowledge becomes incredibly powerful.

This is also where I think the future becomes particularly interesting for children growing up today.

A child born now could conceivably have a digital companion that grows alongside them for decades. It could remember their experiences, understand their learning style, know where they struggled in school, recognize patterns in their development, and help them navigate decisions over the course of their life.

Eventually, that intelligence may not live only on a screen. As humanoid robotics progresses, some of these systems will increasingly be embodied in physical machines.

That may sound extreme today, but the trajectory is becoming much easier to imagine than it was even a few years ago.

I Keep Thinking Back to a Conversation I Heard in 2015

All of this keeps bringing me back to an experience I had while working at Fast Retailing.

Each year, Fast Retailing held a major two-day company conference at Pacifico Yokohama in Japan. The auditorium holds roughly 5,000 people, and we would fill the hall with corporate staff and retail frontline employees from Japan and abroad.

Tadashi Yanai, the founder of Fast Retailing and UNIQLO, was close to Masayoshi Son, the founder of SoftBank. Yanai also served on SoftBank’s board.

At one of these conferences in 2015, Yanai invited Masa Son to participate in a fireside conversation.

I still remember the session very clearly.

Masa was standing in front of thousands of retail employees talking about artificial intelligence, robotics, and the technological singularity.

This was 2015.

We were not regularly using terms like AGI and ASI in everyday business conversations the way we are today. But the underlying ideas were already being discussed.

One thing in particular has stuck with me: Masa said he believed we could reach singularity around 2030.

At the time, that sounded incredibly far-fetched and almost science fiction.

Today, it feels very different.

Given the rate of progress we have seen just over the last several years, I find myself wondering whether his prediction may prove to be surprisingly close, even if our eventual definition of “singularity” turns out to be different from what people imagined in 2015.

We are now only a few years away from 2030.

When I think about where AI capabilities were in 2022 compared with where they are today, it becomes difficult to confidently say that something like this is decades away.

What Does “Singularity” Even Mean?

There are several definitions of the technological singularity, but the general idea is a point at which artificial intelligence becomes capable enough, and technological progress becomes rapid enough, that the future beyond that point becomes extremely difficult to predict.

Often, the concept also includes some form of recursive improvement, where AI systems begin contributing significantly to the development of better AI systems.

That does not necessarily mean that one morning an AI system suddenly becomes all-knowing and humanity wakes up in a science-fiction movie.

The transition may be much less obvious than that.

In fact, one of my personal beliefs is that we may cross important thresholds, like achieving AGI and ASI, long before we collectively agree or even think we have crossed them. Once the machines achieve that level of intelligence, do you think they will make it obvious that they have?

The debate about AGI is already showing signs of this problem. There is no single universally accepted definition, and different people will move the goalposts depending on what systems can already do.

We could very well reach some meaningful version of AGI and spend the following six months arguing about whether it “really counts.”

I do not know when AGI, ASI, or anything we would call the singularity will arrive. I am skeptical of anyone who claims to know the exact date.

But I also would not assume we are safely many years away.

The rate of improvement makes that assumption increasingly difficult to defend.

AI Is Already Helping Build the Next Generation of AI

One of the more interesting signals is what is happening inside the frontier AI labs themselves.

Anthropic has said that a very large share of the code going into its own systems is now being written with the help of Claude. That does not mean AI is autonomously rebuilding itself without human involvement, and it would be a mistake to overstate the significance.

But the direction is still notable.

AI systems are increasingly helping engineers write the code used to build and improve AI systems.

That begins to resemble at least one part of the recursive-improvement idea that people have associated with the singularity for decades.

And this is where the speed becomes so important.

If better AI helps people build better AI faster, and those improved systems then help build the next generation even faster, the development cycle itself begins to compress.

We may already be seeing the early stages of that feedback loop.

The Bigger Question Is Not Whether Dots Wins

Dots may become an enormous success, or it may simply be one more step toward whatever comes next.

To me, the important part is what it represents.

A capability that recently required technically sophisticated users to stitch together language models, computers, browsers, APIs, messaging platforms, integrations, permissions, and agent frameworks is rapidly becoming something that mainstream users may simply be able to turn on.

That pattern has repeated itself throughout the last several years of AI.

Capabilities that begin at the frontier quickly become product features.

Those product features become platforms.

And those platforms increasingly start performing work that previously required humans to operate software themselves.

For technology leaders, that creates a much bigger strategic question than simply asking, “How should we use generative AI?”

The emerging question is:

What happens when every employee, every function, and eventually every customer can have persistent intelligence working on their behalf?

That question touches almost every part of enterprise technology: operating models, cybersecurity, identity, governance, data, enterprise architecture, software development, talent, workforce planning, and the future of work itself.

I do not pretend to know exactly where this ends.

But I keep coming back to that conversation I heard from Masa Son in 2015.

At the time, 2030 sounded incredibly far away.

Today, watching the rate at which these systems are evolving, it suddenly does not feel very far away at all.

The post OpenAI’s Dots and the Incredible Speed at Which AI Is Changing appeared first on Joshua Bellendir.

It was a wonderful evening celebrating the people behind the technology organization supporting the 5th largest school district in the country. But what stood out to me most was getting to see firsthand the culture Mugunth is building and the care he puts into recognizing his team.

The evening wasn’t simply about awards. It was about making people feel seen and appreciated. Team members were recognized for their contributions, families were thanked for the support and sacrifices that often happen behind the scenes, and CCSD’s summer student interns were included as part of the celebration and the future of the profession.

One message from the evening particularly stayed with me: Ubuntu, “I am what I am because of you.”

It is a powerful reminder that leadership is ultimately about people. The technology matters. The transformation matters. The results matter. But none of it happens without the people behind it.

Congratulations to Mugunth, the entire TISS organization, all of the nominees and award recipients, and everyone who helped make the evening possible.

And thank you, Mugunth, for inviting me to be part of such a meaningful celebration. I especially loved the parting gift. The “Be Both. Human + Kind.” mug is already getting good use during my morning coffee and a little quiet writing and reflection.

Be Both. Human + Kind.

#Leadership #CIO #TechnologyLeadership #ITLeadership #Culture #Recognition #ClarkCountySchoolDistrict

The post Leadership Is About People: Lessons from the CCSD TISS Spotlight on Excellence Awards appeared first on Joshua Bellendir.

The POS terminal remains one of the most under-modernized pieces of technology in retail. Many checkout environments are still built on architecture dating back to the early 2000s, while customer expectations have evolved dramatically.

Over the past two decades, I’ve spent much of my career helping retailers modernize complex technology environments, most recently as CIO of WHSmith North America, supporting more than 350 locations, and previously in senior technology leadership roles with Fast Retailing / UNIQLO, SoftBank Robotics, Abercrombie & Fitch, and Deloitte.

So I’m excited to share that I’ve joined MishiPay as a Strategic Advisor, working with Mustafa Khanwala and the team in an advisory capacity on US market growth, positioning, and engagement with retailers as they rethink checkout and modernize legacy POS environments.

What drew me to MishiPay is the pragmatism of the approach. Retailers shouldn’t have to rip out their entire POS estate simply to deliver a more modern checkout experience.

That challenge is very real across retail today, and I think there is a significant opportunity to help organizations modernize incrementally while protecting the investments they’ve already made.

If you’re a retail executive or technology leader thinking about the future of checkout, modernizing a legacy POS environment, or simply trying to remove POS constraints from your roadmap, we’d welcome the conversation.

The post I’ve Joined MishiPay as a Strategic Advisor appeared first on Joshua Bellendir.

My wife did not click a phishing link.

She did not share her password.

She did not approve an unexpected login or read an MFA code to a stranger.

In fact, she never interacted with the attacker at all.

Her PayPal account was still taken over.

The opening was a phone number she had stopped using years earlier.

According to multiple PayPal fraud representatives, the attacker reset her password using two recovery checks: an SMS message and a WhatsApp message.

Both were tied to the same retired phone number.

That is the part of this story that should matter to anyone who has ever changed a phone number, retired an email address, replaced a credit card, or simply forgotten about an old online account.

It should also matter to the people designing authentication, fraud, and recovery systems.

I have spent much of my career in CIO and cybersecurity leadership roles. When this happened at home, the incident responder in me took over. I wanted to know four things: What happened? How did the attacker get in? What persistence had they established? And what had to change so it could not happen again?

What followed became a useful reminder that security failures are rarely about one bad password. They are often about old identity data, weak recovery logic, and the gap between restoring a user’s access and actually removing an adversary from an account.

The forgotten number

A few years ago, my wife changed her Google Voice number. She no longer used it, and like most people, she did not maintain a master inventory showing every online account that still referenced it.

That matters because the modern household has an identity inventory problem.

Most of us have accumulated hundreds of online accounts over many years. As our lives progress, we change phone numbers, change jobs, move homes, replace cards, retire email addresses, and forget about services we rarely use. But those old identifiers do not always disappear from the accounts that once depended on them.

In this case, the retired number remained associated with an old PayPal account that my wife had not logged into for years.

My wife had done many of the things security professionals tell people to do. She uses unique passwords, a password manager, MFA, and passkeys where available. None of those controls helped with an account-recovery path tied to a phone number she no longer controlled.

The first warning arrived quietly: an email saying her PayPal password had been reset.

It went unnoticed and unread in her inbox.

That is not unusual. Personal inboxes are noisy. And anyone who works in security knows the irony: PayPal-themed phishing is so common that legitimate PayPal security messages can resemble the very messages people have been trained not to trust.

About a week later, while catching up on unread emails, my wife noticed the earlier PayPal password-reset notification along with a newer PayPal email for a payment she did not recognize. She asked whether I knew anything about it.

My first thought was phishing.

It was not.

We opened PayPal directly rather than clicking anything in the email. The transaction was real. The account had been compromised.

At that point, the payment stopped being the problem.

It was evidence.

The account was the incident.

The incident responder in me took over

Having led organizations through cybersecurity incidents, I immediately shifted into crisis-response mode. My wife could still get into the account using a legitimate passkey that the attacker had not removed. That was fortunate, because it gave us visibility into the state of the account before speaking with PayPal’s fraud team.

Once inside, I approached it the way I would approach a compromised enterprise identity: establish the timeline, assume persistence, review every trust relationship, remove anything that could allow re-entry, and only then rebuild trusted access.

We found exactly what I would expect an attacker to establish after gaining control:

• A passkey we did not recognize.
• Multiple OneTouch auto-login authorizations that were not hers.
• Multiple unfamiliar Android device sessions.
• Changes to authentication and trusted-access relationships that could allow the attacker to return.

The attacker had done more than change the password. These screenshots show the additional persistence we found inside the account: registered passkeys, OneTouch auto-login authorizations, and approved device sessions. Most of the entries shown were unfamiliar and did not belong to my wife, reinforcing why a password reset alone is not enough to contain an account takeover.

That is the part of account takeover many consumers never see. Once inside, an attacker may establish persistence through trusted devices, sessions, passkeys, or other authentication methods that survive a password reset.

Recovery gives the legitimate owner access again.

Containment removes the adversary.

We reset the password, reviewed authentication methods, removed the unauthorized passkey, cleared unfamiliar sessions and devices, removed OneTouch authorizations we did not recognize, re-established trusted authentication, and reviewed the account for other unauthorized changes.

As far as we could determine, there were no additional unauthorized transactions beyond those already identified. PayPal reversed the unauthorized payment quickly, and there was no financial loss. That part of the response was fast and effective.

But I still did not know how the attacker got in.

And until you know that, you do not know what else you should consider compromised.

How did they get in?

This became the investigative part of the incident.

I called PayPal’s fraud department repeatedly because the answer mattered. If the attacker had compromised my wife’s email account, I needed to respond to that. If they had used an old credit card, I wanted to understand that exposure. If they had answered security questions, that suggested a different problem again.

The first explanation we received was vague and initially pointed us in the wrong direction. A representative referred to my wife’s email address and the forgot-password process, which left open the possibility that the email account itself had been compromised.

So I kept asking.

On a later call, a PayPal fraud representative confirmed the recovery methods used in the actual takeover.

The attacker had initiated PayPal’s “Forgot password” process using my wife’s email address as the account identifier.

Then, according to the representative, the attacker used “Get a Text” as one recovery check and “Get a WhatsApp Text” as the other.

Both went to the same retired number.

I did not rely on that one conversation. We subsequently confirmed the same recovery sequence with additional PayPal fraud representatives, including a supervisor. One representative also confirmed that no email code, credit card number, or security-question response was used. This narrowed the reset path to the SMS and WhatsApp checks tied to the retired number.

That changed the entire understanding of the incident.

At the time of the incident, the PayPal recovery screen we observed presented several options, including SMS, WhatsApp, security questions, and confirmation of a credit card number.

The problem was allowing SMS and WhatsApp associated with the same telephone number to satisfy successive recovery checks.

From a security-design standpoint, those are not independent factors. Two interfaces are not two independent controls when compromising the same underlying asset defeats both.

Based on what PayPal’s representatives told us, that was the path used to reset my wife’s password. Had the recovery process required genuinely independent evidence, this specific takeover path would not have worked.

Large-scale breaches involving companies such as Equifax, Marriott, Meta, Ticketmaster, and Change Healthcare have exposed enormous volumes of personal information, including names, email addresses, phone numbers, physical addresses, dates of birth, payment information, and other identity data.

I do not know how the attacker connected my wife’s retired phone number to her PayPal login, and I do not want to speculate about a specific source or technique. But pieces of our identity now exist across an enormous number of systems, and once that data is exposed, scraped, brokered, or stolen, attackers can potentially connect relationships we may have forgotten ourselves.

What I reported to PayPal and what appears to have changed

Once I understood the recovery path, I told PayPal’s fraud team that I believed the same-number recovery logic represented a serious security weakness and asked that it be escalated.

PayPal never provided me with a written technical explanation of what it changed or when.

But something changed.

When I tested the flow a few days after reporting the issue, I could not reproduce the SMS-then-WhatsApp sequence. After completing SMS verification, WhatsApp tied to that same number was no longer available as the next recovery check. I also tested the behavior using several other accounts available to me and could not reproduce the earlier sequence.

A PayPal fraud representative later told me the recovery concern had been escalated to its technical team and thanked me for bringing it to their attention, noting that it could affect other users as well. She also indicated that the earlier recovery flow was no longer available at that time and said the matter had been taken very seriously.

That deserves credit.

If the control was changed in response to this incident, PayPal moved quickly.

But quick remediation should not obscure the underlying lesson: the recovery design should not have allowed two channels dependent on the same telephone number to function as independent assurance in the first place.

For security and technology leaders, the lesson is simple: adding another verification step does not automatically add security. If the same underlying compromise defeats both, the system may look layered while still depending on a single point of failure.

The bigger problem I still think PayPal needs to solve

The specific recovery weakness we observed appears to have been addressed.

The customer account-takeover support experience is what still concerns me.

During our initial fraud-support calls, the focus was primarily on the unauthorized transaction, the password, and whether my wife could get back into the account.

No representative proactively initiated a comprehensive reset of the account’s trust relationships. We were not immediately guided through every active session, passkey, OneTouch authorization, trusted device, and authentication method. We discovered and removed the broader persistence mechanisms ourselves. It was only after I asked whether PayPal normally helps customers review those areas that a representative offered to walk us through some of the checks.

That may sound like a support-process issue. It is actually a security-control issue.

Imagine the account holder was not married to someone who has spent years dealing with cybersecurity incidents.

Imagine it was your mother.

Your grandfather.

Your aunt or uncle.

The fraudulent payment gets reversed. The password is changed. A fraud representative confirms that the user can log in again.

Would that person know to inspect registered passkeys?

Would they know what OneTouch is?

Would they know to terminate every unfamiliar session and trusted device?

Would they know which MFA methods should be removed and re-enrolled?

Should they have to?

They should not.

A confirmed account takeover should trigger a repeatable containment workflow that returns the account to a known-good state. Active sessions should be terminated, newly added authentication methods and trusted devices reviewed or revoked, recovery information verified, and the legitimate owner helped to rebuild trusted access.

PayPal did an excellent job of quickly reversing the unauthorized charges and recovering the funds, but fixing the transaction is not the same as securing the account.

Security has to work for the least technical legitimate customer while still being difficult for the most capable attacker.

The bigger lesson: your digital identity has an inventory problem

The most important lesson I took from this incident is not actually about PayPal.

It is about how we manage digital identity over time.

Phone numbers, email addresses, postal addresses, payment cards, recovery emails, and authentication methods are no longer merely contact details.

They are identity infrastructure.

Online services use them to decide who we are, how we recover accounts, and sometimes whether we should be allowed to reset credentials.

But most households do not maintain an inventory of that infrastructure.

We should.

I am a strong advocate of password managers, but I think we need to use them for more than passwords. Treat your password manager as a lightweight inventory of the identity information attached to your important accounts.

For financial, medical, government, cloud-storage, primary email, and other sensitive accounts, record at least:

• The registered email address.
• The registered phone number.
• Any recovery email address or phone number.
• The postal address on file when relevant.
• The MFA method in use.
• Any important payment or identity information the service relies upon for recovery.

Then make one behavior routine:

Whenever you change a phone number, retire an email address, move homes, or replace an identity anchor, search the password manager for the old value and update every account that still depends on it.

That simple practice would have identified this old PayPal association before an attacker did.

The security basics still matter

This incident does not mean passwords, MFA, passkeys, or password managers failed. It demonstrates why security has to be managed as a lifecycle rather than a one-time setup.

Use strong authentication, keep recovery information current, review trusted devices and active sessions on sensitive accounts, and treat unexpected password-reset messages as incidents until proven otherwise.

Most importantly, when you retire a phone number or email address, do not assume the risk retires with it.

Security leadership starts at home

Executives and security leaders spend enormous amounts of time talking about identity governance, asset inventories, layered controls, incident response, root-cause analysis, and lessons learned.

Those principles do not stop at the office door.

Our households are small digital enterprises. They contain financial information, health records, identity documents, cloud accounts, personal communications, and the people we care most about.

This incident ended well. PayPal reversed the unauthorized transaction. We contained the account. The specific recovery sequence involved in the takeover appears to have been changed after I raised it. Those are meaningful positives.

But the incident should never have been possible through the recovery path PayPal’s representatives described to us.

And a customer who reports a confirmed takeover should not need cybersecurity expertise to make sure the attacker has truly been removed.

That is where I believe PayPal, and every company responsible for sensitive consumer identities, should keep improving.

If you do one thing after reading this, open your password manager today and search for every old phone number and email address you can remember.

The account you forgot about may be the one an attacker finds first.

Joshua Bellendir is a technology executive and advisor with global CIO and cybersecurity leadership experience across retail, technology, and consumer businesses.

The post Two Recovery Checks. One Retired Phone Number. A PayPal Account Takeover. appeared first on Joshua Bellendir.

That idea was at the center of a recent CIO.com article by Mary K. Pratt on the strategic trade-offs CIOs are navigating today. I was grateful to be included in the discussion alongside a thoughtful group of technology leaders, and the topic is one I believe deserves more attention.

Every business wants to move faster. Executives want new digital capabilities, better customer experiences, more automation, AI-enabled workflows, and faster access to data. Those expectations are reasonable. Technology should help the business grow, adapt, and compete.

But speed only creates lasting value when the underlying technology foundation is reliable.

Customers and employees expect technology to work every day. They expect systems to be available, secure, responsive, and intuitive. When the foundation is unstable, innovation slows down because confidence erodes. Teams become more cautious. Business leaders hesitate to invest in new capabilities. Technology organizations spend more time reacting than advancing.

At the same time, avoiding modernization is not a resilience strategy.

Aging platforms may feel stable because they are familiar, but over time they often become harder to support, secure, integrate, and scale. The longer modernization is deferred, the more operational risk accumulates beneath the surface. Eventually, the organization finds itself trying to innovate on top of systems that were not built for the pace, complexity, or expectations of the modern business.

That is why I view innovation and operational resilience as interdependent rather than competing priorities.

Innovation introduces change, and change introduces risk. The answer is not to slow innovation for the sake of stability. The answer is to create the discipline, governance, architecture, and operating standards that allow the business to innovate with confidence.

In practical terms, that means piloting quickly, learning quickly, and being deliberate about what moves into enterprise-scale operations. It means creating space for experimentation while maintaining disciplined production standards. It means modernizing core platforms before they become constraints. And it means treating reliability as a strategic business capability, not just an IT metric.

During my time as CIO at WHSmith North America, we faced this balance directly while modernizing core retail platforms and upgrading store technology across a large retail footprint, including high-volume locations in some of the busiest transportation hubs in North America. Those initiatives were critical to positioning the business for future growth, but they also required careful execution to protect reliable day-to-day operations.

That is the balancing act many CIOs are managing now: helping the business move faster while making sure the foundation can support that speed.

The organizations that get this right do not frame resilience as an obstacle to innovation. They frame it as an enabler. The executive conversation shifts from “How do we reduce risk?” to “How do we create the confidence to move faster?”

That shift matters.

As AI, automation, cloud platforms, data products, and digital customer experiences become more deeply embedded in business strategy, technology leaders will continue to face pressure to accelerate. But sustainable acceleration depends on trust. Trust in the systems. Trust in the data. Trust in the security model. Trust in the team’s ability to move quickly without creating unnecessary fragility.

That trust is built through operational discipline.

Mary’s CIO.com article does a great job bringing together a range of perspectives on the trade-offs technology leaders are facing, including innovation, resilience, risk management, data protection, organizational readiness, and AI cost. It is worth reading for anyone thinking about how the CIO role continues to evolve.

Read the full article here:

https://www.cio.com/article/4201338/6-strategic-trade-offs-cios-cant-afford-to-get-wrong.html

The post Quoted in CIO.com | 6 strategic trade-offs CIOs can’t afford to get wrong appeared first on Joshua Bellendir.

Google Drive integration with ChatGPT is a good example.

Giving an AI assistant access to Google Drive can make it significantly more useful. It can reference documents, find information across files, and, depending on the capabilities enabled, perform actions involving Google Docs, Sheets, Slides, and other Drive files.

But there is an obvious question:

Do I really want to connect my primary Google account and potentially expose my entire Drive?

For me, the answer is no.

Instead, I am using a simple isolation pattern: create a separate Google account specifically for AI agents, then deliberately share files and folders with that account from my primary Google Drive.

I call this secondary account the Agent account.

The Basic Architecture

The model is straightforward:

Primary Google Account → Shared Files/Folders → Agent Google Account → ChatGPT

My primary Google account remains the system of record.

The Agent account only has access to documents that I have explicitly shared with it.

ChatGPT is then connected to the Agent account rather than my primary account.

This creates a simple but useful security boundary.

Instead of asking:

What files in my Drive can ChatGPT access?

I can ask:

What have I intentionally shared with the Agent account?

That is a much easier question to answer.

Why I Prefer This Approach

When connecting Google Drive directly to ChatGPT, the authorization can be broad.

OpenAI’s current documentation says that Google Drive integrations can request read access across Drive and, when Drive actions are enabled, can request permissions that support creating, updating, moving, sharing, copying, uploading, and deleting Drive-family files.

That level of integration is useful, but I don’t necessarily want to provide it against the Google account containing everything I have accumulated over many years.

So rather than relying exclusively on application-level permissions, I am creating an identity-level boundary.

The Agent account simply cannot access files that have never been shared with it.

That gives the human operator an additional layer of control.

Step 1: Create a Dedicated Google Account

Create a secondary Google account that will be used exclusively for AI integrations.

For example:

yourname.agent@gmail.com

or

company.ai.agent@gmail.com

The exact naming convention doesn’t matter.

What matters is that this account is not your normal Google account.

Do not use it for regular email, personal photos, browser synchronization, financial records, or other day-to-day activities.

Think of it as a service identity for AI.

Step 2: Keep Your Primary Drive as the Source of Truth

There is no need to migrate everything into the Agent account.

Continue creating and managing files from your normal Google account.

Your existing ownership model remains unchanged.

Instead, selectively share material with the Agent account just as you would share a document with another person.

For example, I might eventually share folders such as:

• Professional career and resume notes
• Company research
• Project documentation
• Blog posts and ideas
• Reference material
• Working documents I routinely use with ChatGPT

But I would not automatically share my entire Drive.

Step 3: Grant Access Deliberately

This is the most important part of the model.

When I want ChatGPT to work with something, I grant the Agent account access to it.

If ChatGPT only needs to reference information, I can give the Agent account Viewer access.

If I want ChatGPT to eventually modify or update a document, the Agent account will need the appropriate Editor permissions.

This turns AI data access into an intentional action.

No sharing means no access through the Agent account.

Over time, the Agent account will gain access to more and more information. That is expected.

The important distinction is that access grows deliberately rather than implicitly.

Every folder and file permission represents a conscious decision:

I am comfortable making this information available to my AI tools.

Step 4: Connect the Agent Account to ChatGPT

In ChatGPT, open the app or plugin settings and locate the Google Drive integration.

Choose Connect and authenticate using the Agent Google account, not your primary account.

Be especially careful here if you are already signed into multiple Google accounts in your browser. Google will typically present an account-selection screen during authorization.

Verify the email address before approving access.

Once connected, ChatGPT’s Google Drive access is associated with the Agent account.

According to OpenAI, ChatGPT respects the permissions of the Google account being connected. In other words, it can only access content available to that Google identity.

That is exactly what makes this architecture useful.

Step 5: Start Small

I would not immediately share twenty years of documents with the Agent account.

Start with one test folder.

For example:

AI Working Files

Put a few non-sensitive documents in it and share the folder with the Agent account.

Then test things such as:

• Find a particular document
• Summarize it
• Compare two documents
• Extract information
• Update a working document, if write actions are enabled
• Verify that files outside the shared scope cannot be found through the Agent account

Once you are comfortable with the behavior, expand access gradually.

A Useful Folder Model

One approach is to create a dedicated folder hierarchy in your primary Drive:

AI Shared

• Career
• Research
• Projects
• Reference
• Working Documents
• Temporary

Then share the parent folder, selected child folders, or individual documents with the Agent account depending on how much access you want to provide.

There is no single correct structure.

The important part is that the folder hierarchy makes the access boundary visible and understandable to a human being.

This Is Really a Least-Privilege Pattern

The principle behind this approach is not unique to ChatGPT.

It is a basic cybersecurity concept: Least privilege.

An identity should receive only the access necessary to perform its function.

We routinely apply this concept to employees, service accounts, applications, databases, APIs, and cloud infrastructure.

AI agents should be treated the same way.

As agents become capable of reading, creating, updating, and taking action across enterprise systems, identity and authorization become increasingly important.

The question should not be:

Can the AI access this system?

It should be:

Which identity is the AI using, what can that identity access, and why?

The Human Remains the Gatekeeper

One of the things I particularly like about this model is that it keeps the human operator directly involved in expanding the agent’s knowledge environment.

When I decide ChatGPT would benefit from another folder, I share it.

When a project ends, I can remove access.

When I want an agent to reference something but not modify it, I can use read-only permissions.

The Agent account becomes a practical representation of the information environment I have chosen to expose to AI.

And because Google Drive already has mature sharing and permission controls, I don’t need to invent an entirely new governance mechanism.

Important Limitations

This approach should not be interpreted as a perfect security sandbox.

Connecting an external application to a Google account still means granting that application OAuth permissions. You should review the permissions Google presents during authorization and understand what capabilities you are enabling.

OpenAI also notes that connected Google content may be indexed and synchronized to improve retrieval, depending on the integration and configuration being used. Disconnecting the app removes the connection, although associated indexed content may be retained temporarily according to OpenAI’s data retention policies.

Organizations using ChatGPT Business, Enterprise, or Edu may also have more sophisticated administrative options, including controls that can limit synced Google Drive access to particular Shared Drives or folders.

For an individual user, however, the secondary-account model provides an additional boundary that is simple to understand and easy to manage.

A Simple Mental Model

I think about it this way:

My primary Google account represents everything I know.

My Agent account represents everything I have intentionally decided my AI agents are allowed to know.

That distinction will become increasingly important.

Today we are talking about Google Drive.

Tomorrow it may be email, calendars, project-management platforms, financial systems, CRM applications, source-code repositories, and internal company knowledge.

As AI moves from answering questions to actually performing work, giving agents unrestricted access to our digital environments is unlikely to be the right model.

A better approach is to progressively grant access based on need.

Start small.

Observe what the agent can do.

Add information and permissions deliberately.

And always maintain a clear understanding of which identity your AI is operating through and what that identity can access.

The post A Safer Way to Connect Google Drive to ChatGPT: Use an Isolated Agent Account appeared first on Joshua Bellendir.

For years, the cloud conversation centered largely on agility, scalability, and cost optimization. Those benefits remain important, but the decisions facing technology leaders today extend well beyond infrastructure.

As I shared with CIO.com:

“Today, we are balancing a much broader and more complicated set of considerations, including AI readiness, cybersecurity, data governance, sovereign data requirements, edge computing, integration architecture, and operational resilience.”

This is an important evolution. Cloud strategy can no longer be separated from enterprise architecture, data strategy, cybersecurity, or the broader business transformation agenda.

From Cloud Migration to Cloud Optimization

Many enterprises have already completed significant portions of their initial cloud journeys. The challenge now is determining how to operate those environments more effectively.

That means continually asking whether workloads are running in the right environment, whether costs remain aligned with business value, whether data and security controls are keeping pace, and whether the architecture can support emerging requirements such as AI.

AI makes these questions even more important. Scaling AI and advanced analytics introduces significant demands around compute, data architecture, governance, security, integration, and cost. Simply adding more cloud capacity is not a strategy.

The Importance of Governance and Discipline

The next stage of cloud maturity requires stronger operational and financial discipline.

Organizations need greater visibility into cloud consumption and costs, clear architectural standards, strong cybersecurity controls, effective observability, and mature data governance. Cloud decisions should ultimately be tied to measurable business outcomes rather than technology adoption for its own sake.

The goal is not to become “more cloud.” The goal is to create an adaptable technology architecture that allows the business to move faster while maintaining the appropriate balance of cost, resilience, security, and control.

That distinction will become increasingly important as AI accelerates the demands being placed on enterprise technology environments.

Esther’s CIO.com article explores these challenges through perspectives from several technology leaders and is well worth the read.

Read the full CIO.com article: Cloud Strategies Have Become More Complicated Than Ever

The post Quoted in CIO.com | Cloud Strategy Is No Longer Just an Infrastructure Decision appeared first on Joshua Bellendir.

The post Celebrating Southern Nevada’s Technology Leaders: 2026 Top Tech Awards Nominations Are Open appeared first on Joshua Bellendir.

The basic architecture is:

• Twilio provides the phone number and call transport.
• OpenClaw runs the local voice-call webhook.
• ngrok exposes that local webhook to Twilio over a public HTTPS URL.
• OpenAI realtime voice makes the call behave like a live conversation.

What You Need

• A working OpenClaw install
• A Twilio account
• A Twilio voice-capable phone number
• Your Twilio Account SID and Auth Token
• An ngrok account and auth token
• OpenAI/OpenClaw auth capable of using OpenAI realtime voice

If you are using a Twilio trial account, Twilio may play a trial-account prompt before connecting the call. During testing, press the key Twilio asks for so the call continues into OpenClaw.

Step 1. Get A Twilio Phone Number

Create or log into your Twilio account: https://console.twilio.com/dashboard

From the Twilio dashboard, find or purchase a voice-capable phone number.

You will need:

• Twilio phone number
• Twilio Account SID
• Twilio Auth Token

Step 2. Enable The Voice Call Plugin In OpenClaw

Run the OpenClaw onboarding/configuration wizard. Launch the terminal app and run the following command:

openclaw onboard

Enable the Voice Call plugin under the plugin/skills section of the onboarding wizard.

Select Twilio as your provider

When prompted for the Twilio phone number, enter your Twilio number in E.164 format (e.g., +13101112222) in the From Number field

When prompted for inbound policy, start with:

allowlist

Then add only your own phone number to the allowlist. This prevents random callers from reaching your agent while you are testing.

When prompted for the Twilio Account SID, paste the Account SID from the Twilio dashboard.

After you provide the SID and hit enter, you will receive a sensitive field notice, like below. You will need to run this after we complete the onboarding wizard.

Select conversation as the default call mode.

If the wizard asks for webhook host/port before ngrok is configured, use local values for now:

Webhook host: 127.0.0.1
Webhook port: 3334

For session scope, select per-phone. This is so the conversation continues across calls. You would use per-call if you were configuring this as a call center, where each conversation starts fresh with each call.

Select per-phone

That should have been the last question. Finish the wizard. If it asks how you want to launch/hatch the bot and you are not ready yet, choose the “do this later” option.

Step 3. Add The Twilio Auth Token

After the wizard completes, add your Twilio Auth Token:

openclaw config set plugins.entries.voice-call.config.twilio.authToken <TWILIO_AUTH_TOKEN>

Replace <TWILIO_AUTH_TOKEN> with the token from your Twilio dashboard.

Do not publish this token in screenshots, blog comments, GitHub issues, or logs.

Restart the OpenClaw Gateway:

openclaw gateway restart

Then check the Voice Call plugin setup by running this command:

openclaw voicecall setup

You want the setup checks to pass before moving on. You will most likely notice that it falls the webhook check. You should see something similar to the below screenshot. Which is expected. We will configure the webhook in step 4.

Step 4. Configure ngrok For The Public Webhook

Twilio cannot reach a webhook on 127.0.0.1 from the public internet. Your local OpenClaw instance needs a public HTTPS URL that forwards to the local voice-call webhook. That is what ngrok provides.

Create an ngrok account and find your auth token here: https://dashboard.ngrok.com/get-started/your-authtoken

If you have a reserved ngrok domain, use it. A stable domain is much easier than updating Twilio every time ngrok starts.

You can ask your OpenClaw agent to configure ngrok with this prompt:

Help me configure the OpenClaw voice-call plugin webhook using ngrok.

Please do the following:

1. Inspect my OpenClaw config and determine the voice-call webhook server port/path.
2. Check whether ngrok is already installed and available to the Gateway process.
3. If ngrok is not installed, install the standalone ngrok binary as the standard OpenClaw user, not via admin Homebrew, unless my environment clearly uses a different safe pattern.
4. Make sure the Gateway launch/service environment can find the ngrok binary after restart.
5. Ask me for my ngrok auth token if you need it. Do not print it back or store it in memory/log notes.
6. Configure plugins.entries.voice-call.config.tunnel.provider = "ngrok".
7. If I have a reserved ngrok domain, configure it as plugins.entries.voice-call.config.tunnel.ngrokDomain.
8. Restart the OpenClaw Gateway.
9. Verify the setup with openclaw voicecall setup.
10. Show me the final public webhook URL I should use for Twilio, usually:
https://<my-ngrok-domain>/voice/webhook

Be careful not to delete files or run destructive commands. If you modify config files, summarize exactly what changed and confirm that the final setup check passes.

After this step, your public webhook should look like:

https://your-ngrok-domain.ngrok-free.dev/voice/webhook

Step 5. Update The Twilio Webhook

In the Twilio console, open your Twilio phone number settings. Look for the Voice webhook section.

If it still points at Twilio’s demo app, replace it with your OpenClaw ngrok webhook:

https://your-ngrok-domain.ngrok-free.dev/voice/webhook

Use HTTP POST.

This is especially important for inbound calls. For outbound calls, OpenClaw can provide a per-call webhook URL through the Twilio API, but it is still worth making the Twilio number configuration match your OpenClaw webhook.

Step 6. Enable OpenAI Realtime Voice

This was the key fix in my setup.

The default Voice Call conversation path may use short Twilio TwiML/Gather redirects. In my testing, outbound calls would ring and answer, but then immediately complete. Twilio showed the call as successful, but the duration was 0 seconds.

The useful Twilio error was:

21220: Call is not in-progress. Cannot redirect.

That meant OpenClaw was trying to redirect/update the live call after Twilio had already marked it completed.

The fix was to enable realtime voice mode for the Voice Call plugin. This changes the call from a short TwiML redirect flow into a live Twilio Media Stream connected to OpenAI realtime voice.

Example config shape:

plugins.entries.voice-call.config.realtime.enabled = true
plugins.entries.voice-call.config.realtime.provider = "openai"
plugins.entries.voice-call.config.realtime.providers.openai.model = "gpt-realtime-2"
plugins.entries.voice-call.config.realtime.providers.openai.voice = "cedar"
plugins.entries.voice-call.config.realtime.consultPolicy = "always"

Your agent should have configured this portion for you with the above prompt, but you can check by restarting the gateway (openclaw gateway restart) and then verify by running this command:

openclaw voicecall setup

You want to see:

OK mode: Realtime voice enabled (openai)

If you don’t see openai configured, simply ask your agent to configure the voice call plugin with the OpenAI realtime voice.

Step 7. Tune Realtime Voice Behavior

Once realtime voice is working, you may notice that the assistant gets interrupted too easily. That is usually barge-in behavior: the realtime model hears input audio and cancels its current response so the caller can speak.

That is useful, but it can be too sensitive on phone audio.

This conservative tuning worked better for my setup:

interruptResponseOnInputAudio: false
vadThreshold: 0.65
silenceDurationMs: 650
prefixPaddingMs: 300
minBargeInAudioEndMs: 800

What these do:

• interruptResponseOnInputAudio: false makes the assistant less likely to stop talking immediately when it hears noise.
• vadThreshold: 0.65 makes speech detection less sensitive.
• silenceDurationMs: 650 waits a little longer before deciding your turn is finished.
• prefixPaddingMs: 300 preserves a little audio before detected speech starts.
• minBargeInAudioEndMs: 800 prevents extremely early interruptions.

The tradeoff is that the conversation may feel slightly less instant, but it is usually more stable.

Step 8. Test An Outbound Call

Place a test call:

openclaw voicecall call --to "+1YOURNUMBER" --mode conversation --message "Hello, this is a test call from my OpenClaw agent."

If you are on a Twilio trial account, listen for the Twilio prompt and press the requested key to continue.

During a successful realtime call, OpenClaw should show transcripts and realtime events.

Check active call status:

openclaw voicecall status --json

Or inspect a specific call:

openclaw voicecall status --call-id <CALL_ID>

Or even better, simply ask your OpenClaw agent to call you via sending him a message via Telegram.

Congratulations! You have now configured your agent with a phone number and voice calling capabilities. You can have it call you on a schedule to provide you summaries of what it’s working on. You can call it and talk through your to do tasks on your drive home. You can even have it call a restaurant and make reservations for you. Yes, I tried it and although there can be some issues, it did work! Imagine all the restaurant staff taking calls from digital assistants trying to book a reservation. Yes, we are already there.

Troubleshooting Scenarios

The below are some examples of road bumps I hit along the way. In case you come across the same. I highly recommend you to leverage your agent as you work through these. In most cases, your agent will be able to update it’s own config to address these issues.

1. The call rings, then immediately hangs up

Check Twilio call logs. If the call shows Completed with 0 sec duration, inspect the event details.

If you see this, enable realtime voice mode:

21220: Call is not in-progress. Cannot redirect.

The default redirect flow is likely completing before OpenClaw can move the call into listening mode.

2. Twilio plays an opening message

That is usually the Twilio trial-account prompt. Press the key Twilio asks for to continue the call. For a clean production experience, upgrade the Twilio account so trial prompts are removed.

3. The Twilio webhook points to the demo app

Replace the demo webhook with your ngrok webhook and use HTTP POST:

https://your-ngrok-domain.ngrok-free.dev/voice/webhook

4. OpenClaw and the plugin versions are out of sync

If the Voice Call plugin or Gateway behaves strangely after install, update OpenClaw from the correct account/environment for your machine:

openclaw update
openclaw gateway restart
openclaw doctor
openclaw doctor --fix
openclaw voicecall setup

5. The wrong phone number is configured

Use E.164 format. For US numbers, include +1. If you accidentally entered a number without the country code, update the config (edit the phone number in your openclaw.json file) and rerun the following command to confirm:

openclaw voicecall setup

6. ngrok works manually, but the Gateway cannot find it

If ngrok was installed into a user-local path, make sure the Gateway service environment includes that path. This matters when the Gateway runs through launchd or another service manager instead of your interactive shell.

After changing the service environment, restart the Gateway and rerun:

openclaw voicecall setup

Final Working Setup

• Twilio regular voice-capable phone number
• Twilio Voice webhook pointed to the ngrok public URL
• OpenClaw Voice Call plugin using ngrok tunnel
• OpenAI realtime voice enabled in the Voice Call plugin
• Gateway restarted after config changes
• openclaw voicecall setup passing

Once those pieces were in place, outbound calls connected, the realtime bridge started, and OpenClaw transcribed live caller audio.

Security Notes

Keep these stored in a password manager and never share:

• Twilio Auth Token
• ngrok Auth Token
• Telegram bot token
• OpenClaw Gateway auth token
• Full config files unless secrets are redacted

Use allowlists while testing inbound calls. Open voice access is powerful; treat it like giving someone a live phone line to your agent.

The post Step-by-Step Guide: Give Your OpenClaw Agent a Phone Number and Voice Calling Capabilities appeared first on Joshua Bellendir.

OpenClaw is an open-source AI agent framework that allows you to run a persistent, self-hosted AI assistant locally on your own hardware. Unlike traditional chatbots that only respond within a browser window, OpenClaw can interact with your operating system, manage files, execute commands, automate workflows, and integrate with external services like Telegram, WhatsApp, GitHub, and Google Workspace.

What makes OpenClaw particularly interesting is that it combines modern large language models with long-running agent behavior and local infrastructure control. In practical terms, this means you can build an AI assistant that operates more like a lightweight autonomous operator than a simple chatbot.

For many people, the appeal of OpenClaw is control:

• Your agent runs on hardware you own
• You decide what services it can access
• You control the security boundaries
• You can extend it with skills, plugins, and automation workflows

But that same level of capability also introduces risk.

An AI agent with filesystem access, shell access, internet connectivity, and persistent runtime behavior should be treated carefully. Unfortunately, many setup guides focus heavily on functionality while spending very little time discussing operational security or least-privilege deployment practices.

This guide focuses specifically on deploying OpenClaw securely on a Mac Mini using:

• a dedicated non-admin user account
• Local-only gateway binding (127.0.0.1)
• hardened macOS security settings
• Telegram allowlists
• persistent background services
• post-installation security auditing

The goal is not enterprise-grade hardening, but rather a practical and security-conscious deployment suitable for hobbyists, developers, technologists, and home lab users who want to experiment with AI agents responsibly.

Figure 1: High-level security architecture for a hardened OpenClaw deployment on macOS using least privilege principles and local-only gateway exposure.

Recommended Hardware

For a smooth experience, I recommend (at minimum):

• Mac Mini M4
• 16GB RAM minimum
• 256GB SSD minimum

Apple Silicon performs exceptionally well for local AI agent workloads while maintaining very low power consumption.

You should also plan for:

• 1–3 hours of setup time
• An LLM provider account (OpenAI, Anthropic, Gemini, etc.)
• A Telegram account (for this guide)

Why Run OpenClaw Under a Dedicated User Account?

OpenClaw is capable of:

• Reading files
• Executing shell commands
• Connecting to external services
• Automating workflows
• Running continuously in the background

For that reason, I strongly recommend running it under a dedicated standard (non-admin) macOS account rather than your primary administrator account.

This limits the blast radius if:

• The agent misbehaves
• A plugin is compromised
• Credentials leak
• Remote access is abused
• An automation accidentally performs destructive actions

Treat AI agents the same way you would treat any long-running automation service or daemon: least privilege should be the default.

Step 1: Update macOS

Before beginning, make sure your Mac Mini is fully updated.

Go to:

System Settings → General → Software Update

Install all available updates before continuing.

Step 2: Create a Dedicated Standard User

Create a dedicated standard (non-admin) user account that will run the OpenClaw agent.

Go to:

System Settings → Users & Groups → Add User

Create:

• Account Type: Standard
• Suggested Username: openclaw

This user account will:

• Run the OpenClaw gateway
• Own the workspace files
• Limit administrative access

 Important
All software installation steps below should initially be performed from your administrator account. We will switch to the dedicated standard user later when onboarding the OpenClaw agent itself.

Step 3: Configure macOS Power Settings

Since OpenClaw is designed to run continuously, we want the Mac Mini to remain awake and recover automatically after power outages.

Go to:

System Settings → Energy

Enable:

• Prevent automatic sleeping when the display is off
• Start up automatically after a power failure

This ensures:

• The system stays online
• The agent remains accessible
• Services recover automatically after outages

Step 4: Enable FileVault Disk Encryption

Go to:

System Settings → Privacy & Security → FileVault

Enable:

• FileVault

This encrypts the disk and protects local data if the machine is lost or stolen.

Step 5: Configure the macOS Firewall

Go to:

System Settings → Network → Firewall

Enable:

• Firewall

Then click:

Options...

Enable:

• Stealth Mode

Depending on your environment, you may also choose to:

• Block all incoming connections

 Note
Blocking all incoming connections can interfere with some remote management or VNC workflows. If you enable it temporarily during setup, remember to re-test connectivity afterward.

Step 6: Install Required Software

We now need to install the following:

• Homebrew
• Node.js
• npm (Node Package Manager) – this will install as part of the Node.js installation

All of these steps should still be performed from your administrator account.

Install Homebrew

Open the Terminal app and run:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

The installation may take several minutes. 

At the end of the installation, Homebrew will provide commands to add itself to your shell path.

It should look something like this:

echo >> /Users/YOURUSERNAME/.zprofile
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/YOURUSERNAME/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Run the commands provided by the installer for your environment.

Verify the installation:

brew --version

If successful, Homebrew will return its installed version number.

Install Node.js

Install Node.js using Homebrew:

brew install node

Verify the installation:

node --version

OpenClaw currently requires Node.js v22 or later.

Install OpenClaw

Still under your administrator account, install OpenClaw globally:

npm install -g openclaw@latest

Verify the installation:

openclaw --version

At the time of writing, version 2026.01.29 was installed.

 Important
We are only installing OpenClaw from the administrator account.
The actual onboarding and runtime configuration will happen under the dedicated standard user account.

Optional: Using Screen Sharing to Remote Into the Standard User Account (OpenClaw)

Instead of constantly logging in and out between the admin account and the openclaw account, we can remotely access the local standard user session via Mac’s built in Screen Sharing app. MacOS does not directly support local VNC loopback access out of the box, but we can create a workaround using SSH tunneling.

This section is completely optional. If you prefer to just switch back and forth between your admin and standard user account, jump down to Step 7 to onboard your OpenClaw agent.

Enable Screen Sharing and Remote Login

Go to:

System Settings → General

Enable:

• Screen Sharing
• Remote Login

For both settings (Screen Sharing and Remote Login):

• Add your standard user account (openclaw) to the allowed users list.

Example of Screen Sharing Settings:

You can access these settings using the small (i) information button beside each option.

 Important
If the openclaw user is not explicitly added to both allowlists, authentication will fail later.

Create the SSH Tunnel

From your administrator account, open Terminal and run:

ssh -NL 5901:localhost:5900 openclaw@localhost

Replace:

• openclaw with your standard username

If prompted:

• Accept the SSH connection
• Enter the password for the standard user account

If successful, the terminal will appear to “hang”. This is expected behavior. Leave the terminal window open, as this is what is establishing the SSH tunnel. You need this active to connect via screen sharing.

 Important
If you don’t know your user’s short username, log into your user account and type “whoami” into a terminal window. It will respond with your user’s short username.

Connect Using Screen Sharing

Launch the macOS Screen Sharing app.

Connect to:

vnc://localhost:5901

When prompted for credentials, enter:

• Username: openclaw
• Password: your standard user password

Important: After entering your credentials, on the next pop up window, select “log in as yourself” and click connect.

You should now have a remote desktop session into the standard user account.

This makes it easier to:

• Copy/paste commands
• Manage onboarding
• Switch between accounts
• Monitor the agent

Once setup is complete, you can disable:

• Screen Sharing
• Remote Login

Step 7: Onboard the OpenClaw Agent

Important: The onboarding and configuration steps below should be performed from your standard non-admin user account (openclaw). You can either log into the “openclaw” standard user account or use the remote screen sharing method described in Step 6 above.

Before onboarding, verify OpenClaw is accessible via your standard user account (openclaw):

openclaw --version

You should receive the installed version number.

Now begin onboarding:

openclaw onboard

This launches the onboarding wizard.

Recommended Onboarding Configuration

Below are the settings I recommend as of May 2026.

OpenClaw Security Disclaimer

Select:

Yes

Setup Mode

Select:

Manual

This allows us to explicitly configure each setting.

What Do You Want to Set Up?

Select:

Local gateway (this machine)

Workspace Directory

Select:

/Users/openclaw/.openclaw/workspace

Hit enter to use the default suggested directory unless you have specific requirements.

Model / Authentication Provider

Choose your preferred LLM provider. 

Examples:

• OpenAI
• Anthropic
• Gemini
• Grok
• Codex

This guide is going to walk you through configuring OpenAI using the OAuth method, but feel free to use your preferred provider and follow the onscreen directions. Otherwise, let’s proceed with OpenAI.

When I initially tested OpenClaw, I used the OpenAI API with the gpt-4o model (gpt-4o-mini is also a good choice if going with the API). It worked very well, but token usage can increase quickly depending on context size and agent activity. The OAuth method is a much cheaper alternative to the API. 

So for my second deployment of OpenClaw, I switched to OpenAI Codex OAuth.

Since I already had a paid OpenAI subscription, this avoided API token management and additional usage costs. If you don’t have an OpenAI Pro subscription already, create an OpenAI account and upgrade to Pro for $20/month. Well worth it and is required for this setup. 

If using your OpenAI Pro Account (OAUTH):

• Select OpenAI Codex
• Authenticate via OAuth
• Keep the default model (gpt-5.5)

Gateway Configuration

Recommended settings:

Port: 18789
Bind: 127.0.0.1
Auth: Token mode
Tailscale exposure: Off

As shown in Figure 1 above, the OpenClaw gateway is intentionally bound to localhost (127.0.0.1) and isolated under a dedicated non-admin user account.

For the token:

• Select Generate/store plaintext token
• Leave the token field blank to auto-generate

 Important
Binding to 127.0.0.1 is one of the most important security settings in this guide.
This prevents the gateway from listening publicly on your network interfaces.

Configure Chat Channels

Select:

Yes

For this guide, we will use Telegram.

Telegram is one of the easiest integrations to configure and works well for interacting with the agent remotely. Another popular channel to use would be WhatsApp, but the telegram setup is a bit easier, so we will go with that for now. You can always change this later by re-running the onboarding wizard.

Create a Telegram Bot

Before we proceed with the channel setup using Telegram, we need to setup a Telegram Bot which will be used as the Telegram user for our OpenClaw agent. If you don’t already use Telegram, simply download the Telegram app and register a new account.

Telegram has an official bot called the BotFather which is used to register Bots on the platform.

Open the Telegram app and search for:

@BotFather

Start a chat and run:

/newbot

BotFather will ask for:

• A display name
• A username ending in bot

Once completed, BotFather will provide:

• A bot token

Save this token.

Return to the OpenClaw onboarding wizard and select Telegram (Bot API) under the list of chat channels.

• Select “Enter Telegram bot token”
• Paste the token

Once you have successfully added the Telegram channel, select “Finished” on the select a channel option.

Configure Telegram Access Restrictions

After adding Telegram, OpenClaw will display a warning about DM pairing access.

By default:

• Any Telegram user can attempt to pair with your bot

For improved security, I strongly recommend:

• Using an allowlist and restrict to only your Telegram user.

Select:

Allowlist (specific users only)

You will now need your Telegram numeric user ID.

Find Your Telegram User ID

Open the Telegram app and search for:

@rawdatabot

Start a chat and run:

/start

This bot will return your:

• User ID / Chat ID

Copy your numeric Telegram user ID and paste it into the OpenClaw onboarding wizard.

This restricts communication to only your Telegram account. 

One of the more interesting aspects of OpenClaw is that once the agent is operational, it can manage many of these configurations for you directly. For example, if you want to grant a trusted contact access through your Telegram bot, the agent can add their Telegram user ID to the allowlist automatically.

 Important
Be cautious when granting access, as anyone added to the allowlist may be able to control the agent and execute actions on your Mac Mini depending on the permissions and integrations configured

Search Provider

I recommend either:

• Brave Search
• DuckDuckGo

Both work well for general agent usage. I suggest to go with DuckDuckGo as it’s free. You can always rerun the onboard wizard and change to a different provider. 

Skills, Plugins, and Hooks

For your initial deployment, I recommend skipping:

• Skills
• Plugins
• Hooks

Get the base platform stable first before expanding functionality. We will come back to this in a future guide. You can always rerun the onboard wizard to enable these, or even better, ask your agent once it’s hatched to enable them for you. 

The best skills to enable for foundational automation and productivity would be:

Install Gateway Service

Select:

Yes

This is the second most important setting.

Without this:

• the gateway stops when the terminal closes

With the gateway service installed:

• OpenClaw runs persistently in the background
• It survives reboots
• It behaves like a proper daemon/service

Gateway Runtime

Select:

Node (recommended)

Once the gateway is running, the OpenClaw onboarding wizard will output a bunch of helpful information. I strongly suggest to copy the text and paste into notepad to reference later. 

For example, it will provide you with the Control UI information, which includes your token to access the OpenClaw web dashboard, where you can interact with your agent, update the OpenClaw software, add skills, and much more. If you’re not comfortable in the command line, you’ll want to use the OpenClaw dashboard. 

◇  Control UI ─────────────────────────────────────────────────────────────────────╮
│                                                                                  
│  Web UI: http://127.0.0.1:18789/                                                 
│  Web UI (with token):                                                            
│  http://127.0.0.1:18789/#token=THIS_WILL_BE_YOUR_SPECIFIC_TOKEN │
│  Gateway WS: ws://127.0.0.1:18789                                                
│  Gateway: reachable                                                              
│  Docs: https://docs.openclaw.ai/web/control-ui     

Bring the Agent Online

At the end of onboarding, OpenClaw will ask:

How do you want to hatch your bot?

Select:

Open the Web UI

Your agent will now come online.

You will likely see something similar to:

Hey. I just came online. Who am I? And who are you?

We’ve got a fresh workspace, so I’m supposed to figure myself out with you a bit: name, what kind of creature I am, my vibe, and a         
signature emoji.

If you’re feeling playful, toss me a name. If not, I can suggest a few.

Bootstrap Your Agent

I recommend starting with a clear operational prompt.

Paste the below (tweak as needed) into the chat window with your agent.

You are (Insert Name). I am (Insert Name).

Be direct, concise, and honest. If I ask you to do something dumb or risky, push back and tell me why. Don’t sugarcoat or over-explain. I’d rather hear a problem than have you blindly execute.

You’re running on a Mac Mini as my personal assistant. 

Core rules: Never delete files, send messages, or run commands with side effects without confirming with me first. Ask before acting on anything destructive or irreversible. Keep responses short unless I ask for detail. Flag security concerns proactively.

This helps establish:

• tone
• behavioral boundaries
• operational expectations
• safety controls

Post-Onboarding Security Hardening

Before you begin expanding the agent’s capabilities, let’s run a few security checks against the installation.

Run the following security audits:

openclaw security audit --deep
openclaw security audit --fix

The audit will catch common misconfigurations – e.g., open DM policies, incomplete allowfrom configurations, exposed gateway, and weak permissions. The –fix flag fixes what it can.

OpenClaw Doctor is your Friend

The openclaw doctor is a built-in diagnostic and repair tool for the OpenClaw AI ecosystem that scans for and fixes issues with configurations, file permissions, and port conflicts. It acts as an automated health check, ensuring that the gateway, channels, and local models are communicating properly. 

Key functions of the command include:

• Health Checks: Inspects ~/.openclaw/openclaw.json and directory structures for errors.
• Automated Repairs: When run as openclaw doctor –repair, it fixes issues like stale configurations, port conflicts (default port 18789), and corrupted workspace indexes.
• Migrations: Handles legacy state migrations to ensure the installation uses the latest file structures.
• Security Audit: Identifies potential security issues, such as dangerous debug flags or improper authentication. 

Common Commands:

 Important.
It is highly recommended to run this command after updating OpenClaw, changing configurations, or installing new skills to ensure the system is stable. 

Useful OpenClaw Commands

Commands for Standard User Account (openclaw):

Commands for Admin User Account:

 Important
Most runtime and gateway commands should be executed from the dedicated standard user account, not the administrator account.

After updating OpenClaw from the admin account, make sure you restart the gateway service under the standard user account with the following command: openclaw gateway restart.

Final Thoughts

OpenClaw is one of the most popular open-source AI agent frameworks currently available for users who want:

• local control
• extensibility
• persistent automation
• self-hosted infrastructure

The most important recommendation I can give is this:

Treat AI agents like infrastructure.

Run them with least privilege, isolate them from your primary environment, and avoid exposing services publicly unless absolutely necessary.

Regularly run security audits and the OpenClaw doctor to ensure your installation remains stable and secure over time.

A Security Checklist to Live By:

• Protect your API keys (keep them in your preferred password manager)
• Run OpenClaw under a dedicated non-admin MacOS user
• Keep OpenClaw updated with the latest version (regularly check for updates)
• Do NOT expose port 18789 publicly
• Gateway bound to 127.0.0.1
• FileVault enabled
• MacOS firewall enabled w/ blocking incoming connections
• Token auth on gateway
• DM set to pairing with channel allowlist limited to your Telegram user only
• If using cloud LLM API (e.g., OpenAI, Claude Opus 4.6, Grok), ensure API spending limits set with provider
• Review permissions carefully and instruct your agent to always review requests to ensure they are not risky
• Run openclaw security audit –deep regularly
• Never install untrusted skills / All ClawHub skills reviewed before installation

The post How to Securely Run OpenClaw on a Mac Mini (Step-by-Step Guide) appeared first on Joshua Bellendir.