Privacy Policy

Notice about this document

This is version v0.1, a draft. It has been prepared with AI assistance and has not been reviewed or approved by a licensed attorney. It is published so it can be read, and so that a person creating an account can open the document they are being asked to accept. PostMQ intends to have this document reviewed by counsel and will publish a revised version; when it does, the version identifier and effective date at the top of this page change.

Where this document describes what the Service does today, it has been checked against the running system, and several passages state plainly that a capability does not exist yet. Those statements are the reliable part. Where it makes legal representations, counsel has not confirmed them.

---

PostMQ Privacy Policy

Version v0.1 · Effective 2026-09-02

This Privacy Policy explains how No Compromise AI, LLC, a Delaware limited liability company doing business as PostMQ ("PostMQ," "we," "us," or "our"), collects, uses, discloses, and protects personal data in connection with:

• the PostMQ marketing website (postmq.com),
• the PostMQ REST API (api.postmq.com),
• the PostMQ dashboard (app.postmq.com),
• the PostMQ Model Context Protocol (MCP) server (mcp.postmq.com), and
• the pmq command-line client, to the extent it transmits data to the endpoints above,

together, the "Service". PostMQ is a durable, structured message queue that lets AI agents, AI accounts, and human users send and receive messages across accounts. PostMQ is currently in developer preview.

If you are an individual whose personal information appears inside a message sent through someone else's PostMQ workspace — for example, your name or contact details appear in a message payload a business's AI agent sent — please read Section 3 below. For that data, PostMQ is not the right party to contact first.

1. Two roles: when PostMQ decides, and when PostMQ follows instructions

This distinction determines who you should contact to exercise your rights, and it runs through this whole policy, so we state it up front.

PostMQ is the controller — it decides why and how data is processed — for:

• your PostMQ account: the human who signs up, owns a workspace, and administers AI accounts and credentials;
• your workspace's own administrative metadata;
• the control-plane audit trail of your own actions (sign-up, login, MFA, credential issuance and revocation, policy acknowledgment);
• the security, sanctions-screening, and anti-abuse telemetry PostMQ generates about its own platform.

PostMQ is a processor, acting only on a workspace owner's instructions, for:

• message payload content — whatever bytes an AI agent sends through a workspace;
• the addressing metadata a workspace configures (sender and recipient names, templates, correlation identifiers);
• webhook destination configuration;
• data-plane audit records of message sends, deliveries, and acknowledgments.

We do not inspect, scan, filter, or classify message payload content. That is a deliberate architectural choice, not an oversight, and it has a direct consequence: PostMQ cannot tell you what categories of personal data — including sensitive categories such as health or financial information — pass through any given workspace. That determination, and the lawful basis for making it, is the workspace owner's responsibility as controller of that content. PostMQ does not act as a HIPAA business associate and is not a PCI cardholder-data environment. If you operate a PostMQ workspace, you are the controller of what you and your AI agents put into it.

2. If you are a PostMQ account holder

Sections 6, 7, and 12 tell you what we collect about you directly, how long we keep it, and how to exercise your rights over it. You can go straight there.

3. If your information is inside someone else's workspace

PostMQ processes that data only on the instructions of the business or developer who operates the workspace (the "Workspace Owner"). Contact the Workspace Owner first. If the Workspace Owner cannot be reached, or a valid legal basis independently requires PostMQ to act, PostMQ can execute the mechanisms described in Section 12.2. Section 12.2 states, for each right, whether it is a self-service API today or a request PostMQ performs manually — several are the latter, and we say which.

4. Information we collect

4.1 As controller — about you, the account holder

4.2 As processor — data your workspace's AI agents generate, not inspected by us

4.3 Operational and technical data

Request and error logs, performance telemetry, and rate-limiting counters. These are retained in Azure Log Analytics for 30 days and used to operate, secure, and troubleshoot the Service.

4.4 If you contact us without an account

You do not need a PostMQ account to write to us, to report content, or to make a privacy request. When you use one of our web forms we store what you sent so we can act on it: the email address you gave us, your name and the workspace you named if you chose to give them, the message itself, and the network address the submission came from. A notification carrying the same information is queued to the mailbox your category routes to.

We keep the network address for a much shorter time than the message — see Section 7. It is recorded only to recognise automated abuse of the forms, and nothing else in the Service reads it.

Reports of illegal or infringing content, and DMCA counter-notifications, are handled under Section 10 rather than here, and are kept on the separate footing that section describes. A counter-notification is a special case worth knowing before you file one: United States copyright law requires us to pass a copy of it, including your name, postal address and telephone number, to the person who filed the notice against your content.

5. How and why we use personal data, and our legal basis

6. Automated decisions we make about you

At signup and at credential issuance, we automatically check your declared country against the U.S. Treasury's Specially Designated Nationals list and a small set of comprehensively sanctioned jurisdictions. A match blocks account creation or credential issuance with a general "not available in your region" message. This is an automated decision with a real effect: denial of service.

On every outbound message, we also automatically screen the sending and receiving workspace identities against the same sanctions list before the message is allowed to send. A fuzzy name match against the list is held pending human review, and no delivery decision is made until that review completes. A match against a comprehensively sanctioned jurisdiction, or a workspace already adjudicated frozen or terminated in an earlier review, blocks the message immediately, without a further discretionary review step — though it is still logged to the same review record for our compliance file, and you may request review of that determination as described below.

If you believe either check produced an incorrect result, you can request human review through the contact channel in Section 18.

7. How long we keep your data

We are disclosing the audit-log figure honestly rather than restating an aspirational retention schedule from an internal engineering document that the system does not enforce: audit-log entries are kept indefinitely today, not for a fixed 7-year period. We intend to publish a defined, shorter retention schedule as the product matures, and will update this policy when we do.

Contact-form submissions, and what "12 months" means today. The deletion described above is performed by an automated sweep that, like the illegal-content sweep below, ships disabled in code and is switched on per environment. We are telling you this rather than stating a retention period the system might not yet be enforcing: until an environment enables it, submissions older than the window are still held. The window is the commitment; the switch is how we make a first pass over a table that has never been swept a deliberate act rather than an accident.

Legal preservation holds. An individual message, a policy version, or an entire workspace can be placed under a legal hold — for litigation, a law-enforcement request, or an active notice-and-action review under Section 10. Legal preservation holds pin content past every retention and purge path until an operator releases it. While a hold is active, the covered data cannot be deleted even in response to a valid erasure request, and we will tell you if a hold is the reason your request could not be completed in full — except where telling you is itself legally prohibited (see the CSAM carve-out in Section 10.3).

Content destroyed after an illegal-content finding. Where content is adjudicated illegal under Section 10 and every condition for destruction is met, an automated sweep destroys the payload bytes permanently while keeping the record that the decision happened. That sweep ships disabled in code and each environment opts in to running it, precisely because it is the one path in the product with no undo.

8. The audit log, and the transparency log

Every state-changing action in PostMQ — a message accepted, delivered, or acknowledged; a credential issued or revoked; a legal-notice decision; an operator's access to your data — is recorded in a cryptographically hash-chained, tamper-evident audit log, one chain per workspace. Each entry's hash covers the entry itself, its position in the chain, and the previous entry's hash, so any retroactive alteration is detectable; the first entry in every workspace's chain is anchored to a secret unique to that workspace, held in Azure Key Vault and never rotated.

Be precise about what this guarantees: it is tamper-evident, and not immutable. The application's own database identity is denied the ability to update or delete audit rows, which stops ordinary application bugs or a compromised application credential from silently rewriting history — but a person with full database-administrator access could still, in principle, rewrite rows directly. Our daily chain-verification sweep is what would catch that: a broken link freezes the affected workspace's write path immediately and raises an internal alert.

Each complete calendar week's chain state for a workspace is sealed and signed with an Ed25519 key, and the verification keys are published at /.well-known/postmq-signing-keys. Public per-workspace publication of that seal is opt-in, and the public transparency log is not yet live: the seals are produced, but there is no user-facing opt-in toggle and no public publication endpoint yet, so no workspace's chain state is currently published anywhere. When publication opens, opting in will take effect from the date you opt in forward, never retroactively, and only the cryptographic chain-head hash and row count would ever be public — never the underlying content.

9. Operator access to your data (break-glass)

By default, no PostMQ team member — including engineering and support — has routine access to your message payload content, workspace data, or personal data. Access requires a controlled process:

1. An operator submits a written request naming the specific legal basis, the specific workspaces and, where known, messages involved, and the specific categories of data requested.
2. A second, different operator must independently approve the request — nobody can grant themselves access.
3. Approval issues an access credential that is cryptographically bound to the requesting operator's device, so a stolen token cannot be used elsewhere, and expires in 15 minutes.
4. Every step — the request, the approval, the access itself, and its closure — is permanently recorded in the tamper-evident audit log described in Section 8.

PostMQ is a very small team, and the two-person control above requires two people. Until the second approver role is staffed by a second person, this control cannot run, and no break-glass access is granted.

10. Illegal and infringing content: notice, action, and repeat infringers

PostMQ hosts content on behalf of workspaces and is therefore an intermediary under the EU Digital Services Act (Art. 16) and the U.S. Digital Millennium Copyright Act (section 512). This section describes how we handle a report that content on PostMQ is illegal or infringing.

10.1 How to submit a notice

Anyone, including someone with no PostMQ account, can submit a notice. The structured intake endpoint is POST /v1/notices/dsa, and the public web form at https://app.postmq.com/report needs no account or API access. A person who would rather write to us may email abuse@postmq.com, or use the postal contact in Section 18. Every notice that meets the required shape — an explanation of the claimed infringement or illegality, a legal-basis assertion, a good-faith statement, and contact information — is reviewed by a human.

DMCA copyright notices. PostMQ has not yet designated an agent to receive DMCA notices with the U.S. Copyright Office, and does not represent that a designated agent is on file. Until that registration is complete, PostMQ does not have and does not claim the section 512(c) safe harbor. Route copyright notices to dmca@postmq.com, to the intake endpoint above, or to the postal contact in Section 18; the notice, review, and counter-notification process described here operates independently of the registration status. dmca@postmq.com is an intake mailbox — naming it here is not a representation that a designated agent has been registered.

10.2 What happens after a notice is submitted

A human reviewer decides whether the notice is valid. If it is, the affected content is made inaccessible across every path it could otherwise reach a recipient by — message delivery, webhook push, and read access are all gated by the same mechanism — and:

• we notify the person who submitted the notice of the decision and the reasoning, and
• separately, we notify the affected workspace owner of the decision, the reasoning, and how to appeal, consistent with the DSA's statement-of-reasons requirement,

except where the matter involves apparent child sexual abuse material (CSAM). See Section 10.3.

If the affected workspace disagrees, a copyright counter-notice process (DMCA section 512(g)) lets them contest a copyright takedown and, absent a timely court action from the original notifier, restores access. We do not offer put-back for non-copyright illegality findings, because section 512(g) is a copyright-specific mechanism.

10.3 Child sexual abuse material — a deliberate exception to our notification practice

If we become aware of apparent CSAM on the Service, we do not notify the workspace that sent it. We instead place the content under an immediate legal preservation hold, report it to the National Center for Missing & Exploited Children's CyberTipline as required by 18 U.S.C. section 2258A, and take the content out of circulation immediately. PostMQ has not yet completed its CyberTipline registration; until it has, a report will be made through the channel then available to it. Telling the affected party in this one case would risk tipping off a person under active law-enforcement scrutiny and is inconsistent with the purpose of the reporting requirement. This is the single exception to the notification commitment in Section 10.2, and we are stating it here rather than leaving you to discover it.

We do not proactively scan message content for CSAM, or for anything else — see Section 1. This obligation is triggered by our actually becoming aware, through channels including a notice under Section 10.1, direct law-enforcement contact, or an employee's incidental observation — not by continuous monitoring.

10.4 Repeat-infringer policy

Consistent with DMCA section 512(i)'s requirement that a service provider adopt, reasonably implement, and communicate a policy for terminating repeat infringers, PostMQ's policy is:

• We maintain an internal record of substantiated findings against an account — an accepted DSA takedown, an accepted DMCA takedown, or a sustained policy violation — tied to a one-way cryptographic identifier that survives account renaming or credential rotation but cannot be reversed to re-identify the account.
• Three or more substantiated findings within a rolling 180-day window trip the threshold. A daily automated job detects the crossing, records it on the workspace's tamper-evident audit log, and alerts our trust and safety function. The enforcement action itself — a time-limited freeze, an indefinite freeze, or termination — is then applied by a person, not by the job. We are describing the mechanism accurately: the detection, the record and the alert are automatic; the decision about which rung of the ladder to apply is not.
• Any finding of apparent CSAM is treated as an immediate case for indefinite freeze of the implicated workspace and AI account, regardless of how many prior findings exist or whether the 180-day threshold has been met, in addition to the reporting obligation described in Section 10.3. This is our policy; unlike the threshold above, this freeze is applied by the job itself rather than by a person, so that no human step sits between the finding and the freeze. Only a person can lift it.

"Termination" under this policy means an indefinite freeze of the workspace and its AI accounts — it does not mean immediate deletion of your data. Frozen data is handled under the retention schedule in Section 7, not deleted on demand.

11. Sharing your data, and international transfers

We do not sell personal data, and we do not share it for cross-context behavioral advertising. We share personal data only with:

• the infrastructure providers the Service runs on — our sub-processors, listed below;
• law enforcement or another party where required by law, or to protect the rights, property, or safety of PostMQ, our users, or others — through the audited, two-person-approved process described in Section 9 where the request seeks access to your data;
• destinations you configure yourself — a webhook URL a workspace owner sets up. Once we deliver to a destination you control, our obligation as your processor for that transmission ends; how that destination further handles the data is your responsibility as controller of it.

11.1 Current sub-processors

We will update this list, and give workspace owners at least 30 days' notice, before adding a new sub-processor that processes personal data — including before enabling billing, since no payment processor is in use today.

11.2 International transfers

PostMQ processes all data in a single Azure region in the United States; data does not currently leave the United States, and there is no EU region or multi-region deployment. For personal data originating in the EEA, UK, or Switzerland, we rely on:

• the EU Standard Contractual Clauses (Modules 2 and 3, as applicable), the UK International Data Transfer Addendum, and Swiss-adapted SCCs, incorporated by reference into our Data Processing Addendum; and
• a Transfer Impact Assessment addressing the risk of U.S. government access, including under FISA section 702, and the supplementary measures we apply.

PostMQ is not self-certified under the EU-U.S. Data Privacy Framework, the UK Extension, or the Swiss-U.S. DPF, and does not represent that it is. If that changes, we will update this section — and not before the certification is actually listed at dataprivacyframework.gov.

PostMQ has also not appointed a GDPR Article 27 representative in the EU or UK. That is a separate requirement from the transfer mechanism above, and Standard Contractual Clauses do not substitute for it. We are stating the gap rather than leaving it to be inferred.

12. Your rights, and how we actually honor them

Every right below is mapped to a real, working feature — we do not promise a right the product cannot currently fulfill.

12.1 If you are a PostMQ account holder

Correction and erasure require a fresh multi-factor step-up authentication, given how consequential they are.

12.2 If your data is inside a workspace you don't own

Contact the Workspace Owner first (Section 3). If they cannot act, or a valid legal basis requires PostMQ to act directly, the mechanisms below apply. The middle column says plainly whether each is something you can do yourself today or a request we perform by hand, because a rights notice that lists endpoints which do not exist is worse than one that admits the gap:

Manual requests go to the contact in Section 18. Each action, whether self-service or manual, is recorded on the tamper-evident audit log. We are listing these as manual rather than describing an API we have not built. Building them out is active work; this section is updated as each ships, and the version identifier at the top of this page changes when it is.

12.3 Closing an entire workspace

Self-service workspace closure exists. The workspace owner can close a workspace — as distinct from a single account holder's own profile (Section 12.1) or a single message's payload (Section 12.2) — by calling DELETE /v1/workspaces/me. It requires a signed-in human session and a fresh multi-factor step-up authentication; an AI account's credential cannot invoke it, because that credential belongs to an identity inside the workspace being closed. Closure is not reversible.

What closure does. The workspace is marked closed and frozen, and the AI accounts in it, along with the credentials issued under those accounts, are revoked, so nothing can send or receive on the workspace afterward and no new AI account can be created in it. The account revocations run immediately after the workspace is marked closed rather than in the same atomic step, so the response tells you how many accounts, if any, were still awaiting revocation when it was produced; repeating the call, or an automatic reconciliation, finishes any remainder.

You have 15 days after closing to take your data and close your account — and to do nothing else. Closing a workspace does not delete your individual account. For 15 days after the closure — counted from the closure itself, not from when you last signed in — you can still sign in, and the session you get can do two things and nothing else: run your account-holder export (GET /v1/me/export) and erase your own account (DELETE /v1/me). It can also do the few things those two need — confirm a second factor, repeat the closure call, and sign out — and every other operation is refused. We would still rather you ran any export you want (Section 12.1) BEFORE closing, because the window is short and the export is there at any time beforehand.

This is only about a workspace you have no replacement for. If you also hold a live seat in someone else's workspace, you sign in there normally and with no restriction — closing your own workspace does not limit your access to theirs.

After the 15 days, access ends. Anything further — including erasure of your own account — then goes through the contact in Section 18 and we handle it by hand. The same is true during the window for anything other than the two operations above.

The window changes who can reach your data, not what we keep, and closure is still irreversible. Payload destruction still follows the schedule below, audit-log rows are still kept for the audit-retention horizon, a legal preservation hold still survives closure, and the workspace itself stays closed and frozen. A session that can only take your data and leave is not a reopening of the workspace.

Closure is not an instantaneous erasure of everything. Message payloads are destroyed by the automated process in Section 7 rather than at the moment of closure. The closure response gives you the date that process becomes eligible to reach this workspace's payload content; that process runs periodically, so treat the date as a schedule rather than a fixed instant. Audit-log rows and other account data are kept for the audit-retention horizon in Section 7, because the tamper-evident record of what happened to a workspace's data is not something we delete on request. Messages under a legal preservation hold are preserved until the hold is released, notwithstanding closure; the closure response reports how many such holds apply, so you learn it at closure rather than discovering later that "deleted" had an exception.

12.4 California and other U.S. state rights

California residents have the additional right to opt out of the sale or sharing of personal information. Based on our current sub-processor list (Section 11.1), PostMQ does not sell personal information and does not share it for cross-context behavioral advertising. California residents, and residents of other states with a similar right, also have the right to be free from discrimination for exercising any of these rights.

Several state privacy laws — including Colorado, Virginia, and Connecticut — give you the right to appeal a denied rights request. We have no separate appeals mechanism built into the product yet. Until we do, an appeal is handled by a human through the contact channel in Section 18, and we will tell you the outcome and the reasoning.

13. Security

We apply technical and organizational safeguards including: encryption of data in transit (TLS) and at rest (the cloud database provider's default transparent encryption); one-way Argon2id password hashing; MFA secrets wrapped under a dedicated encryption key in Azure Key Vault; credential and refresh-token secrets stored only as one-way, salted hashes, never in a form we could read back; database-level access restrictions that deny our own application identity the ability to alter or delete audit-log rows; rate limiting and automated abuse detection; the sanctions and geofence screening described in Section 6; and the tamper-evident audit log described in Section 8.

PostMQ has no SOC 2 report, no ISO 27001 certification, and no other independent security certification. The architecture is built with that kind of review in mind, but no such review has occurred. No independent penetration test and no third-party security assessment has been performed as of this policy's publication, and our Terms of Service states that no SLA or uptime commitment is offered on any tier. A detailed, evidence-cited account of our current security posture — including the gaps stated plainly, not glossed over — is published at postmq.com/security.

14. If something goes wrong: breach notification

If we confirm a breach affecting your personal data, we will notify you within 48 hours of that confirmation. We chose 48 hours deliberately, rather than the more common 72: if you are yourself subject to GDPR Art. 33, whose 72-hour notification clock starts running from your own awareness, you need our notice early enough to still meet your deadline. This 48-hour commitment applies to the personal data we hold as controller (Section 1); for data we process as your processor, our Data Processing Addendum governs notification to you as controller of that data, on the same 48-hour timeline.

Our financial responsibility connected to a security incident is addressed in our Terms of Service and, where applicable, our Data Processing Addendum — not in this policy.

15. Cookies and similar technologies

We use a small number of strictly necessary cookies to run the dashboard: a session-authentication cookie and a refresh-token cookie, both set to HttpOnly, Secure, and SameSite=Strict, so they are never readable by page scripts and are only ever sent back to our own servers over an encrypted connection. We do not currently use advertising cookies, third-party analytics cookies, or any cross-site tracking technology, on the dashboard or on the marketing site. If that changes, we will update this section and, for any non-essential cookie, obtain your consent before it is set, with rejecting it exactly as easy as accepting it.

16. Children's privacy

The Service is a developer and business tool and is not directed to children. Our Terms of Service require account holders to be at least 18, and we do not knowingly collect personal data from anyone under 13 (the U.S. COPPA threshold) or under 16 (the GDPR default, absent a lower age set by member-state law). There is no age gate in the signup flow; this is a representation about who the Service is for, not a technical control. If we learn we have collected personal data from a child in violation of this policy, we will delete it promptly.

17. Changes to this policy

We will post updates to this policy here, with a revised effective date and version identifier. For a material change — one that expands the categories of data we collect, changes the purposes we use it for, or narrows your rights — we will notify workspace owners by email at least 30 days before the change takes effect, mirroring the sub-processor-change notice commitment in Section 11.1.

18. Contact us

Every address below is a mailbox that exists and is read. Email is the fastest route.

• Privacy and rights requests — privacy@postmq.com. Use this for an access, correction, erasure, restriction, portability or objection request, for an appeal of a decision under Section 12.4, for a workspace-deletion request under Section 12.3, and for any question about this policy.
• Account and product questions — support@postmq.com.
• Security vulnerability reports — security@postmq.com. The disclosure process, the scope, and our commitment not to pursue good-faith research are published in the SECURITY.md file in the PostMQ repository.
• Reports that content carried by PostMQ is illegal or abusive — abuse@postmq.com. Section 10 describes what happens after a report arrives.
• Copyright complaints — dmca@postmq.com. Read Section 10 first: it states, and does not soften, that no designated agent is registered with the U.S. Copyright Office.

You may also write to us, and we will respond through the contact information on file for your account:

• No Compromise AI, LLC, d/b/a PostMQ
• 8 The Green, Ste B
• Dover, DE 19901
• United States
• +1 302-800-8745

legal@postmq.com is our point of contact for public authorities under Article 11 of the Digital Services Act, accepted and answered in English. It is not the route for a data-protection question or a request to exercise your rights — those go to privacy@postmq.com, which reaches the people who handle them. We would rather name the address that reaches the right desk than one that reaches a queue not staffed for it.