4Quays
Sign In

Managing Agents

Enroll AI agents as cryptographic principals, manage their keys, and connect them to your tools

An AI agent in 4Quays is a first-class cryptographic principal, the same as a service. It has its own key pair, its own policy, and its own entries in the audit log. That is what lets an agent sign a message another party can verify, or receive an encrypted message only it can open, without the agent ever holding key material itself.

This page covers the console work. For wiring an agent up to Claude Code, Codex, Cursor or VS Code, see Agent Provenance.

Enrolling an agent

From Agents, choose Enroll agent. You give the agent a name, pick a policy, and choose what it needs to do.

An enrollment creates:

  • An ML-DSA signing key, so the agent can sign messages and artifacts.
  • Optionally an ML-KEM encryption key, if the agent needs to receive encrypted messages.
  • An API key, shown once. It belongs in the agent's environment, never in a prompt or a committed file.

The private key stays in 4Quays. The agent calls the API to sign or decrypt, which is what keeps the key out of the model's context and out of your repository.

Choosing a parameter set

Signing keys are available at ML-DSA-44, ML-DSA-65 and ML-DSA-87; encryption keys at ML-KEM-512, ML-KEM-768 and ML-KEM-1024. Higher parameter sets mean larger signatures and slower operations. ML-DSA-65 with ML-KEM-768 is a reasonable default unless your policy says otherwise. See Supported Algorithms for the full list.

The policy decides which parameter sets an agent may use. If you request an algorithm the policy does not permit, or one that cannot serve the key's purpose, enrollment is rejected rather than silently downgraded.

Rotating keys

Rotate issues a new key pair and marks the previous one as rotated. The agent starts signing with the new key immediately.

Signatures made with the old key keep verifying. That is deliberate: a signature is a statement about a moment in time, and rotation is not a reason to invalidate everything an agent ever signed. Verification results will show that the signing key was rotated, and that the signature is still valid.

Signing grants

A grant is a short-lived, single-use credential that lets something sign once, on behalf of an agent, without holding the agent's API key.

Use one when you want a build step, a one-off script or a third party to produce exactly one signature. From the agent detail page, choose Mint grant, set the expiry, and hand over the token. After it is used, or after it expires, it fails closed.

Revoking and deleting

Revoke disables the key. Hosted verification of anything signed with it will report the key as revoked.

Note what revocation does not do. A verifier checking a signature entirely on-device, against a cached public key, has no way to learn about the revocation. If your threat model depends on revocation propagating, verify through the hosted endpoint rather than locally.

Delete removes the agent. Its audit log entries remain, because they are a record of what happened.

Clearsign

Clearsign wraps a block of text in a signature while leaving the text readable, the way PGP clearsign does. Use it when a human needs to read the content and a machine needs to check it, for example an agent posting a decision into a ticket.

Each clearsigned block gets a shareable verification link at /v/<id>. Anyone with the link can confirm the signer and that the content is intact, with no account and no API key.

Watching agent activity

Agent operations appear in Monitoring and Audit Logs alongside service operations, and alert rules evaluate over both. An alert rule scoped to an agent can fire on error rate, latency, throughput, deviation from a baseline, or on the absence of activity you expected to see.

Next steps