Read-only MCP integration

Connect compatible AI clients to permitted certificate metadata and operational status.

Documentation for 1.0.38. Screenshots show example data.

Planned for 1.0.38. MCP is an optional separate process/container. Upgrading the appliance does not expose a public MCP endpoint.

Available tools

  • ▸search_certificates and get_certificate: certificate identity, SANs, validity, public-key algorithm, fingerprint and revoked/superseded status.
  • ▸list_certificate_authorities: permitted CA metadata.
  • ▸list_agents: host identity, version, approval status and last heartbeat.
  • ▸list_jobs and get_job: operation type, execution state, timestamps and uncertainty indicators.

There are no issuance, renewal or deployment tools. Private keys, connector credentials, raw job payloads and detailed result bodies are not exposed. Use the platform UI for detailed job diagnostics.

Create scoped access

  1. 01As an administrator, open Settings → Access & security → MCP / AI integrations under the existing MFA policy.
  2. 02Name the client or audience, choose validity and the minimum access needed. Tokens expire in 1–90 days. Collection-scoped credentials permit certificate reads; CA, agent and job scopes require explicitly acknowledged platform-wide access.
  3. 03Save the one-time token in a protected credential file. Do not put it in chat, Git, a URL or command arguments. The server stores a hash and checks scope, expiry and revocation on each request.
  4. 04Deploy the release-matched MCP bridge and configure verified HTTPS to the appliance. Supply the token and trusted CA chain through protected files; the bridge needs no database connection, Docker socket or device credentials.
  5. 05Connect your compatible client and verify a read within the permitted scope. Use separate bridges and credentials for different audiences.

Local and remote clients

Local STDIO: the AI client starts the bridge process/container with standard input and output attached. Protocol messages use stdout; logs use stderr. Do not allocate a TTY. Use the release-matched setup instructions in the application documentation.

Remote access: configure the authenticated remote transport and its OAuth/Entra requirements deliberately. Remote identity does not inherit the human user’s ens0key roles or collection grants; the bridge credential determines what every connected client can read. Validate compatibility with the intended client before rollout.

Review data exposure

Certificate identities and operational metadata read by an AI client become available to that client and its service/model. Review that boundary before granting access. Collection filter changes can change the visible set; deleting a collection deletes its credentials.

Revoke credentials that are no longer needed and rotate before expiry. Do not disable TLS verification or trust an unverified leaf certificate to make a connection work.

The existing API credentials inventory is a metadata registry, not the credentials that authenticate this integration. The built-in AI Assistant is also a separate feature.

ens0key 1.0.38-preview · Example data