Security

1. Commitment

PDFService is a multi-tenant hosted SaaS platform for simple electronic signatures (SES) on ordinary business documents. We apply layered controls appropriate to a document-trust product that humans, AI agents, and developers all use.

This page is a public overview, not a certification claim or a substitute for a written enterprise security addendum.

2. Transport and edge

Production traffic is served over HTTPS at the public edge. Same-origin routing keeps the web app and API on pdfservice.ai under one host contract.

• TLS for web, API, and MCP endpoints in production
• Hosted same-origin design so browser sessions do not need a separate public API host
• Security response headers (including CSP posture) applied at the reverse-proxy edge

3. Authentication

Senders and signers use different authentication models. Agents and API clients share the same account-bound credentials as the workspace.

• Sender access: account session after sign-in (and workspace roles as configured)
• Programmatic access: workspace API keys (Bearer) for REST and MCP — keys act as your account
• Signer access: email one-time codes (OTP) plus scoped capability tokens for the signing session
• Placement-ceremony signer access: capability-token links only — no account, no password
• OTP secrets are stored hashed; codes are short-lived
• Manage operations require scoped credentials — not bare document identifiers alone

4. Cryptography and evidence

When a signature completes, our signing engine produces a tamper-evident PDF. Signing steps form an audit trail you can download with the PDF. The private signing key is held by the service after the signer completes email verification and consent — not by the signer. That integrity evidence supports our SES product only.

Placement ceremonies are a separate lane with no seal: drawn or imported signature images, dates, and text values are flattened into the PDF pages as a visual artifact. No cryptographic seal is applied to placement output and no PAdES package is produced.

• PAdES-format packaging of completed PDFs (technical format — not AES and not QES by itself)
• Platform-managed certificate and keystore inside the signing service boundary
• Append-only, hash-linked audit events for each signing process
• Completed PDF download and audit retrieval on the same account credits as web and agents

5. Operational controls

• Upload size limits and basic abuse controls on the control plane
• Credit metering so automated clients cannot silently skip billing for completed signatures
• Plugin and admin surfaces gated by authenticated roles
• Production secrets and provider credentials handled under product encryption / host contracts — not embedded in client bundles

6. Service providers

We rely on managed infrastructure for hosting, object storage, databases, email delivery, and (when enabled) payments. Provider access is limited to what is needed for the service they perform. Categories are listed in our sub-processor registry draft; vendor names are finalized as production topology stabilizes.

7. What we do not claim

Unless separately certified and listed here, we do not claim SOC 2, ISO 27001, FedRAMP, or similar third-party attestations. We will not invent certifications in marketing or sales decks.

We provide simple electronic signatures (SES) for ordinary business use only.

We do not claim Advanced Electronic Signatures (AES) as a current product: platform keys plus email OTP do not put signature-creation data under the signer’s sole control.

We do not provide Qualified Electronic Signatures (QES), are not a Qualified Trust Service Provider, and do not operate a QSCD. QES is not supported and requires QTSP accreditation and qualified devices we do not operate.

CA-anchored certificates or stronger auth, if offered later, improve process or viewer UX — they do not by themselves create AES or QES.

8. Your responsibilities

Security is shared. You remain responsible for how you use the product:

1. Protect account passwords and workspace API keys; rotate keys if exposed
2. Do not embed long-lived keys in public client-side code or public repositories
3. Verify signer email addresses before high-stakes sends
4. Configure webhooks and agent integrations with least privilege
5. Use Enterprise terms when you need contractual security addenda, DPAs, or volume controls

9. Vulnerability reports

Report suspected security issues through the contact channels on pdfservice.ai (or the security contact we publish for coordinated disclosure). Do not post sensitive exploit details in public forums before we have a reasonable chance to investigate.

Related documents: Legal hub, Terms of Service, Privacy Policy.