Security
How LockMCP protects your credentials and data, and what you can see and control yourself. Find the workspace view at Dashboard → Security.
This page describes product behaviour — what the platform does and what you can verify in your own dashboard. For contractual security commitments, compliance documentation or a security questionnaire, contact us directly rather than relying on this page.
Credential encryption
Your connections hold credentials for your upstream APIs — API keys, bearer tokens, OAuth secrets. These are encrypted at rest with AES-256-GCM, an authenticated encryption scheme, so stored ciphertext can't be silently altered without detection.
Credentials are decrypted only when a tool call needs them to reach your API. They are never shown back to you in full after saving, and never included in logs or audit entries.
The Security page lists which connections hold encrypted credentials, along with the algorithm and encryption version in use.
Signing keys
Connections that issue tokens use ES256 key pairs to sign them. The private key is itself encrypted at rest; the public key is what verifies tokens.
The Security page shows each key's status and expiry.
An expired signing key stops authentication working. Keep signing key expiry warnings enabled under Workspace Settings → Notifications, and point the alert email at a monitored shared inbox. This is the single most preventable cause of an avoidable outage.
Data encryption key
The key protecting your stored credentials. The Security page shows when it was last rotated, or flags that it never has been.
Rotating periodically limits the value of any single key compromise. Rotation re-encrypts existing credentials — your connections keep working throughout.
Workspace isolation
Every workspace's data is isolated. Queries are scoped to the workspace at the database level, not only in application code — so a bug in a query can't return another workspace's rows.
Connections within a workspace are also scoped: each has its own MCP endpoint, and tools are served only for the connection that was addressed.
How tool calls are protected
Each call passes several checks before reaching your API:
- Token verification — the caller's token must be valid, unexpired, and signed by the expected issuer.
- User resolution — the token maps to a real member of your workspace.
- Role check — the tool list is filtered in the query itself, so a user is never handed a tool their roles don't permit.
- Connection state — only Active connections serve tools.
- Proxy — the call goes to your API with the connection's stored credentials.
Outbound requests are validated to prevent tools being used to reach internal or private network addresses, so a malicious spec can't turn a connection into a probe of infrastructure that isn't yours.
Defence against prompt injection
Responses from your API pass through a sanitisation step that defuses phrases commonly used to hijack a model's instructions. It's non-destructive — your data is still readable — and it's a mitigation, not a guarantee.
Treat it as defence in depth. Content that reaches an AI client is ultimately interpreted by a model, so your API should remain the authority on authorisation regardless of what a response contains.
What you control
| Control | Where |
|---|---|
| Who has access | Members & Access |
| What each role can call | Assigning Tool Access |
| Which tools exist at all | Tool Catalog |
| Ending a live session | Sessions — see Monitoring & Audit |
| Who did what | Audit Log |
| Key state and rotation | Dashboard → Security |
Practices worth adopting
Grant the narrowest tool access that works. An AI client will eventually call anything it can see. Restricting the tool list is more reliable than expecting restraint from a model.
Don't publish destructive tools casually. If delete_customer is published, keep it in one narrow role rather than letting it ride along in a general-purpose one.
Keep your API's authorisation independent. LockMCP constrains what the AI can attempt; your backend should still reject anything the user shouldn't reach. Both layers matter, and only yours is authoritative.
Revoke properly when someone leaves. Removing a member stops future sign-ins but doesn't invalidate a live token for Identity Brokering or Token Exchange. Revoke their sessions too.
Review access periodically. Tool access accumulates. A monthly pass over the Tool Catalog Access column catches roles that quietly grew.
Where to go next
- Monitoring & Audit — the audit trail and live sessions
- Assigning Tool Access — the main lever you control
- Workspace Settings — notifications and provisioning