Security Model

pgContext SQL APIs are designed to work with ordinary PostgreSQL security controls. Catalog-changing functions run with pgContext catalog privileges, set a safe function search_path, and still check the SQL session user for collection ownership and source-table privileges before exposing or mutating user data.

Source tables remain application-owned PostgreSQL tables. Table ACLs and row level security policies continue to apply to search, count, facet, point, and registration paths that read or expose source data.

Filters are parsed into typed structures before SQL rendering. Registered columns and JSONB paths are resolved through catalog metadata; predicate values are bound as SPI parameters instead of being interpolated into SQL text.

Security-definer paths are tested with attacker-controlled schemas earlier in the caller search_path to ensure pgContext resolves its own catalog objects and PostgreSQL built-ins deliberately.

Telemetry surfaces are local SQL-visible counters and typed statuses. Query cohort telemetry does not store vector contents, filter values, or literal query text, and cohort labels are validated as bounded ASCII operator labels rather than free-form user text.

Security-Definer Review Notes

Security-definer functions are limited to extension catalog maintenance and diagnostic aggregation. They set a fixed search_path of pg_catalog, pgcontext, and public; resolve user relations through registered catalog metadata or validated qualified names; and still check the SQL session user before exposing source rows or mutating collection-owned metadata.

Reviewed groups:

  • Collection catalog: create_collection, collection_info, register_vector, and drop_collection.
  • Payload and point catalog: register_filter_column, register_jsonb_path, upsert_points, and delete_points.
  • Source-row readers: search, filtered search, candidate recheck, count, facet, scroll, and query.
  • Operations and telemetry: index_status, estimate_index_memory, optimization_status, vacuum_advice, record_query_stat, and query_cohort_stats.
  • Model metadata: register_model_version, model_versions, create_embedding_migration, update_embedding_migration, and embedding_migrations.
  • Artifact operations: publish_artifact_segment, publish_artifact_segment_file, artifact_segments, artifact_segment_memory, artifact_segment_diagnostics, artifact_segment_serving_readiness, artifact_segment_mmap_payload, cleanup_artifact_segments, and retire_artifact_segment.

Release tests cover hostile search_path shadow objects, default privileges, ACL/RLS source-row boundaries, and telemetry privacy. New security-definer functions must add the same kind of catalog classification, SQLSTATE, and hostile-input coverage before becoming part of the stable surface.

PostgreSQL-Native Operational Boundary

Using PostgreSQL ACLs, RLS, transactions, WAL, backup, and restore is an intentional product difference from systems that copy payloads into a separate service. The operational consequence is that pgContext does not provide a second authorization policy or an independent consistency and backup domain: source-table privileges and transaction visibility remain authoritative.

When migrating, preserve the source tables, roles, grants, RLS policies, and pgContext catalog schema in the same PostgreSQL backup/restore workflow. Verify the application role against representative search and filter queries after restore; do not translate PostgreSQL policy into a pgContext-specific ACL.