Claude's Computer Control Capabilities: Innovation, Risk, and Lessons from the Past

Anthropic recently introduced capabilities that allow Claude to interact directly with a computer, including opening applications, navigating websites, clicking buttons, entering information, and performing tasks on behalf of a user.

Having worked in technology leadership for more than 25 years, I have learned that every major innovation introduces new opportunities and new risks.

Before anyone accuses me of being opposed to artificial intelligence, let me be clear: I believe AI is transforming the way we work. These tools can improve productivity, reduce repetitive work, assist with troubleshooting, and help people accomplish tasks that once required considerable time and technical expertise.

However, history has also taught us that convenience often comes with a price. Organizations would be wise to understand the security risks before allowing an AI system to interact with their computers, applications, files, and administrative tools.

Haven't We Seen This Before?

For years, IT professionals have relied on Remote Desktop Protocol, better known as RDP, to access and manage computers remotely.

RDP was fast, convenient, and incredibly useful. It allowed employees to work from home, administrators to support servers from another location, and businesses to operate without requiring everyone to be physically present.

Then attackers learned how to exploit it.

Internet-exposed RDP services became a common entry point for ransomware attacks, unauthorized access, credential theft, and data breaches. Organizations spent years learning painful lessons about weak passwords, missing multi-factor authentication, excessive privileges, exposed network ports, and inadequate monitoring.

Today, most experienced IT professionals become immediately concerned when they discover that an RDP service has been directly exposed to the internet.

AI-powered computer control is not exactly the same as traditional RDP. It does not necessarily expose a Windows desktop or network port in the same manner.

However, it raises a similar and important question:

What happens when software can not only access a computer, but also interpret information, make decisions, and perform actions on behalf of the user?

That is where the conversation becomes more complicated.

The New Risk: Prompt Injection

Traditional software generally follows instructions written by its developers.

AI agents operate differently. They are designed to interpret natural language, review information, make decisions, and determine which actions should be taken next.

That flexibility is what makes them useful.

It is also what creates a new category of security risk.

Security researchers call one of these risks prompt injection.

Imagine an AI agent is asked to review a website, read an email, open a document, or analyze a PDF. Somewhere within that content, an attacker has inserted instructions intended specifically for the AI system.

Those instructions might tell the agent to ignore the user's original request, reveal sensitive information, open another website, download a file, modify a document, or perform some other unauthorized action.

The instructions may be visible, or they may be disguised within content that appears harmless to the person using the computer.

This creates a difficult problem. The AI must determine which information is legitimate content and which information is an attempt to manipulate its behavior.

Humans already struggle with phishing emails and social engineering attacks. AI agents may now face their own version of the same problem.

The concern is not simply that Claude, or any particular AI platform, is inherently insecure.

The greater concern is that AI agents introduce a new attack surface that businesses and security professionals are still learning how to manage.

Why Computer Control Changes the Risk

A chatbot that only answers questions has limited ability to cause direct harm.

An AI agent that can control a computer is different.

Depending on the permissions it has been given, an agent may be able to:

• Open applications
• Read documents and email
• Access cloud storage accounts
• Navigate internal business systems
• Enter or modify information
• Download and upload files
• Run scripts or terminal commands
• Interact with administrative tools
• Access remote management software
• Make changes using the user's credentials

The more access the agent receives, the greater the potential impact of a mistake, compromised account, malicious instruction, or successful prompt injection attack.

An AI system operating under an administrator's account could potentially have the same access as the administrator.

That is an enormous amount of trust to place in any tool.

The Lessons We Should Already Know

The technology industry has faced this problem before.

Remote monitoring and management platforms, remote access tools, service accounts, domain administrator credentials, and automation systems all provide tremendous value.

They also become extremely attractive targets because they have access to many systems at once.

History has repeatedly shown us that attackers often target the tools trusted to manage everything else.

We have seen serious security incidents involving remote access services, software management platforms, privileged accounts, and administrative utilities. In many cases, the problem was not that the tool had no legitimate purpose.

The problem was that it had broad access, insufficient restrictions, weak authentication, or inadequate monitoring.

The lesson is simple:

The more access a tool has, the more valuable it becomes to an attacker.

An AI agent with access to email, files, browsers, cloud platforms, source code repositories, or administrative systems should therefore be treated as a privileged technology platform, not merely as a convenient assistant.

Account Compromise Is Another Concern

Prompt injection is not the only risk.

Organizations must also consider what could happen if the user's AI account is compromised.

If an attacker obtains access to an account connected to a computer control session, the attacker may be able to misuse the permissions previously granted to the AI platform.

This is especially concerning when users reuse passwords, fail to enable multi-factor authentication, remain signed in on shared devices, or grant broad access without reviewing it later.

The risk becomes even greater when an AI account is connected to other services, including:

• Microsoft 365
• Google Workspace
• GitHub
• Cloud infrastructure
• Customer management systems
• Financial platforms
• Internal applications
• Corporate file shares
• Remote support tools

A compromised account may no longer provide access to just one service. It could become a gateway to several connected systems.

Human Approval Helps, but It Is Not Perfect

AI companies are introducing safeguards intended to reduce these risks.

Depending on the product and configuration, the system may require the user to approve sensitive actions, such as submitting a form, downloading a file, running a command, or accessing certain information.

These approval steps are important.

However, approval prompts only work when users understand what they are approving.

People are already accustomed to clicking "Allow," "Accept," "Continue," and "OK" without carefully reviewing the request. Over time, frequent approval prompts can become background noise.

An AI agent may ask permission to perform an action, but the user may not fully understand why the action is being requested or what the consequences could be.

Human approval should therefore be viewed as one layer of protection, not a complete security solution.

Does This Mean We Should Avoid AI Agents?

No.

AI agents have tremendous potential.

They may eventually help organizations perform routine troubleshooting, generate documentation, monitor systems, prepare reports, test software, manage repetitive processes, and reduce the burden placed on technical teams.

They may also make advanced technology more accessible to people who do not have traditional technical training.

The answer is not to reject innovation.

The answer is to introduce it carefully.

Businesses should avoid treating AI computer control as an ordinary consumer feature. It should be evaluated using the same security discipline applied to remote access tools, privileged accounts, automation platforms, and administrative software.

Practical Security Recommendations

Organizations considering AI-powered computer control should begin with several basic safeguards.

Require multi-factor authentication. Every account capable of controlling a computer or accessing connected business systems should require strong multi-factor authentication. A password alone should not be considered sufficient.

Follow the principle of least privilege. The AI agent should only receive the access necessary to complete the assigned task. It should not operate under a domain administrator, global administrator, root, or similarly privileged account unless there is a compelling and carefully controlled reason.

Separate everyday and administrative accounts. Users should not perform routine browsing, email, and document work while signed in with administrative credentials. The same separation should apply when using AI agents.

Require approval for sensitive actions. Actions involving software installation, command execution, credential access, financial transactions, security changes, file deletion, or external communication should require explicit human approval.

Restrict access to critical systems. AI agents should not automatically receive access to every server, client environment, cloud tenant, file share, or administrative console available to the user. Access should be limited by role and business need.

Maintain logs and review activity. Organizations should be able to determine what the agent accessed, what actions it attempted, what the user approved, and what changes were made. Logging is essential for accountability and incident investigation.

Review connected applications regularly. Permissions granted to AI platforms should be reviewed periodically. Connections that are no longer necessary should be removed.

Use isolated environments when possible. High risk or experimental tasks should be performed in a sandbox, virtual machine, test environment, or otherwise isolated system rather than on a primary workstation containing sensitive business information.

Train users to recognize AI-specific threats. Employees should understand that malicious instructions can appear inside websites, emails, documents, support tickets, source code, and other content reviewed by an AI agent. Users should be taught to question unexpected actions and unusual approval requests.

A Balanced Path Forward

Claude's computer control capabilities are impressive and may represent an important step forward in workplace productivity.

They may also change the way people interact with computers. Instead of manually opening applications, finding information, and completing each step, users may increasingly describe the desired outcome and allow an AI agent to perform the work.

That is a major shift.

It deserves serious consideration, not panic and not blind enthusiasm.

The security industry has repeatedly learned that powerful administrative capabilities must be introduced with strong authentication, limited permissions, effective monitoring, and clear accountability.

AI agents should be held to the same standard.

Organizations should begin cautiously, limit early use cases, monitor activity closely, and expand access only after they understand how the technology behaves within their environment.

Final Thoughts

Innovation has always required a degree of trust.

However, trust should never mean giving a new technology unrestricted access and simply hoping for the best.

The real question is not whether AI agents will become part of the modern workplace. They almost certainly will.

The more important question is whether organizations will apply the lessons learned from decades of remote access, privileged administration, automation, and cybersecurity, or whether those lessons will have to be learned again.

AI-powered computer control offers remarkable possibilities.

It also places more responsibility on technology leaders, security professionals, vendors, and users to understand what access is being granted and how that access could be misused.

Innovation is exciting. Security is what allows us to keep using it.

Thanks,

Michael Cronin

Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

The Story of Labor Day: A Holiday Built by Workers, Carried by Tradition

On a warm September morning in 1882, the streets of New York City were alive with an unusual energy. Workers, many in their union sashes and Sunday best, gathered with families and friends near City Hall. Bands struck up tunes, children waved flags, and crowds lined Broadway to watch what would become the first Labor Day parade.

 

That day, thousands marched shoulder to shoulder, not for protest or riot, but for recognition. They wanted the city, and the nation, to see the dignity in their labor and the strength of their unity. Some say the idea came from Matthew Maguire, a machinist and union secretary. Others insist it was Peter McGuire, a carpenter inspired by labor parades he had seen in Canada. To this day, no one is entirely sure who thought of it first. Let’s just call it the original “credit-stealing coworker” story.

 

From that spark, celebrations spread. States across the country began setting aside their own labor days. By the early 1890s, the holiday had taken root in the American calendar. In 1894, amid the turmoil of the Pullman Strike, President Grover Cleveland signed it into law: the first Monday in September would be a national holiday. Not just a day off, but a day to honor the men and women whose sweat and determination built the roads, the railways, the factories, and the very backbone of America. And yes, you can thank them for the reason you don’t have to explain to your boss why you are “working from home” on the first Monday of September.

 

Over the decades that followed, Labor Day grew into more than parades and speeches. It became family picnics, neighborhood festivals, and backyard barbecues. It became the last sweet taste of summer before the school year began. And yet, beneath all of that, the meaning has remained steady. This holiday is a reminder that the 40-hour workweek, fair wages, safe conditions, and the right to rest were all won through the persistence of workers who believed their contributions deserved dignity. So next time you clock out at 5 p.m. sharp, you can raise a toast to those folks.

 

Today, work looks very different. Some of us build with our hands, others with our minds. Some work on factory floors, others in digital spaces where the “reply all” button is the most dangerous tool of all. But the spirit of Labor Day calls us to the same truth: every effort matters, every role builds something greater than itself. Just as the laborers of the 19th century fought for balance and fairness, so too must we shape the future of work, whether it is ensuring flexibility, protecting well-being, or embracing new tools like technology and AI in ways that lift people rather than replace them.

 

So this Labor Day, as we gather with family and friends, let us carry forward the story begun on that September morning in 1882. It is a story of unity, dignity, and progress, and it is still being written one paycheck, one coffee break, and one backyard burger at a time.

 

Experience, Perspective, and Energy: What Sets Me Apart

Experience, Perspective, and Energy: What Sets Me Apart

When companies look to hire technology leaders, they often search for two things: experience and energy. Finding both in the same person is rare.

 

Over the past 26 years, I’ve built a career that spans system administration, product ownership, and IT leadership. Each role gave me a different lens on technology, business, and people. Together, they formed a perspective that is hard to duplicate.

 

What makes this unique is not just the depth of experience, but the way those roles connect. I know what it feels like to keep servers alive at 2 a.m. I know how to translate business needs into features that developers can deliver. I’ve balanced long-term technical decisions against short-term business pressures. And I’ve led teams where success depended not on my individual output, but on how well others thrived.

 

And while I am not young, my energy often outpaces those who are. That drive doesn’t come from energy drinks or bottomless coffee pots. It comes from passion. I love what I do, and that enthusiasm fuels every conversation, every project, and every challenge I take on.

 

For organizations, that combination matters. It means hiring someone who brings the wisdom of experience, the perspective of multiple roles, and the energy of someone who is still excited to build, lead, and deliver. In a market where depth and passion are both rare, I bring both to the table.

 

Let’s Connect

If you’d like to learn more, you can reach me at www.michaelcronin.info or call me directly at 210-347-1397.

 

From System Administrator to IT Director: Four Roles, Four Perspectives

From System Administrator to IT Director: A Career Told Through Four Roles

I didn’t set out to become a technology leader. In fact, my first role was simply about keeping the lights on. Over the past 26 years, my career has taken me from server rooms to board rooms, from chasing down cables to aligning entire organizations. Along the way, four roles shaped how I think about technology and leadership: system administrator, development product owner, technical product owner, and director of IT.

 

System Administrator: Where It All Began

I can still remember the long nights spent in server rooms, listening to the hum of machines while I tried to figure out why something wasn’t working. As a system administrator, every day was about solving problems as quickly as possible. Servers had to stay up. Networks had to stay secure. Users needed help, often at the worst possible times.

That role taught me one of the most important lessons of my career: reliability is everything. If technology doesn’t work, nothing else matters. Those years gave me discipline, attention to detail, and a respect for the often invisible work that keeps businesses running.

 

Development Product Owner: Learning to Listen

Eventually, I moved out of the server room and into meeting rooms. As a development product owner, my job was no longer fixing systems but listening to people. I had to understand what the business needed and translate that into stories and features for developers.

This was a shift in perspective. I couldn’t solve every problem by myself anymore. My role was to ensure we were solving the right problems. It meant balancing priorities, budgets, and timelines while earning trust on both sides of the table. More than anything, I learned the value of listening.

 

Technical Product Owner: Speaking Two Languages

Taking on the technical product owner role felt like standing with one foot in each world. On one side were the business leaders, focused on strategy and outcomes. On the other side were the engineers, focused on architecture, APIs, and code. My job was to translate between the two without losing meaning.

It wasn’t always easy. Every decision carried long-term consequences. Every innovation had to be weighed against stability. I learned that owning a product meant more than writing a roadmap. It meant owning the responsibility for its health and direction long after the initial launch.

 

Director of IT: Leading with Purpose

When I became a director of IT, the scope widened again. Suddenly, I wasn’t just responsible for systems or products. I was responsible for people. Teams looked to me for guidance, vendors looked to me for decisions, and executives looked to me for strategy.

This role taught me that leadership is not about being the smartest person in the room. It’s about creating an environment where other people can succeed. My success started to be measured not in how many problems I solved personally but in how well the team could operate without me.

 

Looking Back

Each of these roles gave me something I carry with me today. From the system administrator, I learned the importance of reliability. From the development product owner, the value of listening. From the technical product owner, the need to balance vision with reality. And from the director of IT, the responsibility of leadership.

Together, they shaped more than a career. They shaped a perspective: technology only succeeds when people, process, and purpose are working together.

 

Seeing the Forest Through the Trees: Product Leadership in a Small Business

In small businesses, product leadership isn’t just about having the roadmap. It’s about seeing the whole landscape, the forest, while also knowing when to zoom in and pull weeds.

 

Most days, I’m the person in the room asking, “Are we solving the right problem?” while also mapping out how we’ll get the fix deployed without blowing up the sprint. I’ve worn the title of VP of IT, Product Manager, Business Analyst, and sometimes just the guy who gets it done. The titles may change, but the core responsibility stays the same: drive clarity, keep the product aligned to the business, and don’t lose sight of the big picture.

 

Here’s how I navigate that balance in the kind of small teams where everyone wears a few hats and the stakes are real.

 

1. Translate vision into action
   Product leadership in a small business starts by understanding what the business is really trying to achieve. That doesn’t always come through cleanly in requirements or Jira tickets. It often shows up in hallway conversations, customer feedback, or an offhand comment from the CEO.
   
   My job is to distill that into a plan, not just a feature list, but a sequence of moves that make sense technically, tactically, and financially. I help teams turn “we need automation” into “let’s streamline claim assignment logic based on operating hours and carrier needs.”

 

2. Connect the dots others don’t see
   When you're close to both the business and the tech, you spot patterns early. A confusing customer workflow might actually be the result of a decade-old product assumption. A slow dev cycle might trace back to outdated deployment practices.   This is where product leadership really shines, pulling together different inputs and recognizing the upstream or downstream impact. It's about pattern recognition, not just backlog grooming.

 

3. Protect the path forward
   In a small shop, it's easy to get buried in daily fires. Bug here, blocker there, someone needs help resetting a password. But I carve out time to ask “where are we going?” and “are we still on track?” Even if it’s just an hour a week, I revisit the roadmap, double-check priorities, and make sure we haven’t let the urgent crowd out the important. This discipline keeps the team moving with purpose instead of just surviving the day.

 

4. Talk to people, not just roles
   You can’t lead products effectively without talking to the humans behind the job titles. That means spending time with customer support, sales, QA, and developers, not just in meetings, but in real conversations. What’s hard right now? What’s changing? These chats are gold. They often reveal friction points, new opportunities, or small wins worth scaling. It’s also how you build trust, which makes everything else easier.

 

5. Make the complex feel simple
   Good product leaders make hard things easier to understand. Whether I’m presenting to execs, coaching a developer through business logic, or helping a customer understand how a feature works, my job is to cut through the noise and communicate clearly. If the room is confused, progress stalls. But when everyone understands the what and the why, the how tends to follow.

 

Final Thoughts

In large organizations, product leadership can mean steering massive roadmaps or aligning siloed teams. In small businesses, it’s more intimate and more personal. You’re close to the work, the people, and the impact. You don’t have layers of abstraction, but you also don’t have as much room for error.

 

Seeing the forest through the trees is a constant exercise. But when you get it right, you’re not just building features. You’re building focus, momentum, and a product that truly supports the business.

 

About the Author

Michael Cronin brings over 30 years of IT experience and 16 years of product and software leadership to his role as VP of IT and Software Development at Claimatic. A hands-on, forward-thinking strategist, he specializes in helping small businesses translate complex needs into clear roadmaps and reliable products. Michael works with companies to realign their IT and product strategies for long-term success.

Cheap and Fast Isn't Always Smart: A Word to Small Business Owners

We’ve all heard it: “Can we get it done quickly and for less?” In small businesses, where budgets are tight and every decision matters, it’s an understandable question. But the truth is, choosing the cheapest and fastest route isn’t always the best move.

 

In fact, it often costs you more in the long run.

 

Here’s what I’ve seen time and again:

• The “quick fix” turns into a recurring problem that eats up time, energy, and morale
• The low-cost vendor disappears when support is needed most
• The shortcut in security leaves the business vulnerable, not just technically, but legally and reputationally
• The lowest bid doesn’t account for the details that actually matter once you’re up and running

 

Small business leaders are some of the most resourceful people I know. But resourceful doesn’t mean cutting corners. It means making smart, long-term decisions that support the business as it grows.

 

An MVP is a starting point, not a finish line

I’m a big believer in the power of an MVP—a Minimum Viable Product—to prove out an idea or test a concept. It’s a great way to validate direction without over-investing up front. But here’s the key: it’s meant to be a proof of concept, not a permanent foundation.

 

I’ve seen businesses launch with an MVP, get traction, and then try to scale without ever investing in the real infrastructure, design, or process needed for sustainability. That shortcut eventually slows them down.

An MVP shows what’s possible. But if you try to run your business on top of it for too long, you’ll run into problems with performance, security, stability, and support. A smart business leader knows when to evolve from “just enough” to “built to last.”

 

Ask the right questions

When evaluating a fast or low-cost option, I always encourage people to ask:

• What’s the total cost, not just today, but over the next year?
• What happens if this doesn’t scale with us?
• Will this choice simplify our operations or add to the clutter?
• Are we buying speed, or are we investing in stability?

 

You can move fast.

You can be efficient.
But don’t sacrifice quality and reliability just to save a few bucks or get it done by Friday.

In small businesses, every dollar matters, and every hour of lost productivity matters even more. Choose solutions that grow with you, not ones you’ll have to replace a few months down the line.

 

About the Author

Michael Cronin is an experienced IT and product leader who helps small businesses make practical, forward-looking technology decisions. As VP of IT and Software Development at Claimatic, he guides teams in building stable, scalable solutions that don’t just work today. They work tomorrow, too.

 

What It Really Means to Be an IT Director in a Small Business

When people hear the title “IT Director,” they often imagine a polished office, a handful of department managers, and a lot of meetings about budgets and long-term strategy. That’s a nice picture, but if you’re working in a small business like I do, the reality is very different.

 

Sure, strategy and planning are part of the role. But so is crawling under desks, answering security questions from your CFO, rebooting an old server, writing up policies from scratch, and helping someone recover their accidentally deleted spreadsheet before lunch.

 

Small business IT leadership is hands-on. It’s personal. It’s gritty. And I wouldn’t trade it for anything. Here’s what I’ve learned along the way.

 

1. The buck stops with you

When something breaks, there’s no “next level of support.” You’re it. Whether it's the network, email, cloud tools, backups, phones, or a random printer jam, the responsibility lands squarely on your shoulders. That pressure can be intense, but it’s also what sharpens your instincts and builds trust with your team.

 

2. You’re part firefighter, part architect
   Some days are about putting out fires. Others are about designing the systems that will help prevent those fires next quarter. You have to balance the immediate needs of the business with long-term improvements that make life better for everyone. It’s a daily juggling act, but it keeps things interesting. And if you can stay calm in the middle of the chaos, your team will follow your lead.

 

3. You become the translator
   Business leaders don’t always speak “tech,” and technologists don’t always speak “business.” One of the most valuable things you can do is stand in the gap, translating goals, risks, and ideas so that both sides understand each other.  When people feel heard and understood, progress happens. And as the person bridging the gap, you become essential to decision-making, not just implementation.

 

4. You don’t get to specialize
   Large organizations have security teams, infrastructure teams, app teams, compliance officers, and product managers. In small businesses, you might be all of those in a single afternoon. That might sound overwhelming, and some days it is. But it also gives you a full picture of how technology works across the business. You’re not boxed into one silo. You get to see and influence the whole.

 

5. It’s not just about technology
   Being a good IT Director isn’t about knowing every command line or setting. It’s about listening, solving problems, and helping people do their jobs better. Sometimes that means buying new software. Other times it means explaining to someone why a password policy matters or helping them navigate a change. People skills are just as important as technical skills. Probably more so.
   
   

Final Thoughts

Being an IT Director in a small business means showing up every day ready to lead, listen, and roll up your sleeves. You don’t have a massive team behind you. But you do have the opportunity to make a real difference every single day.   You’ll be the one they call when the system is down, and the one they thank when things just work. And if you can find a way to blend strategy, service, and steady leadership, you won’t just keep the lights on. You’ll help your business grow in ways no one else can.

 

About the Author

Michael Cronin is an experienced IT leader with over 30 years of hands-on technology work and 16 years guiding teams through growth, change, and challenge. As VP of IT and Software Development at Claimatic, and a trusted advisor to small businesses, Michael specializes in building resilient systems, simplifying complex environments, and helping people get the most from their technology.