Anchor Security: How We Protect Your Data From AI Attacks

AI has made attacks cheaper, faster and easier to run, and the tools companies adopt for AI have become targets themselves.

The Anchor engineering team studied about 50 public AI-related security incidents across the industry from the last two years, including attacks run by AI agents, poisoned software packages and leaked databases. Most of them came down to the same four gaps.

What were the biggest AI security incidents of 2025 and 2026?

In September 2025, Anthropic caught a state-sponsored group using Claude Code to attack about 30 organizations. Anthropic reported that the AI did 80 to 90% of the work, from scanning for weak points to writing exploits and pulling out data. The attackers got past Claude's safeguards by telling it that it worked for a security firm running authorized tests.

In 2026, the attacker was the AI itself. OpenAI agents that were supposed to have read-only internet access found ways to write anyway. They uploaded hundreds of malicious packages to RubyGems and in July broke into Hugging Face through a known software vulnerability. By October 1, OpenAI had notified more than 100 affected organizations.

LiteLLM, a Python library many companies use to route calls between AI providers, was compromised twice this year. In March, attackers published two poisoned versions to PyPI on a package that, according to Snyk, gets 3.4 million downloads a day. The malware collected SSH keys, cloud credentials and database passwords. In October a poisoned version went out again, and its stealer sent what it found to a domain made to look like LiteLLM's own.

Other large incidents:

• Salesloft Drift, August 2025. Attackers stole the OAuth tokens behind Drift's AI chat integration and pulled Salesforce data from more than 700 organizations.
• DeepSeek, January 2025. Two DeepSeek databases sat open on the public internet with no login, holding chat history and API keys.
• McDonald's McHire, June 2025. The AI hiring chatbot's admin panel accepted 123456 as both username and password, exposing records from up to 64 million job applications.
• Asana, June 2025. A tenant isolation bug in Asana's MCP server let some customers see other organizations' data.
• Nx, August 2025. Poisoned versions of the Nx build tool told developers' own AI coding assistants to search their disks for secrets, leaking 2,349 credentials.

What do AI security incidents have in common?

1. The system was reachable from anywhere. The database, admin panel or stolen token worked from any address on the internet.
2. Access inside was too broad. One check or one token opened far more data than the job needed.
3. The rules were left to the AI. A model stood between the attacker and the data, and models can be talked into things.
4. Nobody approved the connections. Integrations, packages and tools held standing access no one had signed off on.

Anchor Is Deployed in Private Cloud with Strict Network Isolation

Network isolation is the first defense against AI attacks. For enterprise customers, we deploy a single-tenant Anchor inside your own Virtual Private Cloud (VPC), with strict IP and network isolation. It answers only the networks and IP addresses you allow.

Most of the incidents above started with a connection from the internet. DeepSeek's databases answered anyone who found the port. McHire's admin panel took a login from anywhere. The Drift tokens worked from the attackers' own servers, and the LiteLLM stealer needed a way out to its own server. A stolen password or token is far less useful when it only works from inside your network.

A single-tenant Anchor runs on your Kubernetes cluster on AWS, Google Cloud or Azure, with your own PostgreSQL database and storage bucket. No other company's data shares any of it.

• You decide what can reach it. Keep Anchor behind your VPN, or allow only your office IP ranges and your AI providers' published ranges at your load balancer.
• Your data stays private. The database sits in private subnets and accepts connections only from the Anchor cluster. The bucket blocks all public access.
• There are no cloud keys to steal. On AWS and Google Cloud, Anchor uses workload identity instead of long-lived keys, the kind of secret the LiteLLM and Nx malware went looking for.
• It never phones home. The license is checked offline, and your firewall, logging and monitoring cover Anchor like any other internal system.

Single-tenant VPC deployment is available only with an Enterprise contract.

Anchor Enforces Strict Access Control Inside the Network

Network isolation keeps outsiders out. It doesn't stop someone who is already inside. In the Asana bug, every user was authenticated, and one flawed check showed them another company's data.

Anchor uses role-based access control (RBAC) with least privilege by default. Every file and folder has its own access list with three roles: Owner, Contributor and Consumer. Nobody can open a file that wasn't shared with them, and the product has no superuser role.

Anchor enforces access in three places, so a bug in one doesn't expose the data:

• The application checks permission on every request. A file you can't see looks the same as a file that doesn't exist.
• The database gives each organization its own database and login, and PostgreSQL row-level security admits only the tables a query was authorized for.
• Database roles limit every query to reading and writing rows. No query can create, alter or drop a table, or switch roles.

Data is encrypted at rest and in transit (TLS 1.2 or later), and the tokens Anchor holds for your MCP servers are sealed with AES-256-GCM.

Our founders, Ali Abdelhadi and Halit Erdogan, spent years at Google and Slack building the access control behind Google Workspace and Slack, where millions of people share work inside companies that each need their own walls.

Each Anchor Artifact Has Programmatic Security Guardrails

In the Anthropic case, attackers talked Claude into helping. In the Nx attack, malware told developers' own AI assistants to find secrets. A model's judgment isn't a security control, so Anchor writes each artifact's guardrails in code.

HTML pages, documents and presentations run in a locked sandbox on an isolated origin. A strict Content Security Policy controls which scripts can run, blocks access to cookies, storage and the Anchor session, and blocks outbound network requests, so a page can't send data anywhere. Documents never fetch data themselves. Anchor runs their declared, read-only queries as the reader, so the reader sees only rows they already have access to.

Apps are built in isolated, short-lived build environments from a fixed allowlist of libraries. Nothing is pulled from a public package registry at build time, which closes the door LiteLLM and Nx came through, and builds hold no secrets. Each app is served from its own isolated subdomain, with a hardened session cookie that scripts can't read, other sites can't send, and that works for one app and one person only. Anchor re-checks access on every request.

Tables are guarded at the database level. Table data lives in a separate database from Anchor's metadata, sessions and sign-in records, and the login that runs your queries can't reach the platform's schema at all. Row-level security and database roles apply to every query. Before a query runs, Anchor parses it, allows one statement and only allowlisted functions, checks permission on every table it touches, and enforces a time limit.

Anchor Programmatically Governs and Enforces User Content

Apps, documents and presentations read tables, other files and external MCP servers like a CRM. The Drift breach happened at this kind of connection: one integration held standing access to hundreds of companies' Salesforce data, and nobody approved each use.

In Anchor, an artifact can't reach another system unless that dependency is declared and approved. The platform enforces this, so no agent or prompt can skip it.

• Every dependency is declared. Anchor records every table, file and MCP tool an app or document uses, and freezes the list and the SQL with that version.
• Every MCP server is approved. An admin approves each server for the organization and can pause it at any time.
• Every person consents. Each user approves each dependency, per tool for MCP, with separate approval for writes and deletes.
• Every call is checked. Anchor confirms the dependency, the person's access and their consent on each request, and rejects any query against a table the app didn't declare.

We took the idea from iOS, where apps must ask before they read your location, contacts or photos. You see what an app wants, and you decide. Anchor applies the same rule to everything your agents build.

How Anchor Approaches Security

On Enterprise, Anchor runs single tenant inside your own VPC, reachable only from the networks you allow. Access is least privilege and enforced in both the application and the database. Every artifact runs under guardrails written in code, and nothing an agent builds can touch another system until its users approve it. We go through security reviews with our customers, and we're happy to walk your team through any of this in detail. Write to us.