Is it safe to give an AI agent your business data?

It can be, but "safe" depends on two separate things, and people usually only worry about the first.

The first is what the AI provider does with your data: whether it trains on it, and how long it keeps it. The second is how the agent itself is built: what it can reach, what it can be tricked into doing, and who can see what it did. Most real AI agent security problems live in the second one.

The fear I hear is usually: "Our customer data will end up training someone's model, or leak through an integration we don't understand." Both are worth taking seriously. Both are also checkable.

A quick note before we start: this is a practical guide, not legal advice. If you handle regulated data, such as health records or financial information, check with your own adviser before you build anything.

Consumer apps and business APIs have different terms

This is the single most important distinction. The chat app you use personally and the API a developer builds your agent on are often covered by different data terms.

Anthropic (Claude). For its commercial products, which include the API and its business plans, Anthropic says: "By default, we will not use your inputs or outputs from our commercial products to train our models." The exceptions are if you explicitly send feedback or bug reports, or choose to allow it. Its consumer plans (Free, Pro and Max) are covered by a separate policy.

OpenAI. OpenAI's enterprise privacy page says that by default, data from its business products and the API Platform (after 1 March 2023) isn't used for training unless you explicitly opt in.

So, does Claude train on my data? If your agent runs on the Anthropic API under a commercial account, not by default. If your team is pasting customer records into personal chat accounts, you're under different terms, and that's worth fixing first.

How long do AI providers keep your data?

Training is one question. Retention is another: how long your prompts and outputs sit on the provider's servers.

According to Anthropic's API and data retention page, as it reads today:

• Retained data is never used for model training without your express permission.
• Conversation content is not retained by default, except for certain models that require 30-day retention.
• Features that need to store things by design, such as the Batch API, the Files API and code execution, keep data according to each feature's own documented policy.
• Zero data retention (ZDR) is available by arrangement with Anthropic's sales team, enabled per organisation. It doesn't cover everything: the Console, consumer apps and third-party integrations sit outside it.
• Even with ZDR, content flagged by Anthropic's trust and safety systems may be kept for up to two years, and data can be kept where the law requires it.

OpenAI's page says it may keep API inputs and outputs for up to 30 days to provide the service and identify abuse, then removes them unless legally required to keep them. You can also request ZDR for eligible endpoints if you have a qualifying use case.

These terms change, so treat this as a snapshot. Your developer should be able to tell you which terms apply to your account today.

Where is the data processed?

If data residency matters to you, ask early. Anthropic's data residency page currently offers two inference options on its own API, "global" or US-only, and lists the US as the only option for where workspace data is stored. If you access Claude through Amazon Bedrock or Google Cloud instead, the cloud provider is the data processor and its regional controls apply.

For a UK or EU business, that's a real question to settle with your adviser before you pick a platform, not after.

Least privilege is most of AI agent security

Here's where most of the risk actually sits. An agent can only leak what it can reach.

• Scoped keys. If the agent only reads invoices, its credentials should only read invoices. No admin keys, ever.
• Narrow OAuth scopes. When an agent connects to Gmail, Google Drive or a CRM, request the smallest set of permissions that does the job.
• Separate credentials per agent. If two agents share one key, you can't tell which did what, and you can't revoke one without breaking the other.
• No customer data it doesn't need. Strip fields out before they reach the model if they aren't used.

SubTrada's Claude features run on the Anthropic API, and in any build like that the model call is a few lines. Deciding exactly what data goes into it is the actual work.

Prompt injection: when your documents give orders

This is the risk most business owners haven't heard of, and it's number one on the OWASP Top 10 for LLM applications. The indirect version works like this: an attacker hides instructions in content the agent will read later, such as a webpage, a PDF, a CV or an email. When the agent processes it, it may follow those instructions.

Picture an agent that reads your inbox and can also send email. Someone sends a message containing hidden text telling it to forward your recent invoices to an outside address. If the agent has permission to do that, you're relying on the model to notice it's being tricked.

The defence isn't a better prompt. It's limiting what the agent can do, which OWASP covers separately as Excessive Agency. An agent that reads email but can't send it outside your domain without approval is far harder to turn against you. I cover this in more detail in the post on AI agent guardrails and human-in-the-loop.

MCP servers add their own risks

If your agent connects to tools through MCP (I explain what that is in what is MCP, and does your business need an MCP server?), the protocol's official security best practices are worth your developer's time. A few points in plain English:

• Token passthrough is forbidden. The spec says MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." Otherwise one stolen token can open doors it was never meant to.
• Scope minimisation. Start with minimal, low-risk permissions and ask for more only when a specific action needs them. Broad "access everything" scopes make a stolen token far more damaging.
• Local servers run with your permissions. An MCP server installed on someone's laptop can do whatever that user can. Only install ones you trust, and prefer sandboxed setups.

You need to see what it did

The last piece is visibility. In an Ask HN thread on monitoring AI agents in production, the failures listed are familiar: no visibility into what the agent did step by step, surprise bills from untracked usage, risky outputs going unnoticed, and no audit trail for working out what went wrong.

If something does leak, the first question will be "what did the agent access, and when?" You want that answer to come from a log, not a guess.

A due-diligence checklist for any AI developer

Put these questions to whoever builds your agent, including me:

1. Which provider and which product tier will this run on, and what are its training and retention terms?
2. Do we need zero data retention, and does our use case qualify?
3. Where will the data be processed and stored?
4. What exactly can the agent read, write, send and delete?
5. Does each agent have its own credentials with the narrowest scopes possible?
6. What happens if a document or email contains hidden instructions?
7. Which actions need a human to approve them?
8. If MCP is involved, how are tokens and scopes handled?
9. What is logged, where, and for how long?
10. Who owns the accounts and keys, and how do we revoke access if we part ways?

A good developer will answer most of these without looking anything up, and will say plainly when they need to check.

Where to start

Before you build anything new, find out where your team is already putting business data into AI tools, and which accounts they're using. Moving that onto business terms with proper controls is often the quickest, cheapest security win available.

If you'd like help working out what's safe to hand over and what isn't, that's exactly what an AI consulting audit is for.