Securing your AI work: from first chat to what you ship

// 01 · Level 1 of 6 · Using AI safely

Talking to AI

What can go wrong

Most of the risk here is what you hand over. Customer names, emails, contracts, someone's CV, an internal strategy doc. Once it's in a chat it's in someone else's system, and depending on the tool and your settings it may be kept, used for training, or readable by connectors you switched on months ago and forgot about.

The checks

1. Is this tool approved for this kind of data? Work data goes into the tools work has approved, not whichever one is open.
2. Does anything here identify a person or a client? If so, take it out or replace it before it goes in (names to roles, real numbers to rough ones).
3. Are the privacy settings checked: are chats used for training, how long are they kept, what does memory store?
4. Which connectors are on, and what can each one read? A connector to your email or drive means the AI can read that too.

What to use

// 02 · Level 2 of 6 · Using AI safely

Making things with AI

What can go wrong

AI makes it very quick to publish something, and that's where small things slip through. A "private" link that anyone with the URL can open. A client's name in a proposal when the contract says it can't be used. A file you share that still has your own notes, a folder path or someone's name buried inside it. Or something that copies another company's material or look a bit too closely.

The checks

1. Who can open this? Check the share setting itself, not what you think it is.
2. Does anything here breach the contract or create a liability, like a client name you're not allowed to use?
3. Read the whole thing as the person receiving it would, including speaker notes, hidden slides, comments and file names.
4. Search for leftovers: "lorem", "TODO", "test", "example.com", your own name, client names, file paths.

What to use

// 03 · Level 3 of 6 · Using AI safely

Letting AI work on your machine

What can go wrong

Once an AI agent can read files and run commands, it can also read the files you'd never paste into a chat: the .env file with your API keys, your SSH keys, your cloud credentials. It can run a command that deletes something, and it can install a package that does far more than it says. Packages are the part most people underestimate. The AI suggests one, you say yes, and its install script runs on your machine before you've looked at it. AI can also suggest a package name that doesn't exist, and attackers register those names so the next person to accept the suggestion gets theirs.

The checks

1. Can the AI read your secrets? It shouldn't be able to, and a rule in the tool's settings is more reliable than asking it nicely in a prompt.
2. Which commands must always ask first? Deleting files, pushing code, deploying, anything that spends money.
3. Before installing a package: is it the real one (check the spelling character by character against the docs you got it from), is it maintained, who publishes it, and does it run scripts on install?
4. Is the lockfile committed, so the same versions install every time?
5. Skills and plugins for your AI are packages too. Before installing one, read its SKILL.md and check its security audit. When Snyk scanned 3,984 public agent skills in February, it confirmed 76 with malicious payloads. Vercel's skills.sh directory now shows audits from Snyk, Socket and Gen on each skill page.

What to use

{
  "permissions": {
    "deny": [
      "Bash(env)",
      "Bash(env:*)",
      "Bash(printenv)",
      "Bash(printenv:*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  }
}

default_permissions = "protect-secrets"

[permissions.protect-secrets]
extends = ":workspace"

[permissions.protect-secrets.filesystem.":workspace_roots"]
"**/.env" = "deny"
"**/.env.*" = "deny"
"**/*.env" = "deny"

[permissions.protect-secrets.filesystem]
"~/.ssh" = "deny"
"~/.aws" = "deny"

// 04 · Level 4 of 6 · Protecting what you build

Apps you build with AI

What can go wrong

AI is very good at making an app that works and much less reliable at making one that's locked. The common gaps are keys sitting in front-end code where anyone can view them, databases where any logged-in user (or anyone with the app's public key) can read every row, and forms that trust whatever is typed into them.

The checks

1. Secrets live on the server or in environment variables, never in front-end code and never in git history.
2. Every table has access rules: who can read this row, and who can change it? (In Supabase, that's row-level security, and it should be on for every table.)
3. Never trust an ID, role or price sent from the browser. Work out who the user is from their session on the server.
4. Everything that comes in from a user is checked on the server, and nothing user-supplied is put straight into HTML, a URL or SQL.

What to use

alter table notes enable row level security;

create policy "Read own notes" on notes
  for select using ((select auth.uid()) = user_id);

create policy "Change own notes" on notes
  for update using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

// 05 · Level 5 of 6 · Protecting what you build

AI inside your product

What can go wrong

When you put a model inside your product, anything it reads can try to give it instructions. That's prompt injection, and it can come straight from a user or hidden in content the model reads, like an email, a web page or an uploaded file. For example, a support assistant that reads incoming emails could get one with a hidden line asking it to forward the last ten invoices to an outside address. It's number one on the OWASP Top 10 for LLM Applications, which is the list most teams use as the standard. The 2026 edition came out in August, and the top three are prompt injection, sensitive information disclosure, and excessive agency (a model given more power to act than it needs). Excessive agency moved up to third, a clear sign of where things are heading as models are given more tools.

The checks

1. Treat anything the model reads as if it came from a stranger, because it might have. Tool results, fetched pages, uploaded files and rows another user wrote all count.
2. Separate deciding from doing. Don't let one step both read untrusted content and take a privileged action on it. Read it, check the result in code, then act.
3. Never run model output directly as code, a database query or a command, and never show it as trusted HTML.
4. Give each tool the narrowest access its job needs, read-only by default. A tool that summarises tickets doesn't need to close them.
5. Anything hard to undo (deleting, changing permissions, sending messages, payments, bulk exports) needs a human yes.
6. Keep secrets and other people's data out of prompts.

What to use

// 06 · Level 6 of 6 · Protecting what you build

The pipeline that catches what you miss

What can go wrong

Everything above relies on someone remembering. The pipeline is there for the day they don't. Without it, a key gets committed, a vulnerable package gets merged, or a change nobody really reviewed goes straight to production.

The checks

1. Every change gets a review, and an AI reviewer is a second pair of eyes, not the only pair.
2. CI runs a dependency check (npm audit or composer audit), secret scanning and the tests.
3. The deeper security review happens where it matters, before a release and on sensitive changes.
4. A named person signs off before anything is deployed.

What to use

All levels

Staying current

The checks

1. Do you know what versions you're running (Node, PHP, frameworks), and are they still supported?
2. Where will you hear about a new advisory? The official security release pages and GitHub security advisories, with dependency alerts on the repo.
3. How fast do you patch? Critical flaws in something internet-facing should be days, not "next sprint".
4. Before installing anything new, especially something an AI suggested, the package checks from level 3.

What to use

Tech blogs, X, colleagues and partners often surface an issue first. Dependabot covers the dependencies in your repos.