PostgreSQL agent-write authority

Use least-privilege SQL grants and row-level security, with an application gate for business intent.

01 / Principal and identity

Who acts, and what can the platform identify?

A database agent acts under a user task while connecting through a database role.

Database role/session is available; trusted application context must be passed separately.

Trace the proposed action
  1. 01Originating task
  2. 02Agent or workload
  3. 03It updates customer account rows.
  4. 04Observed effect

02 / Action-time control

Where can an unauthorized effect be stopped?

Use least-privilege SQL grants and row-level security, with an application gate for business intent.

Bind tenant, table, row selector, changed columns and task.

SubjectVerified caller and task
RequestOperation, target and values
OutcomeDecision, attempt and state

Delegation constraint

A report-generation subtask should not inherit write credentials.

03 / Worked denial

Test a request outside the grant.

An agent asked to correct one address issues an UPDATE without a customer predicate.

Adversarial verification

Attempt a customer UPDATE without a tenant predicate and again with the correct row selector. Inspect application validation, row policy, affected-row count and transaction result.

04 / Review and responsibility

What should the audit trail prove?

Actor/task, SQL digest, affected-row estimate/count, transaction ID, decision and before/after record versions.

Row-level security limits accessible rows but does not by itself prove purpose or correct values.

Platform primary source

Check the current execution model

Architecture discussion

Map one consequential action in your environment.

Request a Conversation