AI agents · MCP · Access control

MCP for Secrets and Certificates: Scope the Token, Keep the Audit

By Sean Monaghan · · 4 min read

MCP gives an AI agent a way to call tools. The credential behind those tools determines what it can actually do. In CertLocker, an MCP token ties access to an agent, permitted scopes, resource groups, and expiry, with audit evidence for the work.

That is the question I would start with in any evaluation: if an agent asks for the wrong resource, what refuses the request, and where can the operator see it afterwards?

Four MCP patterns worth distinguishing

Infisical: its official API MCP server offers secret read and write tools using machine-identity or access-token authentication. It documents tool allowlists and optional secret-value masking. Its documentation MCP is a separate service for searching docs. A docs connection does not grant tenant access.

Doppler: its MCP server exposes API operations such as reading secrets, updating configurations, and viewing activity logs. It has read-only and project/config options, but Doppler explicitly says properly scoped tokens enforce access. Treat a client-side restriction as an aid, not the permission boundary. The docs currently label the server experimental.

CertSecure: Encryption Consulting’s MCP announcement describes certificate lifecycle actions under existing RBAC, with approval workflows for renewal and revocation and agent actions in the audit log. That is a certificate operations pattern, rather than just retrieving an application secret.

CertLocker: the hosted MCP connection puts allowed secrets, certificates, hosts, probes, approval requests, and audit tools behind the agent’s scoped token. An operator can investigate a certificate and its host through the same connection. Current MCP secret operations are list/read; creation and rotation of secrets, delivery-token creation, and renewal mutations are not yet in the documented live tool surface.

Scoped credentials and audit are shared requirements across these approaches. CertLocker’s practical angle is bringing certificate and host operations into the same agent workflow. Choose by the task and the permissions it requires.

Evaluate one agent with one bounded task

  1. Create an agent for a non-production investigation. Give its token only the groups and read scopes that task needs, with an explicit expiry.
  2. Ask it to list allowed resources and inspect certificate or secret metadata before requesting any values.
  3. Use an SSH or probe dry run where available. Review the proposed host and action before execution.
  4. Request a known out-of-scope test resource. Confirm denial and inspect the audit evidence.
  5. Revoke the test token and confirm it can no longer be used.

A secret returned to an agent can enter the model’s context. MCP does not make that exposure disappear. Metadata-first investigations and narrow permissions let you decide when a value is actually needed.

Connect CertLocker MCP

The hosted streamable HTTP endpoint is https://trust.certlocker.io/rest/mcp. Create the agent and MCP token in Trust, then follow the connection guide for your client. The token belongs in the client’s credential configuration, not in a prompt.

For a broader product evaluation, read CertLocker vs Infisical. To see how an access scope carries into operator work, see SFTP uploads in the browser terminal.