AI agent database write policy

The control gap

Read access for investigation should not silently imply the authority to change customer or financial records.

Database writes need structured context before policy can be dependable. Prefer a named operation and parsed table set over an opaque SQL string. Include the environment, database, schema, tables, estimated row count, tenant boundary, transaction mode, and whether the statement changes or deletes data. Destructive DDL should normally be denied to agents rather than approved ad hoc.

The safest rollout begins with read-only calls and a narrow set of idempotent writes. Test the rule against multi-table statements, views, stored procedures, and queries whose target is selected dynamically. The execution result should record affected row count and transaction outcome without copying sensitive row values into the authorization log.

Separate query planning from execution. The adapter can parse or prepare a statement with a read-only connection, resolve affected objects, and obtain an estimated row count before seeking approval. The execution connection should have only the exact database permissions required and should reject statements outside the normalized plan.

Bind approval to statement digest, parameter types, tenant selector, transaction boundary, and maximum affected rows. A reviewer who sees an update for one account must not authorize the same predicate with a different tenant parameter. Stop execution when the actual row count exceeds the reviewed ceiling and roll back the transaction.

Test triggers, cascading deletes, functions with side effects, temporary tables, search-path changes, and time-of-check/time-of-use drift. Evidence should include database identity, transaction ID, normalized statement fingerprint, affected objects, row count, commit or rollback result, and provider error category without retaining row contents.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "update" rather than every operation exposed by the tool.
• Scope the target to approved production tables and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

AI agent database write policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: database-write
match:
  tool: postgres
  action: [insert, update, delete]
  environment: production
decision: require_approval
approval:
  reviewers: ["data-owners"]
  expires_in: 10m

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted update, including denied requests.
• The exact approved production tables selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?