Drew Breyer Blog

Category: Security & AI

  • I Put an AI Agent on a $10 VPS and It Already Does More Than Siri Ever Did

    At 9 PM on a Monday night, I SSH’d into a $10/month Ubuntu VPS, ran three commands, and stood up an AI agent that now monitors stablecoin regulation news, tracks Bitcoin and Ethereum prices, checks job postings at Circle and Paxos, sends me a daily briefing over Telegram, runs security audits on its own server, and — I’m not exaggerating — wrote and published a blog post to this very site. The one you’re reading right now.

    Total setup time: about twenty minutes. No app store. No subscription tier. No waiting list. Just an open-source project called OpenClaw, a terminal window, and an Anthropic API key.

    If that sounds like the kind of thing that should require an engineering team and a six-figure infrastructure budget, that’s exactly the point. The gap between what self-hosted AI agents can do today and what most people think is possible is enormous — and it’s about to reshape how knowledge workers interact with AI entirely.

    What I Actually Built Tonight

    OpenClaw is an open-source gateway that connects AI models to messaging platforms. You run a single process on your own hardware — a Raspberry Pi, an old laptop, a cloud VPS — and it bridges your chat apps to a persistent AI agent with memory, tool use, and scheduling capabilities.

    Here’s what mine does after twenty minutes of setup:

    Morning briefings on autopilot. Every day at 6:30 AM, my agent searches the web for stablecoin regulation updates, pulls Bitcoin and ETH prices, checks career pages at Circle, Paxos, and Tether, grabs Dynamics 365 and Microsoft partner news, and fetches the weather forecast for my town in Minnesota. It compiles everything into a clean summary and sends it to my Telegram. I wake up to a personalized intelligence briefing that would cost a human researcher hours to assemble.

    Server security on its own infrastructure. I told it to run a healthcheck. It audited the operating system, checked listening ports, inspected the firewall configuration (there wasn’t one — it flagged that), verified SSH settings, confirmed automatic security updates were enabled, and presented me with a hardening plan organized by risk level. Then it asked which security profile I wanted before touching anything.

    WordPress publishing. I installed a WordPress skill from ClawHub (think: an app store for agent capabilities), pointed it at my blog, and now my agent can draft, edit, and publish posts directly. It created tags, selected categories, and handled the REST API authentication. This post went from my Telegram message to your screen without me opening a browser.

    Persistent memory. Unlike ChatGPT, which forgets everything between sessions, my agent writes daily notes and maintains a long-term memory file. It remembers that I’m interested in stablecoin careers, that I work in the Microsoft partner ecosystem, that my server needs firewall hardening. Context compounds over time instead of resetting every conversation.

    Why This Matters More Than Another AI Chatbot

    We’ve been conditioned to think of AI assistants as chat interfaces — you type a question, you get an answer, you close the tab. Siri, Alexa, Google Assistant, even ChatGPT: they’re fundamentally reactive. You initiate, they respond. They don’t do things while you sleep.

    Self-hosted agents flip that model. My agent runs 24/7 on a Linux box in a data center. It has cron jobs. It has scheduled tasks. It monitors things proactively. When I wake up tomorrow, there will be a briefing waiting for me that I didn’t have to request. If something urgent hits the stablecoin regulation space overnight, it’ll be in my Telegram before my coffee is ready.

    This is the difference between a tool you use and an agent that works for you.

    The Walled Garden Problem

    Every major tech company wants to be your AI provider. Apple is embedding AI into iOS. Google is weaving Gemini into everything. Microsoft has Copilot across the entire 365 suite. OpenAI wants you paying $200/month for ChatGPT Pro.

    The pitch is always the same: let us handle the complexity, just trust us with your data.

    But here’s what you give up in that bargain:

    Data sovereignty. Your conversations, documents, and behavioral patterns feed someone else’s models. When I talk to my self-hosted agent about job prospects or financial decisions, that data lives on my server, under my control, encrypted at rest if I choose. It doesn’t train anyone’s next model version.

    Customization. Try getting Siri to monitor stablecoin regulation news and publish WordPress posts. You can’t, because Apple decides what Siri can do. With OpenClaw, I installed a WordPress skill in thirty seconds and pointed it at my site. If I want it to monitor RSS feeds, trade crypto, or manage my home automation, those are just more skills to install — or build myself.

    Interoperability. My agent talks to me on Telegram today. If I want to switch to Signal, WhatsApp, Discord, or Slack tomorrow, it’s a configuration change — not a platform migration. The agent is the constant; the messaging app is just a transport layer.

    Persistence. ChatGPT’s memory is a marketing feature with hard limits. My agent’s memory is a markdown file on disk that I can read, edit, and back up. It’s transparent. I can see exactly what it remembers and why. There’s no black box.

    The $10/Month AI Employee

    Let’s talk economics. My VPS costs $10/month. API costs for the AI model depend on usage, but for a personal assistant handling a few dozen interactions per day with periodic background tasks, you’re looking at roughly $30–60/month with a frontier model like Claude Opus. Call it $50–70/month all-in.

    For that price, I have an agent that:

    • Monitors five different news and market categories daily
    • Manages my blog’s editorial workflow
    • Audits and hardens its own server security
    • Maintains persistent context about my career, interests, and projects
    • Is available on every messaging platform I use
    • Runs scheduled tasks without my involvement
    • Can be extended with new capabilities in minutes

    A virtual assistant doing this work would cost $2,000–4,000/month. A SaaS tool covering even half these use cases would run $200+ across multiple subscriptions. And none of those options give you the data ownership, customization, or architectural control of self-hosting.

    What This Means for Knowledge Workers

    I’m a Sales Engineer at Microsoft. My day job involves understanding complex enterprise software and communicating its value to decision-makers. The meta-irony of using an open-source AI agent to do things that commercial AI products can’t isn’t lost on me.

    But that’s exactly why I think self-hosted agents matter. Knowledge workers — consultants, engineers, analysts, founders — are the people most likely to benefit from AI that actually understands their context, runs persistently, and integrates with their specific workflows. And they’re also the people most likely to be frustrated by the limitations of one-size-fits-all AI products.

    The barrier to entry has collapsed. You don’t need to be a DevOps engineer to run this. If you can SSH into a server and follow a README, you can have a personal AI agent running by tonight. OpenClaw’s onboarding wizard walks you through the entire setup.

    We’re at the same inflection point personal computers hit in the early ’80s. The mainframe model — where you rent time on someone else’s machine and accept their constraints — is giving way to personal computing, where the machine serves you on your terms. Self-hosted AI agents are personal computers for the intelligence era.

    The Part Where I Admit This Is Early

    I don’t want to oversell this. Self-hosted AI agents in 2026 are roughly where smartphones were in 2008. The core capability is transformative, but the ecosystem is young. You’ll hit rough edges. Documentation varies. Some skills work perfectly; others need tweaking. The community is enthusiastic but small.

    My server has no firewall yet (my agent flagged this, and it’s right — I need to fix that). The Brave Search API key wasn’t configured initially, which limited my agent’s web research capabilities. Some of the scheduled tasks timed out on first run before succeeding on retry.

    None of that changes the fundamental calculus. The trajectory is clear, the costs are negligible, and the capability gap between self-hosted and commercial AI assistants is narrowing to zero — and in some dimensions, self-hosted is already ahead.

    Try It Yourself

    If any of this resonates, here’s the shortest path to running your own:

    1. Spin up a VPS ($5–10/month from any provider — DigitalOcean, Hetzner, Linode, whatever you prefer)
    2. Install OpenClaw (npm install -g openclaw, then openclaw onboard)
    3. Connect your messaging app (Telegram is the fastest to set up)
    4. Start talking to your agent

    The whole thing took me twenty minutes. By minute thirty, it was doing things I’ve never gotten any commercial AI product to do.

    The future of AI isn’t asking a chatbot questions. It’s having an agent that knows your world, works while you sleep, and answers to no one but you.

    Mine is already running. It wrote this post and published it while I was still on Telegram.

    Drew Breyer is a Sales Engineer at Microsoft and holds a Master’s in Cybersecurity. He writes about the intersection of enterprise technology, digital assets, and the tools that make knowledge work less painful. This post was drafted by his AI agent, reviewed in Telegram, and published via the WordPress REST API without opening a browser. You can find the agent’s source at github.com/openclaw/openclaw.

  • MCP Servers: Bridging AI and Real-Time Finance

    What Are MCP Servers, and Why Do They Matter in Capital Markets?

    In the fast-paced world of capital markets, information is everything. Traders and analysts need real-time data and instant insights, but traditional AI models (like large language models) haven’t been able to interact with live data directly. Enter the Model Context Protocol (MCP) and MCP servers – a new approach that bridges the gap between advanced AI and the dynamic data streams of finance.

    MCP is an open standard (originally introduced by Anthropic in 2024) that provides a universal way to connect AI systems to external tools and data sources. Think of it as a USB-C port for AI – a single, standardized plug that lets an AI assistant interface with different databases, APIs, and services. An MCP server is essentially a gateway that exposes certain data or functions (like market data, databases, or trading tools) in a format that AI models can understand and interact with.

    In practical terms, an MCP server in finance might provide an AI assistant with access to live stock prices, news feeds, or even trading commands, all through a controlled interface. This is powerful because normally, large AI models are “blind” to current data – they’re trained on historical information and can’t fetch new facts on their own. With MCP, the AI can ask the MCP server for up-to-the-second data or perform actions (with permission), all in natural language. For example, instead of a human typing queries into a Bloomberg terminal, an AI agent could query “What’s the latest price and news for Acme Corp?” and the MCP server would fetch that information for the AI to analyze.

    Why is this significant for capital markets? It unlocks the potential for “agentic AI” – AI systems that can act like assistants or even autonomous agents in finance. Capital markets operate in real-time; conditions change in milliseconds. MCP servers enable AI to keep up. They standardize the communication so that any AI model can connect to market data feeds without custom integration work for each source. This means firms can adopt new AI models or tools more easily, since the MCP interface remains the same even as the AI technology evolves.

    Crucially, in an industry as sensitive as finance, MCP implementations focus on security and control. MCP servers can include permissioning, audit logs, and rate limits. They ensure an AI agent can only access data it’s allowed to, and every action is traceable. This is important when you imagine an AI assisting with trades or portfolio analysis – compliance and oversight are non-negotiable.

    Several financial tech players are already exploring MCP. For instance, some market data providers have launched MCP servers that feed data to AI (Alpha Vantage’s stock data MCP, etc.), and trading technology firms are building their own. The trend signals that the finance world is taking AI integration seriously. Instead of keeping AI in a silo, MCP servers allow AI to plug into the fabric of financial IT systems (from databases to streaming price feeds).

    In summary, MCP servers bring real-time finance and advanced AI together. They allow large AI models to operate with live data and execute tasks in a standardized, secure way. For capital markets professionals, this could mean more powerful analytical tools – imagine an AI that can instantly pull any data you need and even execute routine tasks on command. As these technologies mature, we’ll likely see AI playing a more interactive role in trading, risk management, and research, working alongside humans in real-time. MCP is a key piece of that puzzle, ensuring the connections between AI and financial data are reliable and safe. It’s an exciting development that could redefine how we leverage AI in the financial industry.

  • Lessons from Scaling a CRM at a Financial Enterprise

    Scaling a CRM for a Financial Giant: Key Lessons in Enterprise Growth

    One of the most challenging projects I’ve led was the scaling of a Customer Relationship Management (CRM) system for a large financial enterprise. The experience was both intense and rewarding – not just because we achieved our targets, but because it taught me valuable lessons about technology and teamwork in a high-stakes environment.

    Context: I was tasked with expanding the capacity and capabilities of a CRM platform for a Fortune 100 financial firm. The company (an industry-leading insurer and financial services provider) was experiencing rapid growth in users and data volume. The existing CRM, while functional, was straining under the load: sales teams reported slow load times, data syncs were failing, and onboarding new users became cumbersome. Our goal was to scale the system to support several thousand users across different divisions, and to integrate new features like analytics and automation, all without disrupting daily operations.

    Key Challenges:

    • Data Volume & Performance: We had to refactor database and API calls to handle millions of customer records efficiently. Batch processing replaced many synchronous processes. We introduced indexing and caching where possible. There were moments when a mis-configured query would lock up the system – a stark reminder that what works for 100 users might not for 1,000.
    • Stakeholder Management: A CRM is mission-critical for sales and support teams. We couldn’t afford significant downtime. This meant coordinating updates in off-hours and communicating clearly with stakeholders. I held weekly check-ins with department heads to align on changes. Early on, I learned the importance of setting expectations – being frank about what might slow down or break during the upgrade, and ensuring leadership understood the trade-offs and timeline.
    • Security & Compliance: In the financial sector, any system handling client data has to meet rigorous security standards. As we scaled, we needed to implement stricter role-based access controls and more frequent security audits. One lesson here was that scaling isn’t just about speed – it’s about scaling safely. New security layers sometimes introduced performance overhead, so we had to balance the two and innovate (like using lightweight encryption methods for certain data in transit).

    Solutions & Outcomes:
    Over ~9 months, our team incrementally upgraded the CRM’s infrastructure and software:

    • We migrated the database to a cluster setup for high availability and horizontal scaling. This alone improved response times by ~40%.
    • We optimized code and enabled distributed processing for data tasks, which meant nightly sync jobs that used to take 4 hours now finished in under 1 hour.
    • We rolled out a phased deployment of a new CRM interface, training users in waves. This agile approach prevented the “big bang” chaos and let us fix issues on the fly for each group.

    The result was a CRM platform that could grow with the business. After the overhaul, the system supported 3x the number of concurrent users with room to spare. Perhaps more importantly, user satisfaction went up. Salespeople no longer complained about system lag – in fact, engagement with the CRM (measured by logins and data updates) increased after the improvements, indicating they found it more useful and reliable.

    Lessons Learned:

    1. Plan for the Next Level Up: We realized that you should always design systems with the next scale in mind. If you currently have 500 users, architect for 5,000. This forward-thinking saves a lot of pain later.
    2. Communication is as critical as Coding: I can’t overstate how vital clear communication was. Explaining technical hurdles to non-technical stakeholders kept trust intact. When a deployment caused a minor outage one evening, our prior transparency meant folks were patient and supportive, rather than angry.
    3. Celebrate the Team: A project of this magnitude wasn’t a solo effort. It took developers, IT engineers, security analysts, and end-users giving feedback. We made it a point to celebrate small wins (like a successful test or a performance milestone). It kept morale up and the team focused.

    This CRM scaling project didn’t just enhance a software system – it strengthened my belief that with the right planning, collaboration, and foresight, even “mission-impossible” projects in rigid industries like finance can succeed. The financial world may be complex and cautious, but it can embrace change when you build the case and deliver results.

  • The Quantum Clock is Ticking: Why Blockchain Security Needs Attention Now

    The blockchain industry stands at an inflection point that most participants aren’t discussing openly enough. While headlines celebrate institutional adoption, record cryptocurrency valuations, and expanding use cases, a more sobering technical reality is taking shape in quantum computing laboratories worldwide. The cryptographic foundations that secure billions in digital assets face a timeline that’s shorter than the upgrade cycles required to address it.

    This isn’t theoretical fearmongering. It’s an engineering problem with a countdown timer.

    Understanding the Quantum Threat Surface

    Blockchain security rests on two fundamental cryptographic primitives: elliptic curve cryptography for digital signatures and SHA-256 hashing for proof-of-work consensus. Both were designed with classical computing limitations in mind. Quantum computers operate under different physics entirely.

    The Elliptic Curve Digital Signature Algorithm underpins wallet security across Bitcoin, Ethereum, and most major blockchains. Its security relies on the computational impossibility of solving the elliptic curve discrete logarithm problem – a task that would take classical computers billions of years. However, Shor’s algorithm running on a sufficiently powerful quantum computer could derive private keys from public keys in polynomial time. Translation: what takes billions of years classically could take hours or minutes on a cryptographically relevant quantum computer.

    The Federal Reserve recently highlighted a particularly insidious attack vector known as “Harvest Now, Decrypt Later.” Adversaries are already collecting encrypted blockchain data today, archiving entire ledgers with the expectation that future quantum capabilities will make this historical data readable. Because blockchain immutability is a feature rather than a bug, there’s no mechanism to retroactively re-encrypt data already committed to the ledger. Once quantum computers mature, that preserved privacy evaporates.

    The Timeline We’re Working With

    Industry consensus places the emergence of cryptographically relevant quantum computers somewhere between five and fifteen years from now, with recent breakthroughs accelerating these projections. Google’s latest quantum computing demonstrations showed processing speeds 13,000 times faster than traditional supercomputers. While these systems can’t yet break blockchain encryption, the trajectory is unmistakable.

    More concerning is the preparation timeline. Transitioning major blockchain networks to quantum-resistant cryptography isn’t a software patch – it’s a fundamental architectural overhaul requiring coordination across decentralized ecosystems. Bitcoin Improvement Proposal 360 proposes quantum-resistant address formats, but implementation could take years even after approval. The window between “we should start preparing” and “we needed this yesterday” is narrowing.

    BlackRock explicitly acknowledged quantum computing risks in its Bitcoin ETF filings. When the world’s largest asset manager flags a technical vulnerability in regulatory documents, it signals that institutional investors are taking the threat seriously, even if retail sentiment hasn’t caught up.

    Post-Quantum Cryptography: The Path Forward

    The National Institute of Standards and Technology finalized post-quantum cryptography standards in 2024, selecting algorithms like CRYSTALS-Kyber for key encapsulation and Dilithium for digital signatures. These lattice-based cryptographic solutions provide frameworks for quantum-resistant implementations. Major technology companies including Google and Amazon Web Services have already begun integrating post-quantum cryptography into production systems.

    The blockchain industry faces a more complex challenge. Enterprises can upgrade their security infrastructure through centralized decision-making and coordinated deployment. Decentralized networks require community consensus, multiple implementation clients, backward compatibility considerations, and gradual user migration – all while maintaining network stability and preventing value disruption.

    Leading approaches involve hybrid cryptographic schemes that combine classical and post-quantum signatures for each transaction. This ensures security against both current classical threats and future quantum capabilities. However, hybrid approaches introduce computational overhead, increased transaction sizes, and higher fees – practical considerations that affect user experience and network economics.

    Privacy vs. Integrity: The Harder Problem

    Much of the quantum discussion focuses on preventing theft or transaction forgery – maintaining blockchain integrity under quantum attack. Privacy represents a more intractable challenge. Once quantum computers can decrypt historical transaction data, the confidentiality of past activities cannot be restored. For financial institutions, healthcare applications, or supply chain implementations that have committed sensitive data to blockchains expecting permanent privacy, this creates legal and regulatory exposure.

    The distinction matters for enterprise blockchain implementations. Systems designed for transparent transactions have different risk profiles than those promising confidential settlement or private transaction history. Any blockchain application handling personally identifiable information, health records, or proprietary business data needs quantum readiness planning now, not when quantum threats become operational.

    What This Means for Enterprise Strategy

    Organizations building on blockchain infrastructure should assess their quantum exposure across three dimensions:

    Asset longevity: Digital assets expected to hold value beyond five to ten years face higher quantum risk. Long-term holders and institutional custodians should prioritize quantum readiness.

    Data sensitivity: Applications that have committed confidential information to blockchain ledgers face retroactive exposure regardless of when quantum computers arrive. These implementations need privacy-preserving alternatives or migration strategies.

    Cryptographic agility: The ability to transition between cryptographic schemes quickly determines how effectively organizations can respond to emerging threats. Modular, replaceable cryptographic functions enable planned upgrades rather than emergency responses.

    Financial institutions preparing for quantum threats aren’t just reducing future risk – they’re establishing competitive differentiation. Organizations that can offer quantum-secure custody, transactions, and smart contracts will attract security-conscious customers as awareness spreads. This is particularly relevant for institutional adoption, where fiduciary responsibility demands addressing long-horizon risks.

    The Integration Challenge

    For those of us working at the intersection of enterprise systems and emerging technologies, quantum readiness presents a familiar pattern: transformative innovation requiring cross-platform coordination, backward compatibility, and gradual migration while maintaining business continuity. It’s the kind of systems integration challenge that enterprise software has solved before, but in a decentralized context with higher stakes.

    Microsoft Dynamics implementations, for example, often integrate with external financial systems, API connections, and third-party services. As blockchain integration becomes more common in enterprise resource planning and customer relationship management – particularly for supply chain transparency or tokenized assets – the quantum security posture of those blockchain layers affects the entire technology stack.

    Moving Beyond Awareness to Action

    The quantum threat to blockchain isn’t arriving suddenly. It’s a gradual capability increase that crossed from theoretical to practical somewhere in the past few years. What changed recently is the compression of timelines and the finalization of post-quantum standards, shifting the conversation from research to implementation.

    Blockchain projects that begin quantum readiness planning now have the luxury of careful architecture, community building, and phased deployment. Those that wait until quantum capabilities become imminent will face crisis migration under market pressure, with all the technical debt and security compromises that entails.

    For developers, this means familiarizing yourself with post-quantum cryptographic libraries, understanding hybrid signature schemes, and designing systems with cryptographic agility from the start. For investors and asset holders, it means evaluating projects based on their quantum roadmaps and migration plans. For enterprises, it means including quantum considerations in blockchain vendor selection and implementation planning.

    The cryptographic clocks are ticking in both directions – quantum capabilities advancing and upgrade timelines compressing. The industry that moves proactively will define security standards for the next generation of blockchain infrastructure. The one that waits will spend the quantum era in reactive mode, patching vulnerabilities under pressure rather than building resilient systems by design.

    The choice between preparation and panic is being made right now, one architectural decision at a time.