Skip to content

Security model

Aurora MCP was designed to be safely exposed to an LLM. This page explains how.

  • OAuth 2.1 with PKCE (S256) — no client secret stored on the client side.
  • Resource Indicators (RFC 8707) — access tokens are bound to the exact MCP audience (https://mcp.ai.consilio.com), so they can’t be replayed against other Consilio services.
  • Protected Resource Metadata (RFC 9728) — your assistant discovers the auth server and required scopes automatically; nothing to paste.
  • Identity providerConsilioId, a Duende IdentityServer deployment.

Every request your assistant makes on your behalf is scoped to you — the signed-in Consilio user — with the same access you already have in the portal.

Tokens are terminated at the Envoy Gateway, which:

  • Validates the access token’s audience, scope, and signature.
  • Enforces per-tenant policy (per-tool allow/deny, scope requirements, AAL requirements).
  • Injects identity headers (x-consilio-user-sub, -email, -groups, -aal) into the forwarded request.

The MCP server never sees the access token itself — it trusts only the gateway’s identity headers. A Kubernetes NetworkPolicy blocks traffic from any source pod other than the gateway data plane, so those headers can’t be spoofed from inside the cluster either.

Every tool Aurora MCP ships is read-only:

  • searchMatters — read
  • searchWorkspaces — read
  • searchDocuments — read

There is no tool that writes, updates, or deletes anything upstream. The blast radius of an overly-enthusiastic LLM is bounded by this, by design.

  • No prompt content is persisted by the MCP server.
  • No tool output is persisted by the MCP server.
  • No access tokens are logged anywhere (the server never sees them).

Operational logs capture tool-name, latency, response size, and the identity of the caller — used for abuse detection and performance, not retained long-term.