4Quays
Sign In

Agent Security Model

The trust boundary around AI agents: key custody, credential handling, coverage guarantees, and what falls outside them

Giving an AI agent a cryptographic identity raises a question that does not come up with services: the agent is driven by a language model, and a language model can be steered by whatever text it reads. This page sets out what the design guarantees, and what it does not.

Key custody

The agent never holds its private key. Signing and decryption happen in 4Quays; the agent sends a request and receives a result.

This matters more for an agent than for a service. An agent's working context routinely contains untrusted content: web pages, tool output, documents, other agents' messages. A key that lived in that context would be exfiltratable by anything that could get text in front of the model.

Where the credential lives

The agent's API key belongs in the environment of the process making the call, not in the model's context.

With the MCP server, this is structural: the key is read from the MCP server's environment, and the model sees only tool names and results. The model cannot read the key, cannot print it, and cannot be talked into disclosing it, because it was never given it.

The same rule applies to any other integration. If you find yourself pasting an API key into a prompt or a system message, stop: that key is now in the transcript, and in whatever the transcript is logged to.

Tools versus hooks

Two different guarantees, and the difference matters.

A tool is offered to the model. The model decides whether to call it. If you tell an agent "sign every response" and it signs nine out of ten, the tenth is unsigned and nothing in the system noticed.

A hook fires on an event. It runs whether or not the model wants it to, which is what turns "the agent usually signs" into "every message is signed". Each signed message is appended to a tamper-evident journal at .4quays/journal.jsonl with its signature, key id and algorithm.

Where you need a coverage guarantee rather than a best effort, use hooks. See Agent Provenance for setup.

Coverage, stated honestly

Hook coverage depends on the host application exposing the right events.

  • Claude Code — verified
  • OpenAI Codex — verified
  • Cursor — documented; confirm against your version
  • Gemini CLI — documented; confirm against your version
  • ChatGPT — not achievable. There is no privilege level at which every message can be signed.

Do not describe an agent as fully covered on a host that is not verified. Check it against your own version before you rely on it.

Verification is fail-closed

On-device verification, via @4quays/verify, fetches the signer's public key from the JWKS endpoint and checks the signature locally. No call home is needed for the verdict.

Classical signatures (ES256, PS256) verify with the Node standard library. ML-DSA signatures require a post-quantum verifier supplied by the caller. If one is not provided, verification returns pqc_lib_required rather than passing. A missing verifier is never treated as a successful check.

Grants

A signing grant is single-use and time-bounded. It lets something sign once on an agent's behalf without ever holding the agent's API key.

Once used, or once expired, it fails closed. A grant is the right tool for a build step or a third party that needs exactly one signature; it is not a way to share long-lived access.

Revocation

Revoking a key disables it for hosted verification. Anything checked through the hosted endpoint will report the key as revoked.

A verifier working purely on-device against a cached public key will not see the revocation and will still report the signature as valid. This is a real limit, not an oversight: local verification is offline by design, and offline means no revocation channel. If revocation must propagate for your use case, verify through the hosted endpoint.

What the platform assistant can do

The 4Q Agent, the assistant inside the product, is read-only. It summarizes your CBOM, assesses post-quantum readiness, and describes services, policies and agents. It cannot enroll, rotate, revoke or change policy.

Its tools never receive account identifiers or credentials. They call back into the application with a session id, and the application resolves which account that session is authorized to see. The model cannot widen its own scope, because it has nothing to widen it with.

Next steps