Security

How access is protected

Authentication

• TLS only. The server is served over HTTPS with HSTS.
• OAuth 2.1:
  • authorization code flow with PKCE, S256 only
  • dynamic client registration, with strict redirect URI rules
  • the iss parameter in authorization responses
  • tokens bound to https://mcp.estel.tech/mcp as their resource
• Consent: you sign in to Estel and approve each app on a consent page. It shows the app's name, where you'll be sent back to and the permissions requested.
• Expiry: authorization requests expire after 10 minutes. Authorization codes expire after 5 minutes and work once.
• Short-lived tokens: access tokens last 1 hour. Refresh tokens rotate on every use. Reusing an authorization code or an old refresh token revokes the whole connection, which stops a stolen token from being used.
• Secrets are hashed at rest: API keys, tokens, authorization codes and client secrets. An API key is shown once, when it's created.
• Your Estel login stays with Estel. The MCP server only accepts the credentials it issues. It never sees your password or app session.

Authorisation on every call

• Scopes. data:read explores. leads:enrich is needed to spend credits.
• Plan check. Each call checks that your subscription includes MCP access. Plan changes apply within a minute.
• Limits. Per-user quotas and a per-minute rate limit are enforced on the server, the same for every client.
• Revocation. Revoked keys and disconnected apps stop working within 30 seconds.

Protecting the service

• Host and Origin checks on every MCP request, against DNS rebinding.
• Request size limits.
• Per-IP rate limits. Repeated failed authentication is temporarily locked out.
• Read-only queries. Exploration runs in read-only database transactions with a statement timeout.

Protecting data

• Allow-listed output. Responses are built from fixed schemas, so fields outside them can't leak. See Data and privacy.
• Safe errors. Errors never contain stack traces, SQL or internal names.
• Minimal logs. Tool calls are logged with argument names only, never their values.

Keeping your account safe

• Prefer sign-in (OAuth) for apps that support it. Nothing long-lived needs to be stored.
• Give credentials the least access they need. Untick Allow enriching leads for keys that only explore.
• Set an expiry on keys for scripts and CI, and use one key per integration.
• Store keys in a secret manager or an environment variable. Never put them in code, committed files, URLs or chat messages.
• Review Settings → API & MCP regularly. Revoke keys and disconnect apps you no longer use.
• Approve only apps you recognise on the consent page, and check where it will send you back to.
• Ask your assistant to confirm before enriching, so credits aren't spent without you knowing.

If you think a key has leaked, revoke it at once in Settings → API & MCP, then create a new one.

Reporting a vulnerability

If you find a security issue, email support@estel.tech with "Security" in the subject. Please include steps to reproduce, and give us reasonable time to fix it before you disclose it. Don't access other people's data, and don't degrade the service while testing.