PostMQ keeps a governed record of what your AI coding agents decided and did. This page is the buyer's half of that: the units you administer, the boundaries you inherit, the things that are genuinely not built — there is no SAML, no SCIM and no directory sync — and the short list of what a security reviewer can verify today without asking us for anything. The argument for governance by record is on its own page; this one assumes you have read it or will.
Before procurement asks
the four answers that decide itCertificates: none. No SOC 2, no ISO certificate, no third-party audit, no SLA.
People: an owner plus anyone they invite. No SAML, no SCIM.
Residency: Microsoft Azure, United States, single region.
Proof: a questionnaire answered from the code, published with its commit.
stated first · the same list the security page carries
An enterprise evaluation is rarely one person. These are the three who actually decide it, and the thing each of them is trying to settle.
The reason this page is separate from the rest of the site is that the rest of the site answers "what does it do". An organisation is asking something narrower and less flattering: what am I taking on. Every hosted service has a set of things it quietly assumes you will not ask about until the contract stage, and the difference between a good evaluation and a wasted month is whether those things are written down before you start. So they are written down here, in their own section, ahead of the capabilities.
The second reason is that a security reviewer and a CTO want different objects. The reviewer wants a file name and a test name and a commit they can clone. The CTO wants to know whether the record survives the session and what it costs to look. Both are served by the same underlying thing — a record the agent writes as it works, chained and re-verified — but they arrive at it from opposite ends, and a page that pitched only one of them would lose the other.
The third reason is that we would rather lose an evaluation early than late. There are requirements this product does not meet today, and they are not hidden behind a form: data residency outside the United States, more than one person in a workspace, keys you hold yourself, a signed availability commitment. If one of those is a hard requirement, the honest thing is for you to find that out on this page rather than in week three.
You have agents opening branches and closing pull requests, and a board question about who decided what. You are not shopping for a control plane; you want to know whether the work leaves a record that survives the session, and what it costs to find out. Ten minutes here, then the governance argument in full.
You verify rather than read. Every mechanism on this site names the file or the test that makes it true, and the vendor questionnaire answers 61 questions from the code with the commit they were read at — so you can clone that commit and check the answer rather than believe it.
You are the person who will actually put this in front of procurement. The honest position is that there is no certificate to hand over and no signed commitment to point at yet — what there is instead is a published floor price, a questionnaire answered in the open, and a list of gaps we wrote ourselves.
Four objects, and each is the thing you actually operate rather than a benefit statement about it.
A workspace is the unit you buy, the unit you are isolated by, and the unit the record is kept in. It is read off the presented credential at authentication and stamped as a claim — never supplied by a caller — and tenant rows are physically partitioned on a per-workspace hash with the workspace id leading the primary key. The lock-ordering tests include cross-key cases that fail if a locking read ever scans instead of seeking.
Each agent is its own identity inside the workspace, with its own scoped, once-disclosed credential, so attribution is per-agent rather than per-human-who-ran-it. 19 issuable scopes across an operational tier capped at 365 days and an administrative tier capped at 90; the plaintext is shown once at issue and stored as a keyed hash, so a client that loses it rotates. Revoking an account revokes its credentials.
A credential carries the scopes it was issued and no others, every mutating route and tool is scope-gated, and the operator scope cannot be issued over the API at all. An agent that only files decisions gets a credential that can only file decisions — there is no ambient workspace-wide token to hand around.
People use the dashboard; agents use MCP or the versioned REST API under /v1. All three run the same service layer, and for every session-state aggregate REST and MCP are tested byte-identical — so what your reviewer reads in the dashboard is what your audit script pulls, not a second rendering of it.
What those four buy you together is attribution that does not depend on anyone being honest about it. The workspace and the acting identity are both read off the presented credential server-side, on every call, so a record cannot claim to have been written by someone else; the credential is scoped, so an agent's blast radius is the set of scopes somebody deliberately issued it; and the ledgers are readable through the same service layer whether a person or a script is asking. The governance argument for why that is the right shape — and, just as importantly, what it deliberately does not do — is on the AI coding governance page.
Every row was read in the code on the date at the foot of this page. A row with a caveat carries the caveat in the row, and the footnote is the register id it rests on.
| what holds | how | scope |
|---|---|---|
| A workspace has one owner and any number of invited membersC128no SAML and no SCIM: you invite people one at a time and remove them one at a time, and nothing syncs from your directory. Email addresses are unverified at signup. The operator tier is a platform role held by us, never a role assigned inside your workspace | The owner invites by email; the person accepts with their own PostMQ account, and can be removed at any time, which ends their access on their next request. A member sees the workspace’s agents, messages and audit log by default and can act in it, and everyone invited is a member — the account owner is the only human who can invite, remove, or change the workspace itself. Invitations are single-use, expire, and admit only a human whose ACCOUNT email matches the address they were sent to — note that PostMQ does not yet verify an email at signup, so that match proves the address was reachable by whoever registered it, not that it belongs to them | shipped |
| Sign-in is Microsoft Entra ID or passwordC39no SAML and no SCIM, no customer-configurable identity provider per workspace, and no workspace-level requirement that everyone use it | Entra ID (OIDC) is built and configuration-gated — the verifier reports itself configured only when both an authority and a client id are present, and the sign-in page renders no button for a provider with no verifier behind it. Password sign-in carries a TOTP second factor and single-use recovery codes | shipped with caveat |
| The break-glass lifecycle is on the chain, but withheld from your viewC127we volunteer this rather than wait to be asked; it is in the not-yet list below and on the security page, and the sentence is pinned to the code so it cannot outlive the gap | When we need to reach one of your messages, the request, the approval and the close each append a row to the tamper-evident chain, in the same transaction as the restricted operator table they also write (so a rollback drops both). But those three rows are operator-significant and withheld from your own audit view: you do not learn from your log that break-glass was opened over you — the record lives on the chain and the restricted operator tables, for the integrity sweep and the transparency log. The override they authorise IS visible to you: forcing an acknowledgement appends a row to your workspace’s own chain, so you see that an operator acted, and not which operator | shipped with caveat |
| Retention is one number for everybodyC123a custom retention window is part of the Enterprise tier description on the pricing page, not something the product can do today. Enterprise carries no history window at all, so nothing on this tier is bounded by one | Message payloads and their personal data are anonymised 30 days past acceptance unless a legal preservation hold covers the row. Thirty days is a compile-time constant, identical for every workspace — there is no per-workspace retention window to negotiate. Separately, the tier history windows on the pricing page are now read by the product: they bound how far back a read reaches, and they delete nothing | shipped with caveat |
| Getting the record out means paging the API, inside your tier history windowC123the window bounds the read, never the stored row: nothing is deleted, and a longer window brings the older rows straight back. Enterprise has no window. A scheduled export is roadmap; do not mistake GET /v1/me/export for it — that is the data-portability export for a person and carries their profile, owned workspaces and account metadata, not the work record | Every ledger — build sessions, decisions, backlog, lessons, rules, usage and the audit log — is readable over the versioned /v1 REST routes and the MCP query tools, keyset-paged, so a script can pull it this afternoon. On a tier with a history window, the chronological ledgers stop at that window, and each response says so in a history_window field rather than quietly returning less. There is no one-click ledger export and no export button in the dashboard | shipped with caveat |
| Data rights are REST onlyC43there is no dashboard page and no MCP tool for any of it | Access, portability, rectification and erasure of the account holder’s own data are self-service over REST. Erasure needs a fresh MFA step-up and, in one transaction, soft-deletes the human, freezes the workspace and destroys the salt that could re-identify them | shipped with caveat |
| One region, and no keys of your ownC45no EU option, no multi-region and no zone redundancy; no customer-managed keys and no private endpoints | Hosted in Microsoft Azure, United States, a single region: Container Apps, Azure SQL, Key Vault, Storage and Log Analytics. Secrets are held in Key Vault and read with managed identity, and the core secrets are force-resolved at boot so a missing value fails the deployment rather than your first request | shipped with caveat |
| The compliance suite is built, and it is ours to operateC41these are platform obligations we discharge — the notice and sanctions decisions under a designated-operator check, a live human session and a fresh MFA step-up; the message-level overrides they authorise present a break-glass DPoP token and carry no session of their own — they are not a console you are given | Notice-and-action for DSA Article 16 and DMCA runs end to end — public intake, an operator decision with a stated reason, counter-notice, the §512(g) court-action block and a sweep that performs the put-back; a takedown disables access on all three paths content can leave by, reversibly, which is what makes put-back restorable. Every send is screened against OFAC’s SDN list, fail-closed. Legal preservation holds pin content past every retention and purge path until an operator releases it, and the one path that destroys content with no undo ships disabled in code so each environment opts in | shipped |
| Your view of the chain shows verdicts, not hashesC131public publication is opt-in, toggled from the dashboard, and what it publishes is substantially a commitment record — one audited event type’s content plus the week’s hashes; the sealed artefact has no customer retrieval route at all today, and no verifier tool ships — your reviewer writes the script | The three workspace-facing audit-log surfaces return the rows and the integrity sweep’s per-row verdict, and deliberately carry no row hash and no previous-row hash — the read model does not hold those columns. Re-deriving a link yourself is done from the transparency artefact — and in general only from the workspace-private sealed one, which carries every row’s canonical bytes beside its hashes. The public artefact carries the bytes for only one individually audited event type and the hashes alone for every other line | shipped with caveat |
Not assurances — checks, with their limits stated in the same breath. Two of these need nothing from us at all; the other four have caveats we would rather you read here than discover.
61 questions in 11 groups, answered from the code and published with the version and the commit the answers were read at.
Clone that commit and check an answer rather than believe it. A build guard fails the required check if any cited path or test does not exist, if the commit is not an ancestor of the checkout, or if an answer opens with a hedge. Read it before anything else on this page.
The dashboard Audit log page, the versioned REST route and an MCP tool the agent itself can call return the rows and the integrity sweep's per-row verdict, and no hash columns at all.
Read this one carefully, because it is the opposite of what a trust page usually implies. Those three surfaces deliberately carry no row hash and no previous-row hash — the read model does not hold the columns, so the serialiser could not emit them if asked. The reasoning is in the code: eyeballing a hash chain in a table is not verification, and offering it invites a reader to believe it is. What you get instead is the verifier's verdict. Also know what is withheld and why: the operator-significant families — notices, sanctions, standing findings, preservation holds, data-subject requests and anonymisation — are not shown, because disclosing a legal-process row to the party it concerns would defeat the process.
Every line carries its sequence, its previous hash and its row hash, so the chain walks to the signed head either way. Whether the line also carries the row's canonical bytes — the part you re-canonicalise and re-hash — depends on which artefact you hold.
Read the distinction, because it is the difference between two quite different documents. The sealed artefact — your own workspace's copy, in a private container — carries the canonical bytes of every row, so every link is re-derivable. The public artefact deliberately carries row content for only a short, individually audited list of event types — today one, and it is about your own workspace's handling of its own messages. Every other line publishes its sequence and its two hashes with the content withheld. So a public reader can walk that chain to the signed head and confirm we have committed to it — a commitment record. Be precise about what that is worth, because it is less than it sounds: the hashes still check against each other and against the signed head, but with the content withheld none of them can be checked against what it summarises — so the reader is verifying our commitment to a history rather than the history itself. It binds us — we cannot later tell a different story about that week without contradicting a signature we already published — but on its own it does not demonstrate the log is complete. Checking that needs the row content, which only the sealed artefact carries. Three caveats we would rather you read here. Per-workspace public publication is opt-in, switched on by the workspace owner from the dashboard's workspace transparency page (or the matching API route) and never on by default. No verifier ships — there is no command in the CLI that checks a chain, so your reviewer writes the canonicalisation and SHA-256 script themselves. And because a withheld row's hash cannot be re-derived, the blob's own digest is separately signed; that signature is what authenticates the bytes, and a verifier must require it rather than treat it as optional.
Opting a workspace into public transparency publication publishes the integrity chain plus the content of one individually audited event type. It does not publish your people's sign-in history, or anyone else's identifiers.
The gate is an allowlist of individual event types — not whole families — whose content may go to an anonymous host, and it holds exactly one: the moment a consumer in your workspace leases one of its own messages. Everything else stays withheld, including a type nobody has considered and a type added years from now, without anyone remembering the file exists. That one was admitted on measurement, not caution: it was read at the code that emits it and confirmed to sit on the chain of the workspace it is about and to carry nothing chosen by anyone but that workspace. A second candidate was dropped during the audit — the message-expiry event embeds the sender's chosen expiry time, which is a counterparty writing into your public record. The obvious wider candidate — the whole message plane — failed both checks. It publishes consumer-supplied free text outright; and its accept event reads the sender's account and credential ids rather than the ids of the chain it is written to. Those are the same workspace today, and only because a routing check makes them so. Admitting it would therefore rest a permanent, unwithdrawable disclosure on that check continuing to hold — which is not a thing we are willing to rest it on, whatever the routing rules say now. Publication cannot be undone; a week already published stays published. So the list grows one audited type at a time, and never a family at a time.
A plain SHA-256 over the canonical row, its big-endian sequence number and the previous row's hash — no key is an input, and there is no per-workspace chain key.
Why the arithmetic above is checkable at all: every link from row 2 onward depends on nothing secret, so whoever holds the rows and their hashes can re-derive it. Only row 1's anchor needs the genesis secret. The application's database identity is denied UPDATE and DELETE on that table, which makes the log tamper-evident and not immutable — a database owner could still rewrite rows, and the daily verifier would then see the break.
Each complete week's chain head is signed with a dedicated key and chained to the prior week's seal; the verification keys are served publicly and unauthenticated.
Fetch the keys without an account — that half needs nothing from us. Getting a seal to check against them is the part that does: a public artefact exists only for a workspace that has opted in, and the sealed artefact has no customer retrieval route today. The signing key is dedicated, separate from the session signing key, so a session-key incident cannot forge an attestation. Scope it correctly: the document carries the transparency-log signing keys only, because enumerating per-workspace webhook keys on one public document would leak the platform's tenant topology.
The reason to lead with checks rather than assurances is that we have nothing else to offer yet, and pretending otherwise would be the one thing that should end this evaluation. More than 4,000 automated tests back the mechanisms named on this page and the integration suites run against real SQL Server containers rather than mocks — but a test count is our word too. Two of the six above need nothing from us: the questionnaire is public and pinned to a commit, and the signing keys are served unauthenticated. The other four are where an enterprise page usually overstates, so read them as written — your own view of the chain shows the verifier's verdict rather than the hashes, on purpose; opting in publishes a public artefact that commits to the whole week's chain while disclosing the content of just one audited event type, so it is not the thing you re-derive the week's arithmetic from; and the sealed artefact that does carry the bytes has no retrieval route we can point you at yet, nor a script we have shipped you.
The same list the security page and the governance page carry, rendered from the same source, so three pages cannot answer this question differently.
Read this before the sections above it, because it is the part that decides most evaluations. There is no SOC 2 report and nothing else has been certified or audited either; there is no SLA on any tier and no figure we would put in one; nothing has been penetration tested on record; and the legal drafts are unsigned, so none of them binds anybody today. Procurement will want a name to write to and there is not one yet. Here is the whole list, unedited:
Two notes on how to read that list. It is not a roadmap in disguise — nothing on it carries a date, because we would rather name a gap than promise a quarter. And it is deliberately the same array the other two pages render, so an edit that softened it in one place would soften it in all three at once and fail a build guard that checks the topics are still named.
What the Enterprise tier is today, in the words the pricing page already uses — and what it is not.
The Enterprise tier carries a published floor on the pricing page rather than an invitation to get in touch, because a price you cannot see is a negotiation you have already lost. Read the two footnotes with it: the allowances on that page describe each tier and the product can now enforce them, but does so only for a workspace deliberately moved to a published tier — and none is today — and the response commitments attach to paid tiers when billing opens. During developer preview nothing is cut off, no tier carries an availability commitment, and every workspace runs on the Developer allowances at no charge.
On starting a conversation, the honest answer is that contact details are on the support page: a form that reaches a person, not a sales organisation — there is no sales team, no quota and no demo to book. Operational mailboxes exist too — security, privacy, abuse and copyright reports each reach a monitored address, published on the security page and in the legal documents — but none of those is a sales channel and this page borrows none of them to look reachable. The two things that are real are the completed security questionnaire, which is public and answered in full, and the product itself, which any workspace can start on today.
This is the evaluation we would ask you to run rather than take our word for anything. Nothing in it is a demo environment; it is your workspace and your data from the second step on.
Start where the gaps are. 61 questions in 11 groups, answered from the code, published with the version and the commit the answers were read at — 35 Yes, 16 Partial, 9 No, 1 Not yet. Every Yes and every Partial names the files, tests or pull requests that make it true, and a build guard fails if a cited path does not exist or an answer opens with a hedge.
postmq.com/security#questionnaire No card field; billing is not open. You get one workspace, owned by you, and the whole protocol — the tiers differ in people, agents, history and support, never in what the protocol can do.
app.postmq.com/signup Create an AI account for one agent and issue it a credential with only the scopes that agent needs. The plaintext is shown once and stored as a keyed hash; if it is lost you rotate rather than recover. Note what you cannot issue: the operator scope is not available over the API at all.
app.postmq.com/ai-accounts Point an MCP client at the server with that credential and let it work. The session records the machine, the branch, the acting agent and the client that opened it; the actor is derived server-side from the credential, so a client cannot assert who it is.
start_build_session Filter the decision log to that session. Nothing there has been edited — a database trigger refuses it — so a change of judgement appears as a correction pointing at the entry it supersedes, with both still present. The backlog shows what it deferred; usage shows the token counts it spent.
app.postmq.com/decision-log Read the same rows three ways — the dashboard Audit log page, the versioned REST route and an MCP tool the agent itself can call — and note what comes back: the rows and the integrity sweep’s per-row verdict, deliberately not the hashes. Then fetch /.well-known/postmq-signing-keys without an account, which needs nothing from us. Re-deriving a link yourself is the one step this walk cannot give you today; it needs the opt-in transparency artefact, and you would write the script.
GET /v1/audit-log Two things to know before you start, so the walk does not mislead. The whole sequence runs on the free Developer allowances, so nothing in it depends on a commercial conversation. And the last step is the one that matters most: verifying a chain link yourself is the difference between believing this page and checking it, and it is arithmetic over rows you already hold rather than an assertion we make. If it fails, that is a finding, and we would want it.
Last verified 2026-08-24 against main at 8e16460: the
workspace owner column, and that no surface can reach the membership service — the schema for a second human
exists, and nothing in the product can yet put one there; the scope catalogue and
the credential lifetime caps; the Entra verifier's configuration gate; the three break-glass services and
the audit event types they do not declare; the retention constant; the human-portability export's documented
scope; the three audit-chain read surfaces and the published signing-key endpoint were each read on that day.
Related: security — the mechanisms, the test names and the questionnaire · governance by record, not by gate — the argument in full · pricing — the Enterprise tier and its footnotes · session state — where attribution comes from · the decision log a trigger makes append-only.
The questionnaire is public and answered from the code, with the commit it was read at. Enterprise contact details are on the support page — and any workspace can start today at no charge.