← Back

AI Security

My recent posts covered agent skills and how they can be used to codify business workflows. This post turns to the compliance side of the equation. Specifically, from a compliance perspective, what issues should companies be thinking about as they deploy AI tools in production.

From experience, by the time most companies start talking about AI policy, employees have already been using AI tools for months. At that point, the real question is not whether to allow AI use, but rather how to put enough structure around it that the company does not create problems for itself. This is particularly relevant to enterprise sales, security reviews, and customer procurement.

Most of the work in setting up the right structure comes down to three decisions:

  • which account tier the company uses
  • what categories of data can flow through it
  • when the company should move from a direct commercial API to infrastructure-level access such as AWS Bedrock, Azure AI Foundry, or Google Vertex AI

Account tiers

The first issue to consider is the type of account to use, as the gap between consumer and commercial accounts is larger than many teams realize.

Consumer accounts Consumer products like ChatGPT Free or Plus and Claude Free, Pro, or Max generally operate under consumer terms, which are most favorable to the AI lab. Under consumer terms, the labs can typically use their users' data to train their models (unless the user explicitly opts out), data retention periods are longer, and there is no Data Processing Addendum (DPA) available, meaning companies may be in violation of obligations to their customers to ensure any data protection requirements flow down to subprocessors. These accounts are fine for personal use, but they should not be used to process company data or customer data.

Commercial API accounts Commercial API accounts (e.g., Anthropic API, OpenAI API) are different. They typically operate under business terms, offer a DPA, and typically do not use customer data for model training by default. Retention periods are also much shorter. That makes API accounts the right baseline for any work involving company information, customer data, contracts, internal operations, or code.

Infrastructure-level access Infrastructure-level access sits one layer above the commercial APIs. With services like AWS Bedrock, Azure AI Foundry, or Google Vertex AI, the model runs on the cloud provider's managed infrastructure (not Anthropic's or OpenAI's infrastructure) so your data stays within your existing cloud perimeter, governed by your existing cloud agreement. The AI lab never receives your prompts or outputs. That matters when your customers care about working with data processors they are already comfortable with, or when data residency requirements apply.

The practical rule is simple. Personal AI accounts are for personal use. Company work should run through a commercial account.

Data classification

Separate from the account tiers, companies also need to define what data can be shared with AI models. Without that shared understanding, employees will make judgment calls that can put company and customer information at risk. One employee may paste a customer contract into a consumer AI tool because it "seems fine", while another employee avoids AI entirely because they are unsure what is allowed.

You do not need to create a complicated classification framework to solve this issue. Three categories are typically enough:

Category 1 — Unrestricted. Public information, general research, and non-sensitive internal documents. This data can be used with any approved AI tool.

Category 2 — Commercial tier required. Internal operating data, customer information, financial material, standard contracts, and similar business data. This data should only flow through a company-controlled commercial API account or infrastructure-level access.

Category 3 — Restricted. Legal strategy, M&A, fundraising materials, personnel matters, cap table information, core proprietary code, and anything subject to stricter confidentiality constraints. This information should either stay out of AI tools entirely or be routed through tightly controlled infrastructure-level access.

In practice, these categories can typically live in a one-page internal reference document that can be shared across the company and help ensure employees make the same judgment calls the same way.

Coding agents

Coding agents like Claude Code, Codex, Cursor, and similar tools deserve their own section because they have a broader attack surface than ordinary chat interfaces. A chat interface only sees what a user pastes into it, whereas a coding agent can inspect files, explore a code repository, and pull much more context into a request.

A few rules are helpful here:

  1. Coding agents should authenticate through a company-controlled commercial API account, not a developer's personal account.
  2. Secrets should be excluded from the agent's working context. Claude Code, Codex, Cursor, and similar tools allow for exclusion rules. At a minimum, teams should ensure .env files, credentials, keys, and other files and directories containing secrets are excluded from the model's context.
  3. Secrets should not live in readable files in the first place. If an agent can read them, treat that as an exposure risk and rotate the credentials.
  4. File access should be scoped with the same instinct you would apply to a contractor working for your company. Only give the AI agent access to what it needs to complete the specific task and nothing more.

For most teams, that structure should be enough. For more sensitive repositories, proprietary algorithms, or customer-bound environments, infrastructure-level routing may be the better setup.

Infrastructure-level access

The infrastructure-level access offered by Bedrock, Azure AI Foundry, Vertex, and similar products becomes useful when a company moves into the enterprise space and finds themselves interacting with customers who have specific requirements around who can process their data and where that data can be processed.

When you use Anthropic's API, Anthropic is the processor. When you use Bedrock, AWS is the processor and the request stays inside AWS infrastructure. For many companies, that distinction is important because it helps answer questions raised by enterprise procurement teams.

  • Does the provider train on our data? No.
  • Who is the processor? The cloud provider.
  • Where does the data reside? In the configured cloud region.
  • Can you audit usage? Yes, through the cloud provider's logging and identity controls.
  • Do we need a separate vendor agreement? Usually no, if the company already has a commercial agreement with the cloud provider.

The key point, though, is not to move too early. If you do not yet have a contractual or procurement reason to use Bedrock or Vertex, the additional setup is usually unnecessary. Commercial API access is enough for most teams.

Recap

To recap, if a company is going to use AI in production, three decisions should be made early:

  • Create a company-controlled commercial AI account and stop company work from flowing through personal accounts.
  • Document a simple data classification model with examples from the actual business.
  • Decide in advance when the company will use direct commercial API access and when it will route workloads through infrastructure such as Bedrock or Vertex.

Certainly not complicated, but much easier to do before customers start asking uncomfortable questions.