A few weeks ago, attackers compromised Claude Code by exploiting its Sentry integration. The same vulnerability exists in Datadog, PagerDuty, and Jira. For accounting firms running AI assistants that touch client financials, this isn’t abstract risk. It’s a direct path from a monitoring dashboard to bank reconciliations, payroll journals, and tax worksheets.

If you’ve connected an AI tool to your practice management system, your document portal, or your month-end workflow, you’ve probably also connected it to a handful of monitoring and project tools. Those tools log errors, track performance, and send alerts. They also see everything your AI assistant sees. When one of those integrations is compromised, the attacker inherits access to every client record the assistant touched.

The VentureBeat report that surfaced this issue describes a straightforward attack: inject malicious instructions through a monitoring service, and the AI assistant executes them as if they came from a trusted user. No phishing email. No stolen password. The monitoring tool is already inside the perimeter, so the AI treats it as legitimate.

For a firm handling dozens or hundreds of clients, the exposure isn’t theoretical. One compromised integration can leak trial balances, bank statements, payroll data, and tax returns across your entire book of business. The question isn’t whether your AI tools are useful. It’s whether you know which third-party services can read what they’re doing.

The integration surface most firms don’t inventory

Most accounting practices that adopt AI start with a narrow use case. A partner tries an assistant that drafts journal entries, or a manager experiments with a tool that reconciles bank feeds. The assistant works, so the firm scales it. Within a quarter, the tool is handling month-end for twenty clients.

At the same time, the firm’s IT stack grows. Someone adds Sentry to catch errors in the new workflow. Another person connects Datadog to monitor API latency between the AI assistant and the practice management system. A third connects Jira so the development team can track bugs. Each integration makes sense in isolation. Together, they create a web of access that no one has mapped.

The problem is that these monitoring and project tools don’t just watch the AI assistant. They log the data the assistant processes. When the assistant pulls a client’s bank feed, Sentry logs the transaction. When it drafts a journal entry, Datadog captures the payload. When it flags a variance, Jira records the details. Each tool holds fragments of confidential client information, and each tool is a potential entry point for an attacker.

The VentureBeat report describes how attackers exploited this pattern. They compromised a monitoring service, injected instructions into the error logs, and waited for the AI assistant to read them. The assistant treated the injected text as legitimate input and executed the attacker’s commands. The same technique works across any monitoring tool that the AI assistant can read.

For accounting firms, the stakes are higher than for most industries. A leaked software log might expose user behavior or system performance. A leaked accounting log exposes client names, account balances, transaction details, and tax positions. One compromised integration can put your entire client base at risk.

What an AI security audit looks like in practice

Most firms don’t have a formal process for reviewing AI integrations. The assistant gets deployed, it works, and everyone moves on. The security review happens only after an incident, when it’s too late to prevent the leak.

A proper audit starts with a simple inventory. List every AI tool the firm uses. For each tool, list every third-party service it connects to. For each service, document what data it can access. The goal isn’t to eliminate every integration. It’s to know what’s connected and decide whether the access is justified.

In a typical firm, the inventory reveals three categories of integration. The first category is essential services that need full access. Your practice management system, your document portal, and your accounting platform all fall here. These tools hold client data by design, and the AI assistant needs to read them to do its job.

The second category is monitoring and logging tools that don’t need to see client data but do anyway. Sentry, Datadog, PagerDuty, and Jira fall here. These tools exist to track errors and performance, not to process financial records. But because they log everything the AI assistant does, they end up holding fragments of client information. The question is whether you can configure them to redact sensitive fields, or whether you need to disconnect them entirely.

The third category is legacy integrations that no one remembers adding. A Slack bot that was set up for a pilot project. A Zapier workflow that someone built to automate a one-time task. A webhook that connects to a service the firm no longer uses. These integrations are the highest risk because no one is monitoring them, and no one will notice if they’re compromised.

The audit also reviews how the AI assistant handles credentials. Does it store API keys in plaintext? Does it log client identifiers in error messages? Does it send data to third-party services without encryption? These aren’t hypothetical questions. The VentureBeat report describes attackers exploiting exactly these weaknesses.

For firms that run their own AI infrastructure, the audit extends to the hosting environment. Where do the models run? Who has access to the servers? Are the logs encrypted at rest? Are they retained longer than necessary? A compromised server can leak months of client data in a single breach.

For firms that use third-party AI platforms, the audit focuses on the vendor’s security posture. Does the vendor log your data? Do they share it with subprocessors? Do they allow you to delete it on demand? Most vendors publish security documentation, but few firms read it before signing the contract.

The output of the audit is a risk map. For each integration, document what data it can access, why it needs that access, and what happens if it’s compromised. Then decide whether to keep it, reconfigure it, or disconnect it. The goal isn’t zero risk. It’s informed risk, where you know what you’re exposing and why.

If you want a structured way to walk through this process, we’ve built a worksheet that maps the typical integrations in an accounting AI stack. The Month-End AI Close Map for Accounting Firms includes a checklist for each category of tool, so you can inventory what’s connected and decide what to keep. It’s a practical starting point if you’re running this audit for the first time.

How Omni isolates client data by design

When we built Omni, we designed it to avoid the integration sprawl that creates this exposure. Instead of connecting to dozens of third-party services, Omni runs inside your environment and talks only to the systems you explicitly authorize. The Month-End Close Agent pulls data from your bank feeds, your AP and AR systems, and your payroll platform. It reconciles the accounts, flags variances, and drafts journal entries. But it doesn’t send logs to Sentry, metrics to Datadog, or tickets to Jira. It writes its output to your practice management system and stops there.

This isn’t a feature we added after the fact. It’s the architecture we chose from the start. Most AI platforms are built to integrate with everything, on the assumption that more integrations mean more value. We took the opposite view. For accounting firms, more integrations mean more exposure. The value isn’t in connecting to every tool in your stack. It’s in connecting to the right tools and isolating everything else.

The Client Onboarding Agent follows the same pattern. It collects documents from new clients, sets up the chart of accounts, and produces a clean opening trial balance. It talks to your document portal and your accounting platform. It doesn’t talk to your monitoring tools, your project management system, or your error-tracking service. The data stays inside the workflow, and the workflow stays inside your environment.

This design choice has a cost. It means we can’t offer the same level of real-time monitoring that platforms like Datadog provide. We can’t send alerts to Slack every time a reconciliation fails. We can’t log every API call for post-hoc analysis. But for firms that handle confidential client data, those trade-offs are worth it. The monitoring tools that make debugging easier also make breaches easier.

The Advisory Insights Agent extends this isolation to the highest-value part of your practice. It reads each client’s monthly numbers, surfaces three things to talk about, and drafts the partner’s talking points before the meeting. The insights stay in your CRM. The draft talking points stay in your document system. Nothing leaves your environment unless you explicitly send it.

This doesn’t mean Omni is immune to attack. No system is. But it does mean the attack surface is smaller. An attacker who compromises a monitoring tool can’t read Omni’s logs, because Omni doesn’t send logs to monitoring tools. An attacker who compromises a project management system can’t inject instructions, because Omni doesn’t read tickets from project management systems. The only way in is through the systems Omni is designed to access, and those systems are already behind your firm’s security perimeter.

For firms that want to understand how this architecture applies to their specific stack, we run a 60-minute session we call the Omni Audit. It’s not a sales pitch. It’s a technical review. You walk us through your current AI tools, your integrations, and your data flows. We map the exposure, identify the highest-risk connections, and show you what a more isolated architecture would look like. You leave with three outputs: a risk map of your current stack, a list of integrations to review, and a design for an AI workflow that doesn’t leak client data through monitoring tools. Book a 60-min Omni Audit and we’ll schedule it within the week.

The dollar cost of a breach in an accounting practice

The immediate cost of a data breach is the notification and remediation. Most jurisdictions require firms to notify affected clients within 72 hours. For a firm with 200 clients, that’s 200 phone calls, 200 letters, and 200 conversations about what happened and what you’re doing to fix it. The partner time alone runs into tens of thousands of dollars.

The larger cost is the client churn. Accounting is a trust business. Clients stay with firms they trust and leave firms they don’t. A breach that exposes bank statements, payroll records, or tax returns breaks that trust. In our network, we’ve seen firms lose 15 to 25 percent of their client base in the year following a breach. For a firm doing $5 million in revenue, that’s $750,000 to $1.25 million in lost billings.

The third cost is the opportunity cost. A firm dealing with a breach isn’t selling advisory work. It isn’t onboarding new clients. It isn’t building the AI workflows that would have increased margin. It’s managing the crisis. For most firms, that crisis consumes three to six months of senior leadership time. At typical partner billing rates, that’s another $200,000 to $400,000 in foregone revenue.

Add it up, and a breach that leaks client data through a compromised monitoring integration can cost a mid-sized firm $1 million to $2 million in direct and indirect losses. That’s the range we typically see when we work with firms recovering from incidents like the one VentureBeat described.

The preventable part of that cost is the integration sprawl. Most firms don’t need their monitoring tools to log client data. They need them to log system performance. The fix is to configure the tools to redact sensitive fields, or to replace them with tools that don’t log application data at all. The cost of that fix is a few days of IT work. The cost of not doing it is seven figures.

What to do this week

If your firm runs AI assistants that touch client data, start with the inventory. List every AI tool you use. For each tool, list every third-party service it connects to. For each service, ask whether it needs to see client information. If the answer is no, configure it to redact sensitive fields or disconnect it entirely.

If you’re not sure which services have access, check your API logs. Most platforms log every outbound connection. Look for requests to Sentry, Datadog, PagerDuty, Jira, and similar tools. If you see client identifiers or account balances in those logs, you’ve found the exposure.

If you’re planning to deploy a new AI assistant, design the integration map before you deploy the tool. Decide which systems it needs to access and which systems it should ignore. Don’t connect it to monitoring tools by default. Connect only the tools that need to see the data, and configure them to log only what’s necessary for troubleshooting.

If you want a second opinion on your current stack, the Omni Audit for accounting and bookkeeping is designed exactly for this scenario. We review your AI tools, your integrations, and your data flows. We map the exposure and show you what a more isolated architecture would look like. You leave with a risk map, a list of integrations to review, and a design for an AI workflow that doesn’t leak client data. Book my Omni Audit and we’ll get it scheduled.

The attack that compromised Claude Code wasn’t sophisticated. It exploited a monitoring integration that most firms would have assumed was safe. The same vulnerability exists in your stack if you’ve connected AI assistants to Sentry, Datadog, PagerDuty, or Jira. The fix isn’t to stop using AI. It’s to stop connecting AI to tools that don’t need to see client data.

For more on how firms are building AI workflows that isolate sensitive data, see the Omni Ops page. For a broader look at AI security in professional services, visit the EDNA insights library. And if you’re ready to audit your current stack, the AI audit for accounting and bookkeeping is the fastest way to map your exposure and design a fix.