Credential lifecycle
Workspace credentials let apps and agents call Slab5 without sharing a human admin session. Treat API keys and MCP client tokens as scoped, revocable workspace access.
Credential types
Slab5 has two local-first credential types:
- API keys for REST clients, backend apps, scripts, and service integrations.
- MCP client tokens for Claude, Cursor, ChatGPT/custom MCP, LangGraph adapters, and other agent runtimes.
Both resolve to one tenant and one workspace before scopes, module enablement, plan limits, audit logging, and usage metering run. Hosted OAuth MCP connections use the signed-in user's workspace membership and can be narrowed with explicit OAuth workspace grants.
Create
Workspace owner and admin members can create credentials. Members and readonly users cannot create credentials.
Create credentials with:
- A human-readable name.
- The smallest scope set needed for the workflow.
- A clear owner or system purpose.
- The target workspace confirmed before the secret is shown.
The raw secret is shown once. Slab5 stores only a prefix and hash.
Store
Store secrets in local environment files, CI secrets, or a managed secret store. Never commit real credentials to Git.
Do not paste credentials into agent prompts, issue comments, support tickets, screenshots, docs examples, or browser clients. Browser and mobile apps should call a customer backend, and that backend should call Slab5.
Rotate
Rotate a credential by creating the replacement first, deploying the new value to the client, confirming successful calls, then revoking the old credential.
Use a short overlap window. Keep credential names explicit enough that admins can tell which service still uses the old token.
Revoke
Revoke credentials when:
- The owning service is retired.
- The secret may have been exposed.
- The scope set is broader than the workflow needs.
- A developer, contractor, or automation no longer owns the integration.
- Workspace policy changes from static MCP tokens to OAuth-only access.
Revocation should block new API/MCP calls immediately while preserving historical audit and usage records.
OAuth grants
OAuth MCP grants are not shared secrets. They are workspace authorization records for one OAuth subject. Workspace owners and admins can create, update, or revoke them from the MCP Clients page.
Use OAuth grants to limit a hosted OAuth client to the scopes needed for an agent workflow. A grant cannot add scopes beyond the user's Slab5 workspace role, and module enablement still applies.
If a grant is revoked, new OAuth MCP calls for that subject fall back to the workspace role behavior. To remove OAuth access completely, revoke the user's workspace membership, reduce the user's role, or change the workspace MCP auth policy.
Audit and usage
Credential create and revoke actions are audit events. Credential creation is also recorded as usage visibility so admins can track active integration footprint.
Credential metadata may include name, prefix, scopes, status, timestamps, creator, and last-used time. Secret values are never stored in audit metadata, usage metadata, structured errors, or logs.
