Databases, OAuth, API Keys: Know This Before Coding with AI

Generative AI can now create a database, write the rules that protect its contents, and connect a tool to an external service in a few exchanges. That is real progress, and a real risk if nobody understands what the AI just did. Here are the four concepts to know before letting it code for your business: the database, RLS, OAuth, and the API key.

What is a database, and why does an SME need one?

A database is a system that stores information in a structured way, as tables, each made up of rows (a record, a customer for example) and columns (a piece of information about that record: their name, their email, their sign-up date). It is the digital equivalent of a filing cabinet, but one you can query and update at speed.

A spreadsheet works fine for a few dozen rows. Beyond that, once a small business manages dozens of active customers, several people reading or editing the same data at once, or a tool (a website, an AI agent) that needs to read and write automatically, a proper database becomes necessary.

The most common databases in small businesses are relational (Postgres, MySQL): tables are linked to each other by identifiers, an order to a customer, a customer to a company. That structure is what lets an assistant able to act on your systems answer "how many customers ordered more than three times this quarter" by querying several tables at once.

How does an AI generate and change a database structure?

When you ask an AI to "create a database for order management", it writes schema definition code, exactly as a developer would: each table, each column, its type, the relationships between them. That code then runs against the database to actually create the structure.

This step is called a migration: a piece of code describing a structural change, which can be replayed identically on another environment. An AI that "adds a phone field to the customers table" is, in effect, writing a migration.

The point to watch: this structure shapes everything built on top of it. A table poorly designed at the start costs far more to fix once it is in production, with real data in it. It is worth reading what the AI proposes before running it, even without understanding every detail: the question to keep asking is "what does this structure prevent, and what does it allow".

What is RLS (Row Level Security), and why is it essential?

RLS, short for Row Level Security, is a rule enforced directly by the database itself, filtering which rows a caller is allowed to see or change based on their identity. It lives inside the database, which makes it much harder to bypass by accident than a rule coded in the application layer above it.

Example: an invoices table holds the invoices of every client of an accounting firm running a shared application. Without RLS, any logged-in user could, in theory, access other clients' invoices by tweaking a query. With RLS, a rule is written once: "a user only sees rows where client_id matches their identity." It applies automatically, no matter what code queries the database afterwards, including code an AI writes later.

PostgreSQL's official documentation on Row Security Policies states it plainly: without an explicit RLS policy on a table, any user allowed to query that table sees all of its rows. The moment a database is shared across several clients or accounts, enabling and testing RLS is not optional, it is a baseline requirement.

What is OAuth, and how is it different from a password?

OAuth is a delegated-authorisation protocol: it lets one service grant limited access to another without the user ever having to share their password with the requesting service. It is the mechanism behind every "Sign in with Google" button and every "Allow this app to access my account" prompt.

The mechanics, described in RFC 6749, which defines OAuth 2.0, always follow the same logic: the user authenticates once with a trusted third party (Google, Microsoft, the service provider), which issues an access token, limited in time and scope, that the application then uses to act on the user's behalf. The original password is never passed to the third-party application, and the token can be revoked at any time.

The most common confusion in small businesses is treating OAuth as a simple password login. It is not: OAuth answers "what is this application allowed to do on my behalf", not just "who are you". An AI agent connected via OAuth to an inbox or a CRM should only ever be granted the permissions it strictly needs, never full access as a shortcut.

How do you create and manage API keys securely?

An API key is a secret, a string of characters that grants access to a service (database, email, an AI model, payments) without an interactive login. It plays a role close to a password, but built for a machine rather than a human in front of a screen.

The single most important rule, restated by the OWASP API Security Project, is that an API key must never appear in plain text in shared code, a prompt sent to an AI, a screenshot, or a publicly versioned file. A leaked key gives direct access to the service it belongs to, often without that being obvious right away.

In practice, an API key is stored in an environment variable (a file kept separate from the code, never shared, often named .env) or a secrets manager. Three habits are enough: never paste a key into a message to an AI, generate a different key per use and per environment so you can revoke one without breaking everything, and rotate a key the moment its confidentiality is in doubt.

How do these concepts apply in practice, depending on the AI tool you use?

The vocabulary is the same everywhere, but each tool has its own habits to build to avoid exposing a key or a data structure by accident.

With Claude (Claude Code, Claude Cowork)

Claude Code reads and writes code, including database migrations, directly in a local project. The habit to build: ask for an explicit review before running anything ("explain what this migration does before you run it"), and check that .gitignore excludes secret files from the very first use. Claude Cowork should never receive an API key as text in a conversation: credentials are configured through dedicated integrations, not typed into the chat. For more on the tool's own vocabulary, see artifacts, skills, hooks: the Claude Code glossary.

With ChatGPT / Codex

Codex, like Claude Code, can generate migrations and edit configuration files in a repository. Same vigilance: never type an API key into a regular ChatGPT prompt (it stays in the history), and for Codex, check that the execution environment (sandbox or a real repository) does not default to exposing production credentials.

With Antigravity

Antigravity, Google's agentic IDE, works with a direct connection to a local or remote repository. Safety starts upstream: a .gitignore configured before the agent's first generated commit, environment variables kept separate from the code, and a human review of any auto-generated RLS policy before it goes anywhere near production.

Where next?

These four concepts, database, RLS, OAuth, API key, form the minimum base you need to work with an AI that codes without getting caught out by its own speed. Two related topics go further: GitHub and .gitignore, never exposing an API key to generative AI, and generative AI security: best practices and audits to put in place at an SME.