Access Levels

Different agents need different context. Your legal AI doesn't need code review patterns. Your engineering copilot doesn't need invoice dispute histories. Access levels let you provision the right memory to the right consumer.

How It Works

Every memory is tagged with a category describing its domain (e.g., financial, code-quality, architecture). When you create an API key, you assign it an access level — a named preset that grants access to a specific set of categories.

The key only sees memories in its allowed categories. A finance-level key returns financial and compliance memories. An engineering-level key returns code quality, architecture, infrastructure, and security memories.

Access Levels

Level	Categories	Use Case
`engineering`	code-quality, architecture, infrastructure, security	Dev tools, code review agents, engineering copilots
`finance`	financial, compliance	Legal agents, audit dashboards, finance tools
`product`	product, team	PM agents, roadmap tools, retrospective bots
`operations`	infrastructure, security, compliance	SRE agents, incident response, on-call tools
`full`	All categories	Admin dashboards, executive agents, org-wide search

All levels include uncategorized memories (those that don't clearly fit a domain).

Memory Categories

Categories are assigned automatically using hybrid classification:

Rule-based defaults — signal source and type determine a default (e.g., Stripe signals → financial)
LLM override — the classifier can reclassify when content clearly belongs elsewhere (e.g., a Slack message about billing → financial instead of team)

Category	Description	Default Sources
`code-quality`	PR patterns, review conventions, test coverage	GitHub (reviews, comments)
`architecture`	Tech stack decisions, system design choices	GitHub (decisions), Linear
`infrastructure`	Deploys, incidents, outages, CI/CD	GitHub (alerts), Slack (alerts)
`financial`	Revenue, billing, disputes, subscriptions	Stripe
`compliance`	Audit trails, disputes, policy decisions	Stripe (disputes), Jira
`product`	Feature requests, user feedback, roadmap	Linear, Jira
`team`	Process decisions, communication patterns	Slack
`security`	Vulnerabilities, access changes, auth patterns	GitHub, Slack

Creating a Scoped API Key

When creating an API key via the admin API, pass the accessLevel parameter:

curl -X POST https://mneme.fly.dev/api/keys \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"installationId": 123, "name": "legal-agent", "accessLevel": "finance"}'

Response:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "key": "mneme_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "prefix": "mneme_a1b2c3",
  "accessLevel": "finance"
}

If accessLevel is omitted, the key defaults to full.

MCP Configuration

Point your agent at the MCP endpoint with a scoped key:

{
  "mcpServers": {
    "mneme-legal": {
      "type": "http",
      "url": "https://mneme.fly.dev/mcp",
      "headers": {
        "Authorization": "Bearer mneme_<finance-scoped-key>"
      }
    }
  }
}

The agent will only receive memories tagged as financial or compliance — no code patterns, no infrastructure alerts, no team discussions.

Multiple Keys Per Installation

You can create multiple keys with different access levels for the same installation:

# Engineering agent
curl -X POST .../api/keys -d '{"installationId": 123, "name": "eng-copilot", "accessLevel": "engineering"}'

# Finance agent
curl -X POST .../api/keys -d '{"installationId": 123, "name": "legal-bot", "accessLevel": "finance"}'

# Executive dashboard
curl -X POST .../api/keys -d '{"installationId": 123, "name": "exec-dash", "accessLevel": "full"}'

Backward Compatibility

Existing API keys default to full access — no behavior change
Existing memories are automatically categorized based on their source signal
All API changes are additive (new optional fields)
MCP tool responses are unchanged in structure — filtering happens server-side

Access Levels

On this page