Can an AI agent hold a QES and sign for you?

Under eIDAS 2.0, a qualified electronic signature carries the same legal weight as a handwritten one, and from the EUDI Wallet it's free for natural persons — a real reframing, since QES used to be a paid product most people never touched. That's a big enough shift that the obvious next question follows immediately: if an agent can act on your behalf in a browser, book your travel, manage your inbox, can it also hold your QES and sign documents for you? Build the QES track and the answer stops being philosophical and becomes something you can point at in code.

Start with what "qualified" actually means, because the lab's Phase 4 build makes the distinction concrete in a way the acronym soup usually doesn't. An advanced electronic signature (AES) and a qualified one (QES) can be, cryptographically, the exact same artefact — same CMS structure, same ECDSA signature, same certificate chain validation logic. In this lab's toy CA, the entire difference between a "qualified" and an "advanced" leaf certificate is one X.509 extension: qcStatements (ETSI EN 319 412-5, OID 0.4.0.1862.1.1), asserting the certificate was issued under a qualified-certificate policy. Attach it, the certificate is qualified. Omit it, everything else identical, and you have a perfectly valid AES that will never be a QES no matter how cleanly it verifies. One of the five break-it experiments in this lab (advanced_not_qualified_cert_as_qes) builds exactly that case on purpose: signature valid, chain trusted, timestamp valid — every deterministic check passes — and it is still not a QES, because is_qualified reads that one extension and it isn't there. Everything passed. That is not the same as qualified. The lesson is designed to be uncomfortable precisely because "everything passed" is what most engineers instinctively read as "we're done."

What makes a certificate qualified is mostly not cryptography. It's who issued it (a Qualified Trust Service Provider, audited and supervised, not any CA), what checked the signer's identity before issuance, and — this is the part that bears directly on the agentic question — what device held the private key at signing time. eIDAS requires a Qualified Signature Creation Device (QSCD): hardware, certified, built so the key cannot be extracted and so signing requires the legitimate holder's own action. This lab's Python signer key is an ordinary cryptography P-256 keypair sitting in a variable. It produces byte-identical signatures to a QSCD-backed one. It is not a QSCD, and no amount of correct code changes that, because QSCD status is a property of the device, certified by a body that isn't this lab, not a property of the signature it produces. Phase 3.5's WebAuthn wallet hit the same wall from a different angle — non-extractable keys, hardware-gated unlock — and still isn't a Wallet Unit, because being one requires certification this lab cannot obtain. Same shape of limit, different layer of the stack.

Which is the actual answer to the framing question. Sole control — the legal requirement that only the signer can invoke the QSCD — is enforced by hardware and procedure, not by whoever's fingers are on the keyboard. An AI agent with API access to a signing key held in ordinary software has never been closer to holding a QES than a script has, because a QSCD's entire job is refusing to sign for anything that isn't the certified activation path — a human satisfying a possession-and-knowledge or possession-and-biometric gate the device itself checks. There's no API an agent calls instead. If an agent could invoke that gate, so could a compromised script, a stolen session, or a browser extension — which is exactly the failure mode QSCD certification exists to close off. The wallet spec, not this lab's implementation of it, already answers the question: the sole-control requirement is written to bind to a person, and "a person" is a category an agent doesn't clear by getting more capable. It would need to clear it by being one, which is a different, much larger claim than anything in this lab's scope.

The more interesting question, and the one this lab doesn't answer because it sits outside what a toy QTSP can demonstrate, is what happens upstream of the signature: an agent drafting the document, deciding what needs signing, presenting it to the human at the right moment with enough context to make sole control meaningful rather than rubber-stamped. That's a UX and consent-design problem, not a cryptographic one — and unlike the QSCD boundary, it's a problem this project's tooling could actually be extended to probe.