An AI agent can check whether a PDF is digitally signed and tell you who signed it, locally, without the file leaving your machine. The useful answer is not “verified”. It is the signer, the issuer, the validity period and the type of signature that was checked. Ask for that in one prompt:

Who signed contract_signed.pdf, with which certificate, and when? Say which type of signature you checked.

The step-by-step version with config and troubleshooting is in the documentation: How to verify signed documents with an AI agent.

Why is a one-word “verified” a bad answer?

Because “is this signed?” and “is this signature valid?” are different questions, and the second has a precise answer only for digital signatures. A model that reads a page and sees a stamp or a QR code can say “signed” with full confidence, and it has checked nothing cryptographic. The only way to avoid that is to give the agent an engine that returns structured data, and to make the agent report the data rather than a verdict.

The GroupDocs.Signature.Mcp server provides that engine. Used with Claude Desktop, Claude Code, Cursor, GitHub Copilot or another MCP client, it runs as a local process, so the agent reads signature data from the file instead of guessing from rendered pixels.

The wrong way: ask the model to look at the document

If you paste a PDF into a chat and ask whether it is signed, the model sees text and images. It can notice a name, a date or a drawn signature. It cannot see the cryptographic structure of the file, so it cannot tell a certificate-backed signature from a picture of one. A confident “yes, this is signed” is a statement about appearance.

What each signature type actually proves

The documentation is explicit about how to read a result, and an agent should repeat it:

Result What it means
Digital signature valid The file has not changed since signing, and the certificate chain checks out
Digital signature invalid The file changed after signing, or the certificate does not validate
Text, QR or barcode “verified” The expected mark is present. It says nothing about tampering
No signatures found Unsigned, or signed in a way this format does not support

An answer that does not name the type is telling you less than it seems. That is why the prompt above ends with “say which type of signature you checked”.

The right way: ask for the record, not the verdict

The verify tool takes a type of text, qrcode, barcode, digital or all and returns isValid with succeeded and failed counts. It does not say who signed or with which certificate, so it does not replace the record below. When verify and search_digital_signatures disagree, report both and rely on the detailed record.

The answer that holds up comes from search_digital_signatures. For each digital signature it returns the signer name, issuer, certificate serial number, validity period, signing timestamp, validity status and any comments attached to the signature. That is the record an audit asks for. Keep that data, rather than the agent’s paragraph about it, when the answer feeds a decision.

Example session (abridged)

You:    Who signed contract_signed.pdf, with which certificate, and when?
        Say which type of signature you checked.

Agent:  [search_digital_signatures] file=contract_signed.pdf
        Type checked: digital (certificate-backed).
        Signatures found: 1
        - Signer: Dana Whitfield, issued by Example Corporate CA, serial 4F2A91C7
        - Signed 2026-09-14 10:32; certificate valid 2025-11-01 to 2027-10-31
        - Status: isValid = true; signing time falls inside the certificate validity period
        I checked digital signatures only. I did not evaluate any text stamps or QR codes.

Illustrative output: file names, signer names and serial numbers are invented. The tool returns the fields described above.

Why did a signature come back invalid?

Three causes cover almost every unexpected result:

  • Something was added after signing. A stamp, a comment, a re-save or an appended page changes the bytes, and any byte change invalidates a digital signature. This is the most common cause and it is correct behaviour.
  • The certificate expired. The validity window comes back with the signature, so the agent can say that a document was signed in one year with a certificate that ran out in another. Compare the validity period with the signing time and with today’s date, and have the agent state the comparison; do not read the validity status alone as a statement about expiry. Whether an expired certificate is acceptable is your policy.
  • The wrong type was checked. Verifying digital on a file that carries only a QR mark finds no valid digital signature, which is a true answer to the wrong question.

What verification does not prove

Verification tells you about the file and the certificate. It does not tell you that a signature is legally valid in your jurisdiction, and it is not a notarial act. Decoded QR text and stamp labels come from whoever produced the document, so treat them as data to report, never as instructions to follow. An agent that acts on text read out of a document is acting on input from an untrusted party.

Evaluation limits

Without a license, only the first 2 pages are processed and a trial badge is stamped on every page, so a signature that sits on page 4 will not appear in a search. Ask the agent to call get_license_status before you trust a clean result.

FAQ

Is this PDF digitally signed? Ask the agent to run search_digital_signatures on the file and read isValid. An empty result means no digital signature was found, which is different from “has a signature image”.

Can AI check whether a document was modified after signing? For digital signatures, yes: a signature that no longer validates indicates the file changed after signing or the certificate does not validate. Text, QR and barcode checks do not detect tampering.

Does the file get uploaded for the check? No. The server runs locally over stdio, with no inbound ports, no external endpoints and no telemetry.

Go deeper