Which integrations are available for this server?

Provides AMUVectorStore and AMURetriever for LangChain, enabling lineage-aware memory retrieval with Postgres RLS gating in LangChain applications. Provides tools for managing lineage-aware memory units in a PostgreSQL database with pgvector, including search, record, and conflict checking, with column-level access control enforced by Postgres RLS. Allows installing and operating the AMU schema on Supabase Postgres, with the same RLS-gated memory tools and lineage-aware governance.

amu-pgvector

by sangaraju1988

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

amu-pgvector

DOI

Reference implementation of Lineage-Aware Memory Governance (Sangaraju & Vissa, IEEE Access, 10.1109/ACCESS.2026.3730363) on PostgreSQL + pgvector.

The problem

Say Finance computes avg(income) for a customer segment and caches the result so the next agent that asks the same question doesn't have to recompute it. Later, a Marketing agent asks a semantically similar question -- "what's the average customer income by segment?" -- and a naive shared memory, gated only on the metric's name or content tags, serves back Finance's cached result. Marketing was never permitted to see income. The result itself doesn't look like income -- it's a number -- but it was derived from a column Marketing isn't permitted to touch, and nothing about matching on metric name or content catches that. That's the leak this project closes: gating reuse on how a result was derived, not on what it looks like.

Related MCP server: memgate

60-second quickstart

git clone https://github.com/sangaraju1988/amu-pgvector.git
cd amu-pgvector
docker compose up -d
psql -h localhost -p 5433 -U amu_owner -d amu_dev -f sql/amu_pgvector.sql
# password: amu_owner_password

uv sync --all-packages --all-extras   # or: pip install amu-pgvector

from amu_pgvector import AMUStore
from amu_pgvector.embeddings import fake_embedder

DSN = "postgresql://amu_owner:amu_owner_password@localhost:5433/amu_dev"
embed = fake_embedder(dim=1536)  # swap for a real embedding model in production

admin = AMUStore(DSN)
admin.register_sensitive_column("income")
admin.grant_department_permission("Finance", "income")
admin.create_agent_role("finance_agent", "Finance", "finance_pw")
admin.create_agent_role("marketing_agent", "Marketing", "marketing_pw")

admin.record(
    "SELECT avg(income) FROM customers",
    {"avg": 82000},
    metric_name="avg_income",
    description="average customer income",
    owner_department="Finance",
    embed_fn=embed,
)

finance_dsn = "postgresql://finance_agent:finance_pw@localhost:5433/amu_dev"
marketing_dsn = "postgresql://marketing_agent:marketing_pw@localhost:5433/amu_dev"

AMUStore(finance_dsn).search("average customer income", k=5, embed_fn=embed)
# -> [SearchResult(metric_name='avg_income', ...)]

AMUStore(marketing_dsn).search("average customer income", k=5, embed_fn=embed)
# -> [] -- Marketing was never granted `income`, so Postgres itself
#          never returns the row, regardless of how the query is asked.

Every line above was run against this exact repo before being written here (see docs/design.md for what a from-scratch install actually looks like). amu_owner/amu_owner_password is the docker-compose default -- change it for anything beyond local development.

How the gate works

amu.memory_units is a normal Postgres table with FORCE ROW LEVEL SECURITY enabled. Every write goes through a trigger that extracts the lineage of the SQL that actually produced the cached result (via amu-governance's sql_lineage module -- not self-reported by the agent), closes it over any registered materialized-view/derived-table edges, and computes S(a): the set of sensitive columns that lineage actually touches. A SELECT policy enforces S(a) ⊆ P(d) -- the row is visible only if every column in S(a) is in the requesting role's permitted set P(d) -- for every query against the table, from every client: raw SQL, amu.search(), the Python client, the LangChain integration, and the MCP server all go through the same policy, because it's the table's policy, not any one client's filter.

sequenceDiagram
    participant Writer as amu_writer role<br/>(trusted interception layer)
    participant PG as Postgres: amu.memory_units<br/>(FORCE ROW LEVEL SECURITY)
    participant Trigger as BEFORE INSERT trigger
    participant Finance as finance_agent role
    participant Marketing as marketing_agent role

    Writer->>PG: INSERT ... lineage = {"steps":[{"table":"customers","columns_used":["income"]}]}
    PG->>Trigger: compute lineage_columns, S(a), lineage_status
    Trigger-->>PG: sensitive_columns = {income}, resolved

    Finance->>PG: SELECT ... (session_user = finance_agent)
    PG->>PG: S(a)={income} subset P(Finance)={income,...}? yes
    PG-->>Finance: row returned

    Marketing->>PG: SELECT ... (session_user = marketing_agent)
    PG->>PG: S(a)={income} subset P(Marketing)={...}? no
    PG-->>Marketing: row not returned

See docs/design.md for how every paper concept maps to a specific SQL object, and docs/sql-reference.md for an exhaustive reference of every table, function, role and policy.

Security model and limits

Protected: cross-department leakage of a cached result's derivation columns (the core guarantee, enforced by RLS); silent metric-definition conflicts (amu.check_conflict()); a column reclassified as sensitive after AMUs already exist (a trigger recomputes affected rows, no rewrite needed); lineage closure that silently truncates a long or cyclic derivation chain (fails closed -- marks the AMU unresolved and invisible, rather than serving a partially-traced result).

Explicitly out of scope: a writer that lies about lineage (the SQL gate trusts amu_writer's input by design); inference by combining several individually-permitted AMUs; Postgres superusers, who always bypass RLS; timing side channels; a "convenience mode" identity option (off by default) that's only as safe as the boundary between trusted application code and agent-influenced code on a pooled connection.

Full writeup: docs/threat-model.md.

Benchmarks

Every number below is quoted directly from results/SUMMARY.md, generated by benchmarks/generate_summary.py from committed results/<name>/<timestamp>/ runs (git SHA, Postgres/pgvector versions, hardware, seed and parameters in each run's manifest.json). Re-run the benchmark scripts yourself to reproduce or challenge these; nothing here is estimated.

Leak rate (2000 requests over 600 synthetic AMUs, Finance/Marketing/Support):

Condition	Served	Cross-department leaks	Leak rate
Naive (content-gated, no lineage check)	2000	1010	50.5%
amu-pgvector (RLS-gated)	990	0	0.0%

Latency (p50/p95 at k=10; RLS and hnsw.iterative_scan each on/off, same role/queries/data per row):

n	RLS	iterative_scan	p50 (ms)	p95 (ms)
10,000	on	on (`amu.search()` default)	66.8	70.2
10,000	on	off	81.9	88.2
10,000	off	on	19.5	21.8
10,000	off	off	49.2	52.3
100,000	on	on (`amu.search()` default)	712.9	851.2
100,000	on	off	43.4	65.7
100,000	off	on	376.8	418.5
100,000	off	off	46.6	70.9

Read honestly: hnsw.iterative_scan=relaxed_order (what amu.search() uses by default, so that filtered results still hit k even when most rows are hidden) costs real latency at scale -- roughly 16x slower than iterative-off at 100k rows in this run. That's the price of the recall guarantee below; if your visible fraction is consistently high, you may prefer to query without it. 1M-row scale was not attempted: the 100k HNSW index build alone took about 7 minutes on the machine this was run on (Docker Desktop on macOS, sharing the host with unrelated workloads) -- recorded honestly rather than extrapolated.

Filtered recall (recall@10 of gated HNSW search vs. exact brute-force over the same role's actually-visible rows, n=20,000):

Visible fraction	recall@10 (mean)	recall@10 (min)
50%	100.0%	100.0%
10%	100.0%	100.0%
1%	100.0%	100.0%

Integrations

Plain SQL -- sql/amu_pgvector.sql is the artifact that matters most: idempotent, installs on a managed Postgres as a normal database owner (no superuser), no C extensions beyond vector. Works identically on Supabase and Neon (see submissions/supabase-neon-guide.md for a from-scratch tutorial covering both).
LangChain -- langchain-amu provides AMUVectorStore and AMURetriever. Every read runs under the store's own Postgres role, so RLS gates LangChain the same way it gates raw SQL. See packages/langchain-amu/.
MCP -- pip install amu-pgvector[mcp] adds an amu-pgvector-mcp console script exposing amu_search, amu_record and amu_check_conflict as tools, gated the same way. See packages/amu-pgvector/src/amu_pgvector/mcp_server.py.

Citation

@article{sangaraju2026lineage,
  title   = {Lineage-Aware Memory Governance: A Derivation-Gated Framework
             for Privacy-Preserving Column-Level Access Control in
             Enterprise AI Agents},
  author  = {Sangaraju, Venkata and Vissa, Sudhir},
  journal = {IEEE Access},
  year    = {2026},
  doi     = {10.1109/ACCESS.2026.3730363}
}

See CITATION.cff to also cite this software directly.

License

MIT. See LICENSE.

Paper: Sangaraju & Vissa, IEEE Access, DOI 10.1109/ACCESS.2026.3730363
Reference library: amu-governance (PyPI)
docs/design.md -- paper concepts mapped to SQL objects, plus every real gotcha found while building this
docs/threat-model.md -- what's protected, what's not
docs/sql-reference.md -- every table, function, role and policy

Available Tools

3 tools

amu_check_conflictA

Check whether another department has already recorded a conflicting definition of the same metric_name (same name, different derivation / definition_hash). Returns only department names and hashes -- never values or lineage -- so this cannot become a side channel around the gate.

ParametersJSON Schema

Name	Required	Description	Default
`metric_name`	Yes
`definition_hash`	Yes
`owner_department`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: the return is deliberately limited to department names and hashes, never values or lineage, and the reason is an access-control ('gate') rationale. It still omits permission requirements, rate limits, and what a positive vs negative conflict result implies operationally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the operation and its conflict criterion, followed by the return-scope limitation. Dense but every clause carries information; the term 'gate' is used without prior definition, which costs a little clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description does not need to enumerate return fields, and it still usefully bounds what is returned. For a read-only conflict check the remaining gap is authorization/error behavior, which is minor relative to the schema and the side-channel disclosure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three required parameters, so the description must compensate. It clarifies metric_name and the role of definition_hash (derivation identity) in the conflict test, but says nothing about the format of the hash or what owner_department means or controls.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: check whether another department has recorded a conflicting definition of the same metric_name, with the conflict condition defined parenthetically (same name, different derivation/hash). It is clearly distinguishable from amu_record and amu_search in function, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the phrase 'cannot become a side channel around the gate' implies this is a pre-write/pre-record check against a gating workflow, but the description never says when to call it versus amu_record or amu_search, nor does it state preconditions or ordering.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amu_recordA

Record a new Analytical Memory Unit (AMU). Lineage is extracted from the executed sql (ground truth), never self-reported. Requires an amu_writer-member Postgres role -- other roles get a Postgres permission error, not a silent no-op.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes
`value`	Yes
`description`	Yes
`metric_name`	Yes
`owner_department`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does well: it discloses that lineage comes from the executed SQL rather than user input, and that write access requires an amu_writer Postgres role with other roles receiving a hard permission error instead of a silent no-op. It stops short of describing conflict/idempotency behavior, which matters given the amu_check_conflict sibling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the action, then the lineage rule, then the permission requirement. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and auth/lineage behavior is covered. However, for a 5-required-param tool with 0% schema coverage and no annotations, the description leaves most parameters and conflict-handling behavior unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 5 required parameters. The description adds real meaning for `sql` (must be the executed query, lineage is derived from it, not self-reported), but says nothing about `value`, `metric_name`, `description`, or `owner_department`, leaving four required params undocumented in both schema and prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Record) and resource (a new Analytical Memory Unit), and even expands the AMU acronym. It does not explicitly contrast itself with amu_check_conflict or amu_search, but the record-vs-search/conflict distinction is inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use / when-not guidance against the siblings. The statement that lineage is extracted from the executed `sql` implies the tool should be called with the query that was actually run, which is useful implied usage but not a stated condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amu_searchB

Search lineage-gated Analytical Memory Units (AMUs) by semantic similarity to a natural-language query. Results are lineage-gated by Postgres row-level security under this server's own Postgres role: an Analytical Memory Unit (AMU) is only ever returned if every sensitive column touched by its derivation is in this role's permitted set. This tool cannot bypass that gate.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No
`query`	Yes
`metric_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and does well on the security-relevant behavior: it explains that results are lineage-gated by Postgres row-level security under the server's role, that AMUs are only returned if every sensitive column is permitted, and that this tool cannot bypass the gate. It doesn't cover rate limits, empty-result behavior, or ordering/relevance thresholds, so it falls short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and constraint, then supplies the security caveat. It is dense but every sentence adds information; minor redundancy in explaining the gate twice ('lineage-gated' and the full RLS explanation) slightly inflates the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format needn't be explained. However, with 0% schema description coverage and no parameter documentation, plus no usage guidance against siblings, the definition is incomplete for a tool that takes an undocumented k and an optional metric_name filter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and all three parameters are undocumented in both schema and description. Neither 'k' (result count?), 'metric_name' (filter?), nor 'query' (natural-language text) is explained, leaving the agent to guess the meaning and constraints of each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Search), resource (AMUs), and mechanism (semantic similarity to a natural-language query). It is clearly distinguished from siblings amu_record (write) and amu_check_conflict, though it doesn't explicitly reference them. The lineage-gating detail focuses on return eligibility rather than the search action itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like amu_check_conflict, and no prerequisites or exclusions are stated. An agent must infer from the name that this is the read/retrieval counterpart, which is left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Oct 18, 2026
- First observedamu_check_conflict
- First observedamu_record
- First observedamu_search

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-10-18 03:30 across 3 tools

Disambiguation4/5

The three tools map to distinct operations: a pre-write conflict check, a write, and a semantic read. amu_check_conflict and amu_search both read from the AMU store, which could momentarily overlap, but their descriptions (exact metric_name/hash match vs. natural-language similarity query) clearly separate them.

Naming Consistency4/5

All tools share a consistent amu_ prefix and use lowercase snake_case, so the set reads as a coherent family. Minor deviation: amu_check_conflict follows verb_noun while amu_record and amu_search are bare verbs, but this is still readable and predictable.

Tool Count4/5

With only 3 tools the surface is on the lean side, but each tool is well-scoped to a distinct step of the AMU lifecycle (record, retrieve, conflict-check), so nothing feels redundant or padded. It is slightly under-provisioned rather than excessive.

Completeness3/5

The core write/search/conflict-check loop is covered, but there is no way to fetch or list an AMU by identifier or metric_name outside of a semantic query, and no update/delete path (which may be intentional for immutable, lineage-gated memory). These are notable gaps an agent would hit when trying to enumerate or revisit known AMUs.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

nlqdb — analytical memory for AI agents AOAuth
com.nlqdb
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Databases Knowledge & Memory Search
32
polymnemo AOAuth
io.github.PCBZ
Shared cross-LLM long-term memory over MCP: semantic recall, sessions, and media (pgvector).
Knowledge & Memory Vector Databases RAG Systems
1
OneDroid Engram
ai.onedroid
Versioned agent memory in your own Postgres: portable context, permissioned, audit trail.
Knowledge & Memory Databases Security
1
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2

Related MCP Servers

Hindsight-MemPalace
Knowledge & Memory Vector Databases
holetron
A
license
Not graded
quality
C
maintenance
Self-hosted long-term memory for AI agents: MCP server with hierarchical recall over pgvector.
Updated 3 months ago (2026-07-18 00:02 UTC)
21 npm
14
MIT
memgate
Knowledge & Memory Security
Denizayhan04
A
license
Not graded
quality
C
maintenance
Access control, conflict resolution, and audit for shared agent memory. Policy-gated memory tools over Postgres + pgvector, exposed via MCP.
Updated 3 months ago (2026-07-25 15:56 UTC)
1
Apache 2.0
mcp-postgres-guard
Databases Security
vladshykanov
A
license
A
quality
D
maintenance
An MCP server that enables AI agents to securely interact with PostgreSQL databases with least-privilege scopes, PII masking, and human approval for writes.
Updated 3 months ago (2026-07-28 12:04 UTC)
4
MIT
nlqdbofficial
Databases Knowledge & Memory
nlqdb
A
license
A
quality
A
maintenance
Analytical memory for AI agents: a real Postgres your agent connects to over MCP and queries in plain English — GROUP BY, JOIN, aggregate over what it remembered, not just top-k vector recall.
Updated 2 days ago (2026-10-19 13:08 UTC)
7
2
Functional Source , Version 1.1, ALv2 Future

amu-pgvector

The problem

60-second quickstart

How the gate works

Security model and limits

Benchmarks

Integrations

Citation

License

Related

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Hindsight-MemPalace

memgate

mcp-postgres-guard

nlqdbofficial