Security recommendations Alpha
Enginy MCP gives an MCP client the same data access as the approving Enginy user, within the approved scope set. Treat that client as a trusted operator, not as a passive viewer.
Recommended posture:
- connect only to the official hosted MCP URL:
https://openapi.enginy.ai/mcp - keep allowed redirect URIs tight, especially in production
- leave the allowed client-ID list empty only during initial setup or in lower-risk environments
- once you know the client IDs your team actually uses, pin them
- start from read-only scopes and add writes deliberately
- require human confirmation for write-heavy workflows so prompt injection or agent mistakes cannot silently mutate data
- revoke individual user connections when someone no longer needs MCP access
Why human confirmation matters Alpha
Like other remote MCP systems, Enginy is powerful enough to read and mutate business data on behalf of the user who approved it.
That means you should assume an unsafe prompt, malicious retrieved content, or an over-eager agent could try to:
- exfiltrate sensitive records
- broaden its own operating scope by suggesting risky re-authorization
- mutate campaigns, contacts, inbox state, or webhooks without enough review
Troubleshooting guide Alpha
| Symptom | What it usually means | What to check |
|---|---|---|
redirect_uri is not allowed | The callback URL is not on the workspace allowlist | Add the exact redirect URI, including port and path |
OAuth client_id is not allowed | The workspace is pinning client IDs and this one is missing | Add the exact client ID or remove the allowlist temporarily |
Requested scopes are not allowed | The client asked for more than the policy ceiling | Reduce requested scopes or expand the workspace policy |
Tool requires scopes: ... | The token authenticated, but the chosen tool needs more permission | Re-authorize with the required scope set |
Token validation failed | The connection, user, or policy is no longer valid | Check whether the user connection was revoked or the policy was disabled/tightened |
needs authentication or Cannot POST /token | The client assumed a shorthand token path or is using the wrong base URL | Verify the MCP URL and let the client use discovery; Enginy supports compatibility aliases too |
| No tools appear or only a tiny subset appears | The approved scope set is narrow or the client cached stale auth state | Run mcp_whoami, inspect granted scopes, then reconnect if needed |
| A refresh suddenly stops working | The refresh token was rotated, revoked, expired, or invalidated by policy | Re-authorize the client and make sure it stores the newest refresh token after each refresh |
Manual inspection points Alpha
If you need to debug a custom client:
- start from
https://openapi.enginy.ai/mcp - inspect OAuth authorization-server metadata instead of hardcoding endpoints
- confirm the token issuer and JWKS match the same Enginy environment
- verify the redirect URI and client ID values are the same ones Enginy saw during authorization
Operational behavior that surprises clients Alpha
- Enginy’s MCP transport is stateless. Do not rely on a sticky server-side session.
- Refresh tokens are rotating. Always replace the stored refresh token with the newest one.
- Reusing an already-rotated refresh token returns
invalid_grant; if another refresh already succeeded, the active token chain is preserved. - Tightening the workspace policy later can invalidate a previously working token set.
Overview (Alpha)
Revisit the architecture, tool-generation model, and admin-versus-user control split.
Clients & interfaces (Alpha)
See the discovery, transport, registration, and interface-specific setup details for client implementers.
Client support matrix (Alpha)
Confirm whether your client is a direct fit, a config-based fit, or a bridge-only integration.
FAQ / known limitations (Alpha)
Separate normal alpha limitations from real bugs before you start debugging the wrong thing.