Ask Codex to issue
the certificate.
Check the result
in CertLocker.

You are already in Codex or Claude Code, working through a deployment. The service needs a certificate. So you leave the conversation, open another tab, find the right ACME client, check the DNS configuration and start joining the pieces together.

Then you return to the agent and explain what you just did.

That handoff is what we wanted to remove. With CertLocker’s MCP server, the agent can work through the platform’s permitted API operations from the conversation you are already having. Certificate issuance is a good place to show what that means.

You can watch the live demo recorded by Sean above: connect Codex through MCP, request a certificate and inspect the result in CertLocker. All tokens shown in that recording have been rotated. The test evidence below comes from the separate recorded staging run.

A certificate you can actually inspect

On 28 September, we ran a complete test that started in the CertLocker UI and connected the real Codex CLI to our MCP server. Codex requested a fresh certificate through Let’s Encrypt staging, using a configured Cloudflare DNS client for domain validation.

The certificate appeared in CertLocker. The test independently checked the requested hostname against the certificate’s subject alternative name, its validity dates and the signatures between adjacent certificates in the returned chain.

Codex also created a host record and a certificate delivery token bound to that certificate. Later, it deleted the test certificate. The recorded run contains 18 real Codex MCP calls across issuance, resource creation, denied writes and deletion.

Let’s Encrypt staging performs real CA issuance and DNS validation, but its certificates are deliberately untrusted by browsers. This was a disposable integration test, with automatic renewal disabled.

Give it the job in plain language

A request can describe the outcome and its boundaries together. For example:

Use CertLocker MCP to discover the operations available to you.
Find the configured staging ACME client and the DNS client for my test zone.
Show me the proposed workflow before creating anything.

After I confirm, request one certificate for the hostname I provide.
Leave automatic renewal disabled.
Report the workflow status, certificate ID, SANs, issuer and validity dates.
Keep private keys, provider credentials and bearer tokens out of the response.

This is an example instruction, rather than a transcript of the recorded run. The hostname must belong to a zone your configured DNS client can validate. Existing clients are referenced by their resource IDs, so the agent can request issuance without receiving the DNS provider credential in its response.

The useful output is a workflow and a certificate you can check. If issuance fails, the next question is about the actual workflow state and error, rather than another guess at a shell script.

Three tools open up the wider platform

Our earlier MCP article described a small set of tools for secrets, certificates, hosts and access requests. The current implementation also exposes the role-protected Edge API, which serves CertLocker’s application workflows.

The agent follows three steps:

1. certlocker_list_operations discovers the operations its current roles permit.
2. certlocker_describe_operation retrieves the request fields, types and declared constraints for a chosen operation.
3. certlocker_call_operation submits that operation through CertLocker’s backend.

That gives the agent a way to learn the available interface instead of inventing endpoint names or asking you to paste API documentation into the chat. The recorded test discovered 163 operations under its broad test role; a more restricted agent sees a smaller catalogue.

These are calls into the real application services. Changes made through MCP appear in the same inventory and workflows that a human operator uses in the browser.

What can you ask it to do?

The discovered operations cover much more than issuing one certificate. What a particular agent can use depends on its roles, groups and token restrictions.

For example, you could ask it to list certificate expiry dates for resources in its allowed groups, inspect a failed ACME workflow, or prepare an audit summary of recent changes. It can discover the necessary operations and request schemas as it goes.

The precise scope is the set of supported, role-protected API operations exposed through discovery. Browser interactions and external systems still have their own requirements.

Connect Codex or Claude Code

In CertLocker, create an AI agent and assign the Edge roles and resource groups for the job. Create an MCP token linked to that agent, then open Tokens → Client setup. Choose Codex or Claude Code and copy the configuration for that token.

The panel supplies the endpoint and client-specific instructions. Codex uses a server entry in ~/.codex/config.toml; Claude Code has an HTTP install command and a JSON alternative. Preserve the rest of your client configuration when adding the entry. After restarting the client, use /mcp to check the connection. See the official Codex MCP guide and Claude Code MCP guide for client configuration details.

Start with a read-only request:

List the CertLocker operations I am allowed to use.
Find the certificates visible to this agent and report their expiry dates.
Make no changes and do not export credentials.

The recorded issuance walkthrough used Codex. Claude Code has its own client setup in CertLocker and connects to the same MCP interface; the Codex result is the evidence for the issuance test described here.

The agent has its own permissions

An agent does not inherit its owner’s access. It has its own assigned roles. Resource access is restricted by agent groups, and token groups can narrow it further. Where both group lists are populated, their intersection applies.

The backend checks permissions again when an operation executes. Hiding a write operation from discovery is only one part of the control.

In the recorded test, we changed the agent to Read Only and asked Codex to attempt writes. The calls were denied, and independent checks confirmed that the forbidden resources had not been created. Separate checks verified that role changes took effect within an existing session and that the agent could not grant itself more access.

The test used a broad role in its disposable environment to exercise the catalogue. A certificate assistant should have the narrower roles and groups its job requires.

A prompt asking the agent to wait before making changes is useful operator guidance. CertLocker’s backend permissions remain the enforcement boundary, and permitted mutations take effect when called.

Keep the credentials in the workflow

MCP responses redact credentials by default, including DNS provider configuration, ACME account keys, generated certificate keys and bearer tokens. The agent can still work with certificate IDs, public certificate data, validity dates and workflow states.

There is an explicit sensitive-export option for tasks that require it. It changes response redaction and still requires the existing permissions. Exported values, or credentials supplied in a request, can enter the AI client’s transcript or logs. For issuance and deployment, prefer existing server-side resources and their IDs.

Edge operation audit entries attribute the operation and HTTP outcome to an AI agent and session, without recording request bodies or returned secret values. The recorded test independently verified attributed host creation, token creation and certificate deletion. That gives an operator something to investigate after the conversation has ended.

Carry the job through to the running service

Issuance leaves another question: is the service actually serving the new certificate?

The MCP interface exposes operations for configured certificate deployment automations, alongside an issue_and_deploy_certificate prompt describing the sequence. With the right host access, service script and any configured approval, an agent can orchestrate issuance, run the deployment automation and inspect its outcome.

That still needs the operational detail. HAProxy must have the correct reload procedure. IIS needs its binding steps. A host behind a bastion needs the appropriate access route. The certificate’s actual lifetime depends on the issuer and profile you select.

The recorded Codex test proved issuance and resource operations. Its SSH and probe convenience-tool checks were dry runs; it did not prove a live HAProxy deployment. For a service deployment walkthrough, see our certificate Automations article.

One rough edge from the staging run is worth keeping visible: the test controller removed a residual DNS validation TXT record and verified that none remained. Automatic DNS cleanup was not proved by that run.

A conversation with a result behind it

Working in DevOps, the awkward part is often the work between tools: finding the right resource, carrying an ID across, checking what changed, and leaving enough evidence for the next engineer.

MCP lets Codex or Claude Code do more of that work through CertLocker. You describe the task, the agent discovers the operations available to it, and the platform applies its permissions and records the outcome.

You can open the inventory and inspect the certificate. You can review the workflow. You can check the audit trail. And when the agent’s access changes, its next request has to pass the current permission checks.

That is the workflow we want to make useful: ask for the work in the conversation, then check the result in CertLocker.