# How to Share AI Agent Memory Across a Team Without Exposing Private Data > Source: > Published: 2026-06-05 00:00:00+00:00 # How to Share AI Agent Memory Across a Team Without Exposing Private Data Learn how to design shared vs private memory for team AI agents using Notion permissions, GitHub repos, and row-level security in a shared PostgreSQL database. ## The Real Problem With Team AI Agents and Memory When a team deploys shared AI agents, memory becomes a minefield. One agent learns a sales rep’s private commission details. Another picks up a confidential client negotiation. A third stores a manager’s performance review notes. Now every teammate using that agent can surface data they were never supposed to see. This is the core challenge of sharing AI agent memory across a team: you want collective knowledge to make agents smarter, but you can’t let shared memory become a data leak. Getting this right requires thinking carefully about what memory is, where it lives, who can access it, and how access rules are enforced — not just assumed. This guide breaks down how to architect shared versus private memory for multi-agent workflows, using practical patterns with Notion permissions, GitHub repositories, and row-level security in PostgreSQL. Whether you’re building enterprise AI systems or scaling a small team’s agent stack, these patterns apply. ## What AI Agent Memory Actually Is Before designing access controls, it helps to be precise about what “memory” means in an agent context. AI agent memory isn’t one thing. It typically falls into a few distinct categories: **In-context memory**— information passed directly in the prompt or conversation window during a single session. It disappears when the session ends.**External memory**— information stored outside the model in a database, file, or knowledge base and retrieved when relevant. This persists across sessions.**Semantic/vector memory**— embeddings stored in a vector database that allow agents to retrieve conceptually similar information, not just exact matches.**Structured memory**— records in a traditional database (relational or document-based) that agents can query and update with precision.** Episodic memory**— logs of past interactions, decisions, and outcomes that an agent can reference to improve future behavior. For team deployments, external, semantic, and structured memory are where access control matters most. These are the persistent layers that accumulate sensitive information over time. ### Why Default Setups Fail Teams Most out-of-the-box agent memory implementations assume a single user. A vector store holds everything. Any agent query against that store returns results without any notion of who created the data or who should see it. Scale that to a team of 20, and you have a shared brain with no access controls — the equivalent of a shared Google Drive folder where everyone can read everything. ## Mapping Memory to Access Levels The first step in designing safe shared memory is separating what should be shared from what shouldn’t. Most team contexts have at least three tiers: **Organization-wide memory** — knowledge that’s safe and useful for everyone. Company policies, product documentation, FAQs, onboarding materials, shared process guides. Any team member should benefit from agents that know this. **Team or role-based memory** — information relevant to a specific function. Sales pipeline data is useful for the sales team but irrelevant (and potentially sensitive) to engineering. Legal summaries belong to the legal team. Segment this by function, department, or role. **Individual private memory** — notes, drafts, personal context that a single user adds to improve their own agent experience. Performance feedback they’ve received, client relationship notes they’d rather keep private, personal shortcuts and preferences. Getting this taxonomy right before you build anything saves significant retrofitting pain later. Draw it out. Map each type of data your agents will store or retrieve to one of these three tiers. Only then should you start wiring up permissions. ## Using Notion as a Shared Memory Layer Notion works well as an external memory store for team agents because it has a real permissions model built in. Pages can be restricted to specific workspaces, teams, or individuals. That permission model can be inherited by agents that access Notion via the API. ### Setting Up Tiered Notion Permissions Create a deliberate page hierarchy that mirrors your access tiers: **Workspace-level pages**— visible to everyone in the Notion workspace. Use these for org-wide knowledge: product specs, company policies, general process guides.**Teamspace pages**— restricted to specific groups. Set these up in Notion’s Teamspaces feature, where only members of a given team can view or edit content.**Private pages**— personal pages that only the creating user can access. These live in each user’s private sidebar section. When your agent queries Notion, it does so via a Notion integration token. Here’s the key design principle: **each access tier gets its own integration token with scoped permissions**. A shared org-knowledge agent uses a token that can only read public workspace pages. A sales team agent uses a token granted access to the sales teamspace. Individual users authenticate their personal agent with a token scoped to their private pages. ### Practical Agent Query Pattern When an agent receives a query, it determines which memory tier is relevant before fetching. This logic can be explicit in the agent’s system prompt or workflow: - Generic product questions → query org-wide Notion pages - Role-specific process questions → query role-scoped Notion pages using the appropriate integration token - User-specific context → query the user’s private Notion pages using their personal token This keeps the access logic in the agent’s reasoning layer, but enforces it at the API credential level. Even if an agent’s reasoning is flawed, it can’t retrieve data its token doesn’t have access to. ### Limitations to Know Notion’s API doesn’t support fine-grained row-level filtering within a database — it’s page-level access. If you need to share a single Notion database where some records are visible to all and some are restricted, you’ll need to either separate them into different databases or move to a more capable data store like PostgreSQL. ## Using GitHub Repositories for Structured Agent Memory GitHub repositories are an underrated memory layer for technical teams. They offer version control, branching, pull request workflows, and a mature permission model — all of which make them useful for agent knowledge that needs auditability. ### What Works Well in GitHub **Prompt libraries and agent instructions**— store system prompts, tool definitions, and behavioral guidelines as files. Teams can review and approve changes via pull requests.**Decision logs**— agents can write structured markdown files documenting decisions they’ve made, reasoning they’ve applied, and outcomes they’ve observed.**Shared knowledge bases**— technical documentation, runbooks, code examples, and process guides that agents can retrieve and reference.** Agent configuration files**— JSON or YAML files defining agent behavior, tool access, and memory retrieval strategies. ### Repository Permission Patterns GitHub’s permission model gives you several useful access levels: **Public repos**— visible to everyone. Use for truly public knowledge.** Internal repos**— visible to all members of a GitHub organization. Good for org-wide agent memory.** Private repos with team access**— visible only to specific GitHub teams. Map these to your departmental memory tiers.** Branch protection rules**— require reviews before memory updates are merged. This creates an audit trail for what agents know. For agent access, use GitHub fine-grained personal access tokens or GitHub Apps with repository-scoped permissions. A sales agent’s GitHub App gets read access to the sales-team repo. An engineering agent gets access to the engineering repo. Neither can cross into the other’s knowledge base. ### Version-Controlled Memory as an Audit Trail One advantage GitHub provides that most vector databases don’t: every change to agent memory is recorded, attributable, and reversible. If an agent starts surfacing incorrect or outdated information, you can trace exactly when that knowledge was added and who approved it. For regulated industries where AI behavior needs auditability, this is a meaningful advantage. ## Row-Level Security in PostgreSQL for Team Agents For the most precise access control — especially when agents read and write structured data — PostgreSQL’s [Row-Level Security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) is the strongest option available. RLS lets you define policies at the database level that restrict which rows a given database role can see or modify. This means access control is enforced in the database itself, not just in the application or agent logic sitting on top of it. ### How RLS Works You enable RLS on a table, then define policies that control access per role. Here’s a simple example pattern: ``` -- Enable RLS on the agent_memory table ALTER TABLE agent_memory ENABLE ROW LEVEL SECURITY; -- Policy: users can only see their own private records CREATE POLICY user_private_memory ON agent_memory FOR SELECT USING (owner_user_id = current_setting('app.current_user_id')::uuid); -- Policy: team members can see team-scoped records CREATE POLICY team_shared_memory ON agent_memory FOR SELECT USING (team_id = current_setting('app.current_team_id')::uuid); -- Policy: org-wide records are visible to all authenticated users CREATE POLICY org_memory ON agent_memory FOR SELECT USING (scope = 'org'); ``` When an agent queries this table, it connects as a database role that has these policies applied. The database automatically filters results based on who’s asking — the agent doesn’t need to construct filtered queries manually. ### Schema Design for Tiered Memory A practical schema for team agent memory in PostgreSQL might look like this: | Column | Type | Purpose | |---|---|---| `id` | UUID | Unique record identifier | `content` | TEXT | The memory content | `embedding` | VECTOR | Semantic search vector (if using pgvector) | `scope` | ENUM | `'private'` , `'team'` , `'org'` | `owner_user_id` | UUID | Nullable; set for private records | `team_id` | UUID | Nullable; set for team-scoped records | `created_by` | UUID | Always set; who created this memory | `created_at` | TIMESTAMP | Creation time | `metadata` | JSONB | Tags, source, agent ID, etc. | With pgvector installed, this same table supports semantic search with access filtering applied simultaneously. An agent can run a cosine similarity search and only ever retrieve records its current user is authorized to see. ### Setting Context for Agent Queries The policies above reference `current_setting()` to get the current user and team context. Your application layer sets these before each agent query: ``` -- Set user context before running any agent query SET LOCAL app.current_user_id = '550e8400-e29b-41d4-a716-446655440000'; SET LOCAL app.current_team_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890'; ``` This approach keeps the context-setting in the application, but enforces the filtering in the database. Even if an agent’s logic is buggy or manipulated, it cannot retrieve rows it isn’t authorized to see. ### Combining Vector Search With RLS The combination of pgvector and RLS is particularly powerful for team AI deployments. Agents can do semantic retrieval — “find memories similar to this query” — while RLS automatically scopes results to what the current user can access. This removes a common footgun where developers manually add `WHERE user_id = ?` clauses to vector queries and then forget that filter in one code path, creating a data exposure bug. ## Designing the Full Architecture Putting these pieces together, a robust team agent memory system typically has layers: ### Layer 1: Identity and Authentication Every agent request is tied to an authenticated user and their role. This identity is passed through the entire stack — to Notion API calls, GitHub tokens, and database connections. Never let agents run in an “anonymous” or “admin” mode that bypasses identity checks. ### Layer 2: Memory Routing Logic Before querying any memory store, agents determine which tier of memory is relevant. This can be: **Hardcoded in agent configuration**— specific agents are pre-configured to access specific memory tiers** Dynamic based on query classification**— the agent analyzes the incoming query and routes to the appropriate memory source** Hybrid**— agents always check org-wide memory, then optionally check team or private memory based on user context ### Layer 3: Enforced Access Controls At each memory store, access control is enforced at the infrastructure level: - Notion: scoped integration tokens - GitHub: fine-grained personal access tokens or scoped GitHub Apps - PostgreSQL: row-level security policies with context variables The goal is defense in depth. Even if the routing logic in Layer 2 has a bug, Layer 3 should prevent unauthorized data retrieval. ### Layer 4: Audit Logging ## Remy doesn't build the plumbing. It inherits it. Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something. Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want. Log every memory read and write, including which user triggered it, which agent performed it, what query was run, and what data was returned. This isn’t just good security practice — it’s increasingly a compliance requirement for AI systems handling sensitive business data. ## How MindStudio Handles Multi-Agent Memory and Access Control Building this kind of architecture from scratch is doable, but it’s a lot of plumbing before you get to the actual agent behavior you care about. MindStudio’s no-code agent builder has native integrations with Notion, GitHub, and databases like PostgreSQL — which means you can wire up the memory patterns described in this article without writing custom data access code. Each agent you build in MindStudio can be configured to use specific Notion integration tokens, connect to a specific database role, or access specific GitHub repositories. The access scoping lives in the agent’s configuration, not in custom middleware you have to maintain. For teams building multi-agent workflows — where one agent handles customer-facing queries, another handles internal research, and a third handles sensitive HR processes — MindStudio lets you deploy each as a separate agent with distinct memory access, all managed from the same platform. You get the isolation model described above without architecting the entire stack yourself. If you’re building out team AI infrastructure and want a starting point, you can try MindStudio free at [mindstudio.ai](https://mindstudio.ai). ## Common Mistakes That Cause Memory Leakage Even well-intentioned implementations fail in predictable ways. Watch for these: **Flat memory stores with no scope column** — if everything lands in one vector index or database table with no ownership metadata, you have no basis for filtering. Fix this at schema design time, not after data accumulates. **Relying only on application-layer filtering** — if the only thing preventing a user from seeing another user’s data is a `WHERE` clause in your agent’s query logic, one bug exposes everything. Enforce access at the infrastructure layer. **Shared API tokens for all users** — when every agent uses the same Notion or GitHub token, every agent has the same access. User-specific tokens or role-mapped tokens are required for real access isolation. **Caching retrieved memory without user context** — if you cache agent responses to improve performance, make sure cached entries are keyed by user identity, not just query content. A cached response to “what’s my performance review?” should never be served to a different user with the same query. **Implicit trust between agents in multi-agent systems** — when agents call other agents, access context must be passed explicitly. Don’t assume that because Agent A has restricted access, Agent B (called by Agent A) will inherit those restrictions automatically. ## FAQ ### What is the difference between shared and private AI agent memory? Shared memory is information accessible to multiple users or agents — typically org-wide knowledge like documentation, policies, or common procedures. Private memory is tied to a specific user and contains personal context, preferences, or sensitive information that should only be visible to that individual. In a well-designed team AI system, these live in separate storage locations with different access controls, not in the same flat memory store. ### How do I prevent an AI agent from leaking sensitive data to unauthorized users? ## Plans first. *Then code.* Remy writes the spec, manages the build, and ships the app. The most reliable approach is to enforce access controls at the storage layer, not just in the agent’s logic. This means using scoped API tokens for services like Notion, role-level permissions for GitHub repositories, and row-level security in databases like PostgreSQL. Defense in depth — combining routing logic, credential scoping, and database-level enforcement — is far more resilient than relying on any single control. ### Can I use a vector database with role-based access control? Yes, but support varies by database. PostgreSQL with the pgvector extension supports semantic search alongside full row-level security policies, making it a strong choice for teams that need both capabilities. Some managed vector databases like Weaviate and Qdrant offer namespace isolation or payload-based filtering that can approximate role-based access, though the enforcement model is typically less rigorous than SQL-native RLS. ### What is row-level security and how does it apply to AI agents? Row-level security (RLS) is a database feature that lets you define policies controlling which rows a given database user or role can access. For AI agents, this means you can store all memory records in a single table but have the database automatically filter results based on who is querying — without requiring agents to construct filtered queries themselves. It’s one of the most robust ways to enforce data isolation in a shared agent memory system. ### How should I handle memory for agents that serve multiple users? Design memory with explicit ownership metadata from the start. Every record should include who created it, what scope it belongs to (private, team, or org), and any relevant role or team identifiers. When an agent serves a request, it should run with credentials tied to the current user’s identity, so access controls at the storage layer automatically filter the result set to what that user is allowed to see. ### What audit logging should I set up for team AI agents? At minimum, log: the user identity that triggered each agent action, the agent that performed it, the type of memory operation (read or write), a summary of what data was accessed or written, and a timestamp. Store these logs separately from agent memory itself, with append-only access so they can’t be modified after the fact. For regulated industries, also log data classifications of records accessed and any access denials triggered by security policies. ## Key Takeaways **AI agent memory has distinct tiers**— org-wide, team-scoped, and private — and each tier needs its own access controls, not a single shared store.** Notion, GitHub, and PostgreSQL each have legitimate roles**in a layered memory architecture, and each has a native permission model you can leverage.** Row-level security in PostgreSQL**is the most precise tool for enforcing access control at the data layer, especially when combined with semantic vector search via pgvector.**Defense in depth matters**— route requests intelligently, scope your credentials, and enforce access at the storage layer. Don’t rely on any single control.**Audit logging isn’t optional** for enterprise AI deployments — it’s how you detect misconfigurations before they become incidents. Building the right memory architecture before agents accumulate sensitive data is far easier than retrofitting it after. Start with the taxonomy, enforce at the infrastructure layer, and audit everything.