DEV Community: Mateus Medeiros

The Banking System Is Not Ready for AI-Powered Attacks

Mateus Medeiros — Tue, 21 Jul 2026 10:56:38 +0000

Over the past two months, I experienced three security incidents at the fintech where I work as a tech lead.

I won't go into which company it is, the exact amounts involved, or which partners failed. But I'll share what happened with the honesty of someone who was in the middle of the fire, and what it made me think about what's coming.

There's a silent pattern in mid-sized fintechs: engineering grows fast, the product is good, developers are skilled, and security keeps getting pushed to later. Not out of negligence, but because the cost of ignoring it feels abstract until the day it isn't.

How a Real Attack Actually Happens

The popular image of a hacker involves someone furiously typing in a black terminal, trying passwords until one works. Reality is far less cinematic, and far more unsettling.

Of the three incidents I experienced, none involved brute force.

In one of them, a partner of ours had their credential database leaked. The attacker arrived with a copy of the house keys, no need to break in. They managed to move a significant amount of money across accounts before we could stop them.

In another, it was pure social engineering. The attacker somehow obtained a client's credentials, logged in, realized they didn't have the transactional PIN, and opened a support ticket pretending to be the client, even sending a photo holding an ID document. Our support team processed the request. The phone number used was different from the one on file. Nobody noticed.

The weakest link in any system is always human. The best encryption in the world doesn't matter if someone answers the wrong phone call.

Why Our Current Defenses Aren't Enough

After each incident, we asked the right questions: what failed? what could have prevented this?

We reached some uncomfortable conclusions.

The government reversal mechanism doesn't work for this type of attack. Brazil has a special mechanism designed to trace and reverse fraudulent transactions. In theory, it's the financial system's shield against fraud. In practice, it takes days, weeks, sometimes months to act. A competent attacker pulverizes the stolen balance across dozens of mule accounts, which forward to others, which forward to others. Within hours, the trail is nearly untraceable. We filed the request more out of procedure than genuine hope of recovering the money.

Partners' fraud detection is too generic. Our banking partner blocked roughly half the amount transacted in one of the incidents. That helped, and I'm grateful, but the half that wasn't blocked was enough to cause real damage. The problem isn't partner incompetence: it's that a fraud system built to serve thousands of different clients tends to be conservative and generic. It doesn't know the specific transactional pattern of your business.

Condominiums, for example, have extremely predictable financial behavior. Payments happen in specific windows of the month, to corporate accounts, in amounts that follow a historical pattern. A transfer to an individual, outside business hours, above the historical amount for that account is trivially suspicious to someone who knows the domain. To a generic fraud system, it's just another transaction.

What Changes With AI

Recently, major AI labs announced they're working on models capable of autonomously finding vulnerabilities in software systems. There's obvious market interest in those statements, FOMO sells, but there's also genuine truth to them.

A human attacker has limits. They sleep. They make mistakes. They have a finite set of technical knowledge. They need time to analyze a system, identify attack surfaces, test hypotheses.

An AI-powered attacker has none of those limitations.

The speed of exploitation is going to shift by an order of magnitude. What today takes days of manual analysis could take minutes of automated scanning. And the systems that are exposed, APIs without IP validation, forgotten old endpoints still running on the internet, credentials that have never been rotated, are going to be found much faster than any security team can react.

I'm not speculating about a distant future. I'm describing the present with one new variable added.

What You Can Do Right Now

I'm not writing this to cause panic. I'm writing it because most effective defenses are relatively simple to implement, and most companies still haven't done them.

Eliminate long-lived exposed credentials. Production credentials shouldn't exist in .env files on developer machines or be injected as environment variables in Kubernetes pods. They should be fetched at runtime from a secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault). The overhead is small. The gain is enormous.

Add mutual TLS (mTLS) to your B2B APIs. If you have an API that partners integrate with, mTLS is the proper long-term solution: both sides present certificates, so the connection is authenticated at the transport layer regardless of what's in the payload. IP allowlisting is a valid quick win (it's what we did after our incident, and it stopped the immediate bleeding), but it's not a substitute. IPs rotate, VPNs exist, and cloud-native architectures make stable IP ranges increasingly rare. mTLS doesn't have those weaknesses.

Build your own fraud detection, even if simple. You know the transactional behavior of your domain better than any partner does. Basic rules based on historical pattern, time of day, beneficiary type, and amount already capture most obvious anomalies.

Implement credential rotation. Credentials that never expire are credentials that may have been leaked years ago without your knowledge. A periodic rotation process, even semi-manual, drastically reduces the impact of a past breach.

Audit access for former employees. It sounds obvious. Most companies don't do it systematically. Make it a mandatory step in your offboarding process.

Define security protocols for your support team. Social engineering works because support teams prioritize resolving the customer's problem over verifying who the customer actually is. Write down what your team is and isn't allowed to change without additional verification, and what that verification looks like. A checklist isn't glamorous, but it closes the gap that cost us tens of thousands of dollars.

Monitor actively, not passively. Logs exist to be read. If you're discovering incidents because a client complained, you're already late. Invest in alerts, dashboards, and if possible, automation that catches anomalies before they become incidents.

A Question I Can't Stop Asking

I've thought about what would have happened if the attacker we faced had an AI on their side. Not for phishing at scale, but to systematically scan our APIs for unauthenticated endpoints. To test payload variations against our routes. To identify patterns in error responses that reveal internal structure. To do in minutes what took weeks of manual analysis.

The honest answer is: I don't know if we would have held.

And if that's true for us, with all the attention we've dedicated to security over these two months, it's true for the vast majority of fintechs operating today.

The ground is shifting. The question isn't whether you'll be attacked. It's whether you'll be ready when it happens.

If you've been through something similar or have a different perspective, I'd love to hear it in the comments.

I Turned Claude Code Into a Personal AI Butler That Runs My Life

Mateus Medeiros — Mon, 08 Jun 2026 13:21:13 +0000

Not another chatbot wrapper: a proactive assistant that runs on Claude Code headless, wired into my whole life through MCP.

Introduction

Most generic AI assistants are smart but forgetful. They know a lot about the world and nothing about you. Every conversation starts from scratch. Every question is answered generically. Ask them to help you plan your week and they'll give you a productivity framework from 2019.

I wanted something different. I wanted an assistant that knows I lead engineering at a fintech, that I'm working through a GTD backlog, that I've been putting off a specific task for three weeks, that I go to sleep around midnight, and that I absolutely hate soup for dinner.

So I built Jarvis.

This isn't a tutorial. It's a walkthrough of what I built, how I built it, and why the combination of context, MCP, and Claude Code changed how I think about personal tooling.

Part 1: What Jarvis Does

Let me give you a concrete example before I list anything.

Ten minutes before a call with my CTO, I hadn't opened Slack, hadn't reviewed my notes, hadn't done anything. Then, across the room, my Alexa spoke up in Jarvis's voice. It had pulled the last three technical decisions we had open, flagged an unread DM that was likely to come up, and surfaced something I'd written in my diary two days earlier that was directly relevant. I walked into that call better prepared than I would have been after an hour of manual review, and I hadn't asked for any of it. And it doesn't stop when the call ends: afterward, Jarvis reads back through the meeting, the calendar entry, the notes, what was discussed, picks out the loose ends that landed on me, and files them as tasks in my GTD. By the time I'm back at my desk, the follow-ups are already waiting, categorized and prioritized, without me writing a single one of them down.

That's what "useful" looks like in practice. Not "it can do X," but "it showed up before I even knew I needed it."

But "useful" is only half the story. The other half still catches me off guard: Jarvis improves itself.

A few weekends ago I was driving to the mall with my wife. I wanted to hand a couple of things off to Jarvis, but I wasn't about to type paragraphs into Telegram from behind the wheel, and at that point it only understood text. So, stopped at a red light, I told it to fix exactly that: add support for receiving voice messages on Telegram. It delegated the work to Claude Code, which branched, wired up the transcription pipeline, and opened a pull request. I merged it right there, still in the car, and my very next message to Jarvis was a voice note.

Read that back: I used the assistant to give the assistant a new way for me to use it. It didn't just run a task; it extended its own surface area, on request, while I kept my hands on the wheel.

Here's what makes that possible. Jarvis is connected, via MCP (Model Context Protocol), to everything I actually use:

Productivity & Work
Google Calendar, Gmail (two accounts: personal and professional), Google Drive and Docs, Slack. Full GTD task management with categories, priorities, due dates, and statuses. The assistant doesn't just read these; it can act on them, create events, search emails, list tasks by energy level, or find a document buried in a folder I haven't opened in months.

Personal life
A reading list, a games backlog, a watchlist for films and series, a link library. And the watchlist isn't just a place things sit: every Saturday evening, based on how my week went and what I've already watched, Jarvis suggests something new to add. A personal finance module connected to real bank data, not manual entries. A diary with structured entry types (personal, work, technical, idea, meeting, learning). And a shopping list, because even butlers deal with groceries.

Memory: the part that changes everything
Jarvis has two memory layers. Structured facts, the things I've explicitly told it to remember: my name, my wife's name, the football team I support, the birthdays that matter, the company I work for, and that I hate soup for dinner. And semantic memory, a Pinecone vector store that indexes conversations, diary entries, and patterns over time. Before answering anything contextual, it queries that store. When I mention "that infrastructure decision from last week," it knows what I mean. When I ask about someone by name, it already has context.

Automated Routines
This is where it stops feeling like a tool and starts feeling like an actual assistant. Jarvis has 31 scheduled routines running throughout the week. The ones that matter most:

Morning briefing: before I open anything, I already have the day: calendar, tasks, messages worth knowing, how my investments did overnight, and what's going on in the world. The day starts contextualized.
Pre-meeting briefing: what you just read above. Polls the calendar every 15 minutes, fires exactly once per meeting, 10 to 25 minutes before it starts.
Finance report: weekly summary of spending, investments, and outstanding debts. Finds me; I don't chase it.
Weekly review: once a week it walks my GTD with me, what moved, what stalled, what's been sitting in 'waiting' too long, and helps me reset for the week ahead.
Deadline alerts: tasks approaching their due date surface automatically.

The assistant also has a persona: a dry British wit that occasionally points out when you're repeating yourself. It's not neutral, and that's on purpose.

Part 2: How It's Built

The Stack

The backend is a FastAPI application on Python 3.14, running on a Compute Engine VM on GCP behind Nginx. Data lives in Google Cloud Datastore, a managed NoSQL document database.

MCP as the Integration Layer

MCP (Model Context Protocol) is what makes this scale without becoming a mess. Each domain is its own MCP server: Google Workspace, Slack, GTD, Finance, Diary, Memory, Alexa, and more. Twelve servers in total, exposing 35+ tools to the agent.

The agent stays clean. Adding a new integration means writing a new MCP server, not touching the orchestration logic.

Claude as the Brain

The agent is a Python runner, but it doesn't call the Anthropic API directly. Instead, it shells out to Claude Code running headless (claude -p), handing it the persona and system instructions, the MCP server config, and an allow-list of tools. Claude Code does the heavy lifting: it builds the context window, connects to every active MCP server, and drives the tool-calling loop. The runner just feeds it the user message and parses the structured JSON ({response, actions}) that streams back. The neat part: the same Claude Code that writes Jarvis's code is also the engine that runs it. The assistant doesn't just get built by an agent; it is one.

A Persona, On Purpose

Jarvis's personality lives in its own file, persona.md, kept deliberately separate from the operational instructions that tell the runner how to behave (output format, channel rules, when to delegate to Claude Code). The mechanics change often; the identity shouldn't. Splitting them means I can rewrite how Jarvis works without ever touching who Jarvis is, and the character stays consistent across every channel, whether it's answering on Telegram or speaking through an Echo.

And it's a real persona, not a one-line "be friendly and concise." It's a full character brief: an impeccable British butler who happens to run complex systems, dry wit by default, always first person, never the telemarketing enthusiasm of "Great question!" The file even ships with calibration examples so the tone stays sharp:

"Meeting tomorrow at 2pm. I've filed it under 'this time he actually shows up.'"

"The bug is on line 47. The real cause is an architecture decision from two weeks ago, but let's pretend we didn't see that for now."

That's the difference between an assistant that answers and one you'd actually want around. Generic is a choice, and I chose against it.

OpenAI as a Supporting Layer

While Claude drives conversations, OpenAI handles specific tasks: Whisper transcribes the voice messages I send over Telegram, and DALL-E 3 handles image generation (when I asked Jarvis what it thought it looked like, it drew its own self-portrait).

Channels

Telegram for async. The voice side started from a constraint I'd built for myself: I have six Echo devices around the house, one per room, and I wanted to actually put them to use, just not as Alexa. I wanted them to speak as Jarvis. So for voice, the pipeline goes: response text → ElevenLabs → custom audio file → Alexa device. Jarvis speaks in its own voice, not Amazon's default TTS.

But the proactive side is where it gets technically unusual.

Amazon's official Alexa Skills Kit is reactive: it waits to be called. If you want the assistant to speak up on its own, whether a morning briefing, a deadline alert, or a pre-meeting summary, the Skills Kit won't help you. So I reverse-engineered the internal Amazon API. It's undocumented. It's unofficial. Amazon could break it tomorrow. But it's the only path to an assistant with genuine initiative, and to me, that tradeoff was obvious. The fragility is a feature, not a bug: it means I had to care enough to go find it.

Semantic Memory

Conversations, diary entries, and pattern analyses get turned into vectors with OpenAI's text-embedding-3-small and upserted into a Pinecone index, each one tagged with a timestamp and type. Before responding to anything contextual, Jarvis embeds the incoming message and runs a top-k similarity search, pulling back the handful of past moments closest to what I'm asking about right now. A separate nightly routine does the heavier lifting: it reads back over the last day, distills behavioral patterns, and writes those summaries back into the same store, tagged as pattern_analysis, so the next morning's briefing can reference them. The result is what makes it feel continuous: not a chatbot that resets, but something that was paying attention yesterday too.

Routines via Cloud Scheduler

31 cron jobs, fired as HTTP calls from Cloud Scheduler to internal Nginx routes. Each job fetches context (diary, tasks, semantic memory, calendar, Slack), builds a prompt, calls Claude, and sends the result via Telegram or Alexa.

Built with Claude Code

Here's the part that still surprises me every time: I built almost all of this using Claude Code, Anthropic's agentic coding tool that runs in the terminal.

The workflow: I describe what I want, Claude Code creates a branch, implements it, commits, and opens a PR. I review and merge. For most features, I never write a line of code manually. The agent understands the codebase, follows the established patterns, and usually makes the call I would have.

This creates a feedback loop that's genuinely strange to describe. The assistant I'm building is also my development partner. When I ask Jarvis via Telegram to add a feature, it delegates to Claude Code, which opens a PR. The system extends itself.

What It Costs to Run

I expected a system this involved to be expensive. It isn't.

Claude, the brain: $20/month. Jarvis runs on a Claude Pro subscription through Claude Code, not the metered API, so there's no per-token bill no matter how much I talk to it. It even routes models by task: Haiku for everyday conversation, Opus when it's writing code.
GCE e2-small VM: ~$13/month. A single small Compute Engine instance hosts the whole backend.
ElevenLabs voice: $6/month on the Starter plan, and even that is optional: there are free TTS options if you don't mind dropping the custom voice.
OpenAI (Whisper, DALL·E, embeddings): under $2/month. Usage is low and these are cheap per call.
Pinecone, Pluggy, and the rest of GCP (Datastore, Cloud Scheduler): $0. All comfortably inside their free tiers.

All in, Jarvis runs for around $40 a month, and the single biggest line item is a consumer Claude subscription I'd probably be paying for anyway. The part that should feel expensive, the always-on intelligence, is the part that's basically flat-rate, precisely because it runs on Claude Code instead of billing me by the token.

What Makes It Actually Useful

The gap between "AI assistant" and "useful AI assistant" is almost entirely context. Generic assistants are impressive in demos and mediocre in practice because they have no idea who you are.

What made Jarvis cross that gap:

Deep integrations: not API wrappers, but MCP tools with real access and real schemas
Persistent memory: facts you tell it and patterns it finds on its own
Proactive outputs: it shows up, it doesn't just respond
A persona with opinions: less tool, more collaborator

It's not perfect. MCP servers disconnect. Prompts drift. Occasionally it contradicts something from last week. But it's useful in a way that no off-the-shelf assistant has been, and at this point, I'd notice if it disappeared.