How should AI agents access production data safely?

Start with the smallest useful capability

An agent is an untrusted decision component from the perspective of authorization. It may misunderstand a request, produce a plausible but wrong plan, follow a malicious instruction in retrieved text, retry after an ambiguous error, or make an action appear more urgent than it is. None of these problems require the agent to be malicious. A safe design therefore makes authorization independent of the model's output.

Begin with this default: the agent never receives a production database connection string, database administrator account, broad service token, cloud root credential, or a tool that executes arbitrary SQL. Instead, the agent calls an internal data service with a task-specific operation such as get_order_status, list_overdue_invoices, or propose_dispute_opening. The service authenticates the workload, checks the requesting user's authority and tenant, enforces constraints, performs the database work, returns a minimum necessary result, and produces an audit event.

This approach follows the resource-focused view of zero trust. NIST describes zero trust as moving from static network perimeters to protecting users, assets, and resources, with authentication and authorization performed before access to an enterprise resource is established. NIST SP 800-207 Being inside a production network, or being invoked by a legitimate employee, is not a reason to grant an agent broad data access.

Provide a straightforward approved API for each common task. A small service contract is easier to authorize, test, observe, revoke, and evolve than a natural-language request translated directly into database operations.

Separate read access from write actions

Read access can disclose information. Write access can change money, permissions, records, availability, or legal obligations. Combine them only when a specific workflow demands it, and still make their permissions and audit records distinct.

Read plane

The read plane should be read-only by construction. Prefer a dedicated read replica, governed semantic layer, materialized view, or internal read API over the primary database. Give the agent a separate read-only workload identity. Limit it to approved operations, tables or views, columns, tenants, rows, time windows, result counts, query execution time, and aggregate thresholds.

Return facts rather than full records where possible. A support agent answering “Has this customer paid the invoice?” may need payment status, due date, and account eligibility. It likely does not need a full payment history, payment instrument, personal address, internal fraud notes, or unrelated customer records. Mask or tokenize sensitive columns before they leave the service, and make any unmasking a distinct policy decision.

Read access also needs defenses against indirect prompt injection. A customer comment, ticket attachment, database field, or retrieved document can include content intended to make the model ask for more data. The data service must ignore such language when authorizing access. OWASP recommends least privilege for agent tools, isolation of memory and context between users and sessions, structured outputs, and avoiding model output as the authority for authorization. OWASP AI Agent Security Cheat Sheet

Write plane

The write plane should accept a finite set of business commands rather than SQL strings, ad hoc filters, or arbitrary API paths selected by a model. A typed command has an operation name, schema-validated parameters, target tenant, actor, policy context, idempotency key, expected object version, and requested reason. The write service validates all of those values again, then decides whether to reject, stage, request approval, or execute.

The service, not the agent, determines which database statement or downstream API call implements the command. This prevents a model from widening a WHERE clause, modifying an unrelated table, choosing a destructive operation, or using an identifier it inferred from untrusted content. Prompt instructions can help the agent propose a safer command, but they cannot replace validation and authorization. OWASP's prompt-injection guidance likewise treats least-privilege tool scopes, structured validation, and human approval as defense-in-depth controls rather than relying on model behavior alone. OWASP Prompt Injection Prevention

The definitions of “material” and “high-risk” must reflect the business. A $5 internal test adjustment is different from an employment-record change, a payment reversal, a medical record update, a privilege assignment, or an action that sends customer communications. In regulated, financial, health, employment, legal, public-sector, or child-safety settings, obtain the appropriate legal, privacy, security, and domain review before enabling an automated or agent-assisted write path.

Enforce access at more than one layer

Application checks alone are easy to omit during a new endpoint, bug fix, or retry path. Use defense in depth: identity and authorization at the gateway, service-level purpose and command checks, database roles and views, row and column restrictions, network egress limits, and auditing.

Workload identity and tenant context

Assign every agent service its own non-human identity. Bind each request to a user or initiating system, tenant, environment, use case, task ID, and purpose. The agent must not select these values freely. A trusted gateway derives them from authenticated context, verifies them against policy, and signs or securely propagates them to the data service.

Use separate identities for development, staging, and production. A development agent should have no route to production. Production read and production write services should use different identities and secrets. Rotate credentials and revoke them through a central control plane. NIST SP 800-53 includes access control, audit and accountability, identification and authentication, incident response, configuration management, and other control families relevant to this separation. NIST SP 800-53 Rev. 5

Row and column enforcement

Enforce tenant and row scope in the database or a trusted data layer, not only in the agent prompt or generated query. Row-level security, where supported, can restrict rows returned or modified according to the current role and policy. PostgreSQL, for example, supports policies that govern SELECT, INSERT, UPDATE, and DELETE; when row security is enabled with no applicable policy, normal access is default-deny. PostgreSQL Row Security Policies

Database details matter. PostgreSQL documentation also notes that superusers, roles with BYPASSRLS, and usually table owners can bypass row security. Do not run the agent data service under such a role, and test the actual production connection configuration. Use views or stored procedures to expose only approved columns, apply masking before the model receives results, and keep unmasked data in a separately authorized path.

Query and result limits

An agent should not be able to turn a read permission into bulk extraction. For every read operation, set a maximum row count, page count, result byte size, time range, execution timeout, query-cost or scan limit where available, and request rate. Require parameterized templates or structured filter objects rather than free-form SQL. Reject queries that attempt broad enumeration, cross-tenant joins, sensitive columns, unsupported operators, or a missing tenant predicate.

These limits are safety controls, not merely performance tuning. They reduce accidental over-collection, prompt-injection blast radius, and the chance that a model retries an expensive query until it harms the system. Monitor denied queries and near-limit requests because they reveal both poor tool design and possible misuse.

A safe reference flow

Use the following sequence for a production request. It works with a relational database, a document store, a warehouse, or an operational API because the critical steps occur before and around data access.

1. An authenticated user or scheduled system submits a task to the agent application. The application creates a task ID and records the user, tenant, purpose, and requested outcome.

2. The agent may plan with non-sensitive task context, but it receives no production credentials. It selects from a finite tool catalog such as get_case_summary or propose_invoice_dispute.

3. The agent gateway validates the tool name and structured parameters against the task's allowed scope. It rejects a missing tenant, unsupported operation, excessive limit, or unapproved purpose before contacting a data service.

4. A mediated read service authenticates the workload identity, applies service policy, sets the trusted tenant context, queries a read replica or protected view, enforces row and column rules, masks fields, applies query limits, and returns the minimum result. It logs the decision and metadata, not an unnecessary raw result copy.

5. The agent produces an explanation or a proposed structured write command. It cannot execute a write as a side effect of reading. The user or workflow can inspect the proposed target, before and after values, reason, policy warnings, and source evidence.

6. A write workflow validates the typed command independently. It checks current authorization, input schema, business invariants, object version, amount or impact limits, idempotency key, and whether approval is required. It performs a dry run or stages the change when possible.

7. For an approved action, an authenticated reviewer with the right scope approves the exact command. The workflow rechecks authorization and object version after approval, then executes a narrow transactional operation. It records the outcome, new version, and any compensating action.

8. Monitoring watches for unusual data volume, tool use, approval bypass attempts, failed validations, retry loops, and write errors. An incident control can disable the tool at the gateway, revoke the workload identity, quarantine queued writes, and route operators to a manual process.

This flow keeps natural-language reasoning on the outside of the authorization boundary. The agent remains useful for finding context, drafting explanations, and proposing a valid command. Deterministic systems retain control of identity, scope, data access, business invariants, and execution.

Make writes safe to retry, review, and recover

Agent systems may retry after a timeout even when the original request succeeded. They may repeat an action after observing an incomplete response. The write path must therefore make duplicate execution safe or detectable.

Use an idempotency key supplied by the trusted workflow, scoped to the tenant, command type, and intended target. Store the resulting status so an identical retry returns the original result rather than applying the action again. Pair it with optimistic concurrency or an expected version check. If the record changed after the agent built its proposal, reject or re-present the current state instead of applying an action to a different situation.

For a reversible change, write an append-only event or an audit record with before and after state, actor, approver, policy version, task ID, and correlation ID. A rollback should be a new, authorized compensating action, not an untracked database undo. Some effects cannot be reversed safely, including an external email, a payment transfer, a disclosure of private information, a credential rotation, or a destructive purge. For those operations, prevention, approval, staging, and recovery planning are more realistic than promising rollback.

Staging and dry runs are useful if they are faithful. Use production-like schemas, access rules, data shapes, and integration behavior, but avoid copying unnecessary real personal data into lower-protection environments. A dry run should calculate the exact targeted records, expected changes, policy result, and potential side effects. A reviewer must be able to compare that preview with the final action, and the workflow must revalidate critical preconditions before commit.

Audit for reconstruction without building a second data leak

An audit log must answer who initiated a task, which agent version and tool were used, what policy allowed or denied the request, which data scope was accessed, what command was proposed, who approved it, and what outcome occurred. It should not automatically store every prompt, result row, secret, or sensitive field.

At minimum, log task ID, request ID, actor and workload identity, tenant, use case, tool name, policy and model version, authorization decision, data classification, row or object count, query template ID, limit outcome, write command type, payload hash or protected reference, approval record, object version, action outcome, and correlation ID. Keep protected evidence only when there is a defined investigation or regulatory need, with access control and retention rules that match its sensitivity.

Audit integrity matters. Send events to an append-only or tamper-evident system where practical, separate operational logs from the application runtime, and restrict who can read sensitive evidence. Test whether a sampled production action can be reconstructed end to end. If it cannot, the organization will have difficulty determining whether a surprising write came from the agent, an operator, a retry, or a compromised credential.

Prepare for incidents before enabling writes

Create an agent-specific incident runbook and exercise it. It should cover unauthorized data retrieval, cross-tenant exposure, accidental bulk read, unsafe or duplicate write, prompt injection leading to unexpected tool use, compromised agent identity, provider outage, policy-service failure, and corrupted or missing audit evidence.

The immediate containment sequence should be simple and tested: disable the affected tool at the gateway, revoke or suspend the workload identity, freeze or quarantine queued actions, preserve necessary audit evidence, assess affected records and users, and move the task to a manual fallback. Do not make the kill switch depend on asking the agent to stop. It should be an operator-controlled capability outside the agent's tool set.

OWASP recommends monitoring approval behavior, elevated privilege use, tool invocation frequency, high-risk actions, and changes to prompts, tools, memory, retrieval, policies, and model providers. It also recommends structured security testing before production deployment and after material changes. OWASP AI Agent Security Cheat Sheet Adapt those checks to production data: test tenant isolation, denied sensitive-field access, query limits, injected instructions in stored data, duplicate requests, expired approvals, concurrency conflicts, rollback or compensating action, and kill-switch recovery.

A concrete example

Example

Hypothetical setup: a support agent helps staff answer invoice disputes. A support representative asks why invoice INV-1042 is marked overdue and asks the agent to open a dispute if the account record supports it. The agent has no database credential. Its only allowed tools are get_invoice_dispute_context and propose_open_dispute.

The read service derives the tenant and staff role from the authenticated request, then returns a masked, tenant-scoped summary: invoice status, due date, disputed status, relevant payment-event IDs, and the policy conditions for opening a dispute. It excludes payment instrument details, unrelated invoices, internal fraud notes, and other tenants. A stored customer comment attempting to tell the agent to export all invoices cannot widen the tool's server-side row or column policy.

The agent produces a structured proposal containing invoice ID, reason category, and evidence IDs. The write workflow checks that the invoice still belongs to the tenant, is not already disputed, has the expected version, and meets the business rules. Because opening a dispute changes collections behavior, a support lead sees the exact proposed change and approves it. The workflow then writes one transactional state change using an idempotency key. If the response is lost and the agent retries, the service returns the recorded outcome instead of opening a second dispute. The audit trail links the task, agent tool call, masked read scope, validation, approval, object version, and result.

If the invoice changed while the lead reviewed it, the expected-version check fails. The system refreshes the preview rather than applying a stale proposal. If a later correction is warranted, it uses a separate authorized command with its own reason and audit link. Staff can use the agent to prepare the work while the service limits its access to the specific operation.

Roll out in stages and test the controls

Start with a small, well-understood read-only workflow. Use a curated view or replica, sample data-minimization outcomes, and prove that tenant isolation and audit reconstruction work. Add only the operations that have clear business value and a finite command schema. Do not treat a successful demo as evidence that a write-capable agent is ready for production.

Track rejected and permitted tool calls by operation and reason, masked-field requests, query-limit hits, anomalous row counts, model or prompt changes, approval bypass attempts, retry rate, idempotency replays, version conflicts, write error rate, compensation rate, time to revoke access, and kill-switch exercise time. Review a sample of successful reads and writes, not only failures. A healthy control plane will sometimes reject requests that an agent regards as reasonable.

Common failure modes and viable alternatives

For some use cases, the right alternative is no agent access to production at all. A nightly sanitized export, a governed analytics warehouse, an approved dashboard, a human-operated runbook, or a local test environment may meet the need with less risk. Choose the least privileged architecture that still produces a useful answer or workflow.