How to Let Your AI Assistant Use Your Real Data Safely

Connecting your AI coding tool to real data is the configuration that makes generated code dramatically more accurate. But the question developers stall on is: how much access should the agent actually have?

The answer depends on what you're trying to accomplish, but the principle is consistent: the agent should have the minimum access necessary for the task, enforced at a layer the agent can't circumvent.

The Risk That Matters

The agent itself is not the primary threat model. Claude Code, Cursor, and Codex are local tools — they don't exfiltrate data to external parties, and they don't act autonomously without your approval (unless you've explicitly configured them to). The risks in practice are:

• Admin credentials in the wrong place. If you connect your agent to a database using a service role key or admin token, and that credential appears in a generated file, a shell history, or a .env file that gets committed — it's exposed.
• The agent writing to things it shouldn't. An agent with write access to production data can delete records, overwrite values, or insert test data into a live database. These aren't malicious actions — they're mistakes.
• Over-broad reads. An agent that can read all data in a multi-tenant system can inadvertently include another user's data in a response, a log, or a generated mock.
• Bypassed application logic. An agent with raw database access can write records that skip your validation logic, business rules, and audit trails — producing data that looks valid but isn't.

These are solvable problems with the right architecture.

Layer 1: Use Scoped, Read-Only Credentials for Direct Database Access

If you're connecting your agent to a database via a Postgres MCP server or similar direct connection, create a dedicated credential with the minimum permissions required:

• For schema inspection and query work: a read-only role that can run SELECT and schema introspection queries, nothing else.
• Never use your service role or admin key in an agent connection. These keys bypass all security policies and give the agent unrestricted access.
• Use environment variables, not hardcoded values. The credential should live in .env (added to .gitignore) or a secret manager, not in the MCP configuration file that might get committed.

Example Postgres role setup:

CREATE ROLE ai_agent_readonly;
GRANT CONNECT ON DATABASE your_db TO ai_agent_readonly;
GRANT USAGE ON SCHEMA public TO ai_agent_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_agent_readonly;

With this role, the agent can read any table but can't write, delete, or modify schema. It's safe to use for schema introspection and query development.

Layer 2: Row-Level Security at the Database Layer

Read-only credentials limit what operations the agent can perform. Row-Level Security (RLS) limits which rows it can see within those operations.

In a multi-tenant application — any app where different users have their own data — an agent with read access to the entire orders table can potentially return all orders, not just the ones belonging to the current user. If that data appears in a generated response, a log file, or an error message, you have a data exposure.

RLS solves this by enforcing filters at the database layer, before the query result ever reaches the application. A policy that says "only return rows where user_id = current_user_id()" applies regardless of how the query is constructed — whether by a human developer, an application layer, or an AI agent.

The critical property: RLS enforcement happens at the database, not the application. An agent that writes a query that would return all orders in a tenant-isolated system will only receive the rows the current authenticated context is authorized to see. The agent can't construct a query that bypasses a correctly configured RLS policy.

Layer 3: Use a Backend with Server-Side Logic Instead of Direct Database Access

For production applications, the cleanest architecture is to give the agent access not to the database directly, but to a controlled API surface in front of it.

This is the model Momen uses. Instead of connecting your agent to raw Postgres, you connect it to an auto-generated GraphQL API that:

• Exposes only the operations you've explicitly configured (not every possible table access)
• Enforces Momen's RBAC and database-layer RLS on every request — the agent can't bypass it by writing a clever query
• Routes mutations through server-side Actionflows that include validation logic, business rules, and audit trails
• Issues scoped Admin Bearer Tokens for agent access, not full service keys

The agent can read and write real data through this API surface, but it can only do what the API allows. Adding a record triggers the same Actionflow that a human user would trigger — including all the validation and business logic that flow contains.

Momen's permissions documentation covers how the RBAC and RLS layers work together. The AI Agent overview shows how server-side agents operate within those same permission boundaries.

This architecture matters for a specific reason: it means the agent's actions are logged, validated, and bounded by the same rules as every other actor in your system. There's no "agent exception" that bypasses your security model.

What to Actually Configure

For development / schema work:

• Read-only credential with RLS policies in place
• Direct database MCP is fine — the agent needs to read schema and write queries
• Keep the credential in environment variables, not config files

For production data access:

• Use a backend API (GraphQL, REST, or Actionflows) rather than direct database access
• Issue a scoped token for agent access — not an admin key
• Ensure your API enforces the same RLS policies as your production system
• Audit what Actionflows the agent is allowed to call — not all of them should be agent-accessible

For multi-tenant applications:

• RLS at the database layer is non-negotiable if you're giving the agent any read access to production tables
• Test that the agent's queries correctly respect tenant isolation before connecting to production data
• Consider starting with a staging environment that has representative but non-sensitive data

A Note on Agent Keys

Momen's Admin Bearer Token model is designed specifically for the agent-access scenario. Instead of giving the agent your full admin credentials, you issue a Bearer Token with defined scope: it can call specific Actionflows, read specific tables, and nothing else. When the scope is wrong or needs to change, you rotate the token — not the underlying credentials.

This is the same pattern that good API security uses for any external caller: least-privilege access with a scoped, rotatable credential. The agent is just another external caller.

Summary

The practical setup for safe AI data access has three layers:

• Scoped credentials — read-only when possible, never admin keys, always in environment variables
• Row-Level Security — enforced at the database layer so the agent can't construct queries that over-expose data
• An API surface instead of direct database access — for production systems, give the agent access to a controlled API that enforces your business rules and audit trails

The goal isn't to give the agent no access — restricted access produces hallucinations and low-quality output. The goal is to give it bounded access: enough to do the work correctly, constrained so that mistakes don't become incidents.