GoodMem 1.0.307 is out, and with it the largest change since launch: a real authorization model. Until now an instance was effectively single-operator, one root key with full access to everything. That constraint is gone.
A quick tour of what’s new:
Teammates can be onboarded with a one-time enrollment credential and given roles on the instance or on individual spaces.
Spaces can be shared with a person, with a workload, or with every authenticated user on the instance.
Production workloads get their own service identities. Keys rotate underneath them without touching access, and nothing breaks when whoever set them up moves on.
API keys can carry a permission ceiling, so a key issued for a retrieval agent or a CI job stays bounded by its ceiling even if the account behind it can do far more.
Ownership of spaces, service identities, and the instance itself can be transferred explicitly.
The model was designed formally in Alloy before we implemented it, and CI checks the implementation against the spec. The documentation covers both the design and the day-to-day tasks: the security model, sharing a space, scoped API keys, and onboarding users.
There are breaking changes, mostly to API-key semantics; existing personal keys keep working. The upgrade guide walks through the list in the order it is likely to affect you.
To move to 1.0.307, run goodmem upgrade for the CLI, then goodmem system upgrade for the server.
If anything is unclear or breaks, post here and we’ll sort it out.
Great to see this release! We’re running GoodMem Cloud with 6 agent spaces on a shared instance and are ready to migrate off our custom space-locked proxy to the native authorization model.
A few Cloud-specific questions:
1. When will Cloud instances be upgraded to 1.0.307? We upgraded the CLI but the server REST API still returns the old schema (e.g. userId on API keys, no new auth endpoints). goodmem system upgradeappears to be self-hosted Docker only.
2. Once upgraded, can scoped API keys, service identities, and role assignments be managed via the REST API on port 443? The CLI uses gRPC on 9090, which isn’t exposed on Cloud instances. The Python SDK (v0.1.28) CreateApiKeyRequest doesn’t yet include ceiling, authority_mode, or subject fields.
3. Our target architecture: 6 service identities, each with a scoped key ceiling-locked to a single space (READ_SPACE, READ_MEMORY, CREATE_MEMORY for that space only). Is that the recommended pattern for multi-agent isolation on a shared Cloud instance?
Happy to share our current proxy setup if it’s useful context for what the native model replaces.
When a new version is available, we will show that to the GoodMem creator on the GoodMem card, along with an upgrade button. If the creator chooses to upgrade, the GoodMem will be ugraded after its next restart.
I’d be happy to answer your questions. Please let me know if this helps! Thank you.
2. REST management on port 443
Yes. On 1.0.307+ the entire authorization model is manageable over REST, nothing auth-related is gRPC-only:
API keys
Service identities
Roles & grants
Your instance also serves its live OpenAPI spec at GET /openapi.
For the Python SDK: this all shipped very recently, which is why you’re not seeing it. goodmem 0.1.29 was published to PyPI on
Aug 21 and adds authority_mode, ceiling, and subject_principal_id to CreateApiKeyRequest, plus client.service_identities and client.access_policy. And you’re right that the CLI
is gRPC-only, so REST/SDKs are the path on Cloud.
3. Recommended pattern
Yes — one service identity per agent, each with a scoped key ceiling-locked to its
space, is exactly the intended design. One fix: add LIST_MEMORY to your ceiling.
Semantic retrieval requires it, so with only your three ops the agents could write but
never search. The per-agent set you want (identical to the built-in SPACE_CONTRIBUTOR
role):
Operation
Selector
READ_SPACE
EXACT on the space
LIST_MEMORY
EXACT on the space
CREATE_MEMORY
EXACT on the space
READ_MEMORY
DIRECT_MEMBERS_OF the space
Provisioning per agent, with your admin key — the role must exist before the key is
issued, since a ceiling only caps the subject’s live authority, it never grants
anything:
POST /v1/service-identities — create the identity
POST /v1/access-policy/role-assignments — SPACE_CONTRIBUTOR on its space
POST /v1/apikeys — authorityMode: "SCOPED", subjectPrincipalId, and the
ceiling above. Save rawApiKey immediately; it’s returned exactly once.
Revoking a role assignment cuts that key’s access immediately, and rotation is just
issue-new-then-revoke-old for the same identity.