Agents are making real changes to real codebases, and the answer to “who decided this, when, and on what evidence?” is usually a chat transcript that ended with the session. PostMQ makes that work legible afterwards: sessions attributed to a machine, a branch and an acting agent; decisions in a log a database trigger will not let anyone edit; deferrals triaged; spend in token counts — and every one of those writes chained into a per-workspace SHA-256 audit log. Governance by record, not by gate: it does not block a tool call.
session 01K… · branch feat/site-wp310 · agent:01K…
decisions · backlog · usage · chainappend-only · attributed to the credential · illustrative
Something changed quietly in the last year. An agent no longer suggests a line; it opens a branch, writes a migration, edits a permission check, files a pull request and closes half a dozen of them in a day. That is real work by any definition a board would use, and it is being done by an actor that leaves almost nothing behind. When the question arrives — and it always arrives as a question about a specific change — the honest answer today is that the reasoning existed for a few hours inside a context window and is gone.
The two answers most teams reach for do not survive contact with a reviewer. The first is the transcript: it is enormous, it is unstructured, it lives on one laptop, and it is not the decision — it is everything that happened around the decision, including the three approaches that were abandoned. The second is a conventions file in the repository, and it has the opposite failure: it is durable and it is unread at the moment it matters, because it is loaded whole at the start of a session, before anyone knows which change is coming. Neither is attributed, neither is append-only, and neither can be queried by the next agent.
What a reviewer actually wants is narrow and specific: which agent did this, under which session, what did it decide and why, what did it defer, what did it cost, and can any of that have been changed after the fact. Those are six questions with six answers, and each one is a row in a table somewhere or it is nothing. That is the whole thesis of this page. PostMQ is not a way to stop an agent; it is the place those six answers live, written by the agent as it works and readable by a person who was not there.
Before
what a review turns up todayA pull request with a generated description. A transcript on one machine, if it was not cleared. A conventions file that says what should have happened. No record of what was deferred, no attribution past the commit author, and no way to show that any of it is unedited.
After
what a review turns up hereA session row naming the machine, the branch and the acting agent. Its decisions, append-only, each attributed to a credential. Its deferrals with owners and closing references. Its token counts. And a hash chain over the lot, re-verified daily and sealed weekly.
Not a log the platform scrapes from outside — a record the agent keeps itself, through ordinary tool calls, because keeping it is part of the protocol it runs. Each has its own page; this is what a governance reader needs from each.
A build session is opened by the agent and carries the machine it ran on, the git branch, the worktree, the acting agent identity and the client that opened it — plus the pull requests and commit shas it produced. The same project, computer, branch and actor gets the same session back, so a resumed session is one row rather than two. The actor is derived server-side from the presented credential; a client cannot assert who it is.
A database trigger rejects every delete and every update except the two source links, so a decision cannot be edited out of the record after the fact. A correction is a new entry that points at the one it supersedes, and both stay. Every entry is attributed to the credential that wrote it and linked to the build session that was open at the time.
What a session did not finish is filed rather than forgotten: a title, a body, a priority, an owner and a status the database will not reopen once it is closed. Resolving needs a closing pull request, commit or closing notes; dismissing needs a reason. A persisted staleness clock makes an item that nobody has touched visible as such.
Five token classes and the turn counts, recorded against the session that spent them and rolled up per project, day, week and month. The numbers are self-reported by the client that spent them — PostMQ meters no provider — and they are token counts, never money. Nothing reads the number to stop on it.
The agent describes the change it is about to make — the files, the operation, the language — and gets back only the rules whose every populated trigger dimension matches. Each rule counts how often it has been retrieved and when it was last returned, so a rule nobody ever gets is visible as a rule nobody ever gets.
A lesson advances forward only, and the database refuses to store it as enforced until somebody writes down the prevention mechanism — the sentence that says what now makes the mistake hard to repeat. Be exact about the caveat: the gate is structural, and the human in it is convention. Any credential with the write scope can advance a lesson; what cannot be skipped is writing the mechanism.
Underneath all six sits the same chain. Every session-state lifecycle event — sessions started and ended, decisions appended and corrected, backlog filed, triaged, assigned and reprioritised, lessons and rules created and changed — is written into the same tamper-evident SHA-256 audit chain as messaging: 38 of 123 event types. High-frequency touches such as pings and usage reports are deliberately not audited, which is a design decision rather than an omission: a chain that carried every heartbeat would be a chain nobody reads. The hash and the sequence are computed inside the insert transaction by a serialised stored procedure, so application code never computes either and sixteen concurrent writers cannot fork the chain.
Be precise about the construction, because it is what makes the record checkable by someone who does not
trust us. The row hash is SHA-256 over the canonical row bytes, the big-endian sequence
number and the previous row's hash — a plain digest, with no key as an input, and there is no
per-workspace chain key. The genesis secret in Key Vault keys the chain's anchor: row 1's
previous-hash is derived from the workspace id and that secret. The consequence is the useful part —
every link from row 2 onward can be recomputed from the stored rows alone — no key, and only row 1's
anchor needs the genesis secret. Be equally precise about what that buys you today: the
workspace-facing audit reads deliberately return no row_hash or
previous_row_hash (handing them to a browse UI invites the reader to mistake eyeballing a
chain for verifying one), re-deriving the links needs the transparency artefact, that publication is
opt-in per workspace with no self-service toggle, and no verifier tool ships. The construction is
checkable by someone who does not trust us; the surfaces that would let you check it yourself are not
all built.
The application's database identity is denied UPDATE and DELETE on the audit table, so the running system
can only append. That makes the log tamper-evident by construction and not immutable — a
database owner could still rewrite rows, and the verifier would then see the break. It is re-verified on
a daily schedule; a break or hash mismatch freezes the workspace's write path in the same
transaction and raises an integrity alert event. Each complete week's chain head is
signed with a dedicated key and chained to the prior week's seal, with the verification keys published at
/.well-known/postmq-signing-keys; publishing a workspace's own log publicly is
opt-in, toggled from the dashboard’s workspace transparency page. The mechanisms and the test names
are on the security page.
This section is here because the category it sits in is full of products that do the opposite, and a page that let a reader assume wrongly would be worth less than no page. Four sentences, and none of them is hedged.
None of that is an apology. Runtime interception and after-the-fact attribution are different jobs with different failure modes, and a product that claims both usually does one of them badly. What we will say is the narrow thing that is true: after an agent has worked, you can tell which agent it was, under which session, what it decided and on what reasoning, what it deferred, what it consumed, and whether any of that record has been altered. If your requirement is that a particular tool call never runs, that requirement belongs where it already lives — in your repository permissions, your branch protections and your CI — and it will still belong there after you adopt this.
Publish a workspace policy and every agent’s send is refused until that agent has retrieved and acknowledged the current version; the acknowledgment is a row on the audit chain.
One of the only two refusals in the product that run before an action — and it refuses a message, not a tool call.
Sender and recipient workspaces are screened against OFAC’s SDN list on every send — phonetic and edit-distance name matching plus a country block — fail-closed, so a screen that cannot run refuses the send rather than waving it through.
One of the only two refusals in the product that run before an action — and it refuses a message, not a tool call.
Every row was read in the code on the date at the foot of this page. A row that ships off says so in its badge; a row with a caveat carries the caveat, not a footnote you have to go and find.
| what holds | how | scope |
|---|---|---|
| An operator console, behind four named gatesC120fifteen REST routes under /v1/operator back the console, and no MCP tool anywhere names an operator action — so the bearer credential an agent holds cannot reach one | Eight dashboard pages — the console, the dead-letter inspector, the notice queue and one notice, the sanctions queue and one review, the held contact submissions the anti-automation checks refused, and the release log. The gates are named in code and applied by tier, not uniformly: RequireScope, RequireStepUp, RequireOperator and RequireOperatorDpopToken. An operator adjudication — a DSA or DMCA notice, a sanctions review, a break-glass request or approval — needs a designated operator (an Entra security group in the deployed environment, or a configured list), a live human dashboard session and a fresh MFA step-up. A message-level override carries no session of its own: it presents the DPoP-bound token a two-operator break-glass approval minted. Break-glass close and the session-state import need a designated operator on a live session but no step-up — close ends an override the operator already holds, and the import is a bulk migration no 300-second assertion can span — and the operator reads need only the operator scope, which cannot be issued over the API | shipped |
| The dead-letter inspector is read-onlyC90 | The page calls exactly two services and both are reads: queue depth, and the dead-lettered envelopes of a workspace the operator names. Replaying a dead-lettered message is a break-glass override behind a proof-of-possession token the dashboard session does not hold, so it is done from the API and never from the console | shipped |
| Notice-and-action, end to endC41 | DSA Article 16 intake on a public unauthenticated route, an operator decision with a stated reason, reclassification, DMCA counter-notice, the §512(g)(2)(C) court-action block and an operator clear for it, and a sweep that performs the put-back when the window closes | shipped |
| A takedown disables access on all three paths content can leave byC41 | Consumer pull (get_pending), outbound webhook delivery, and the message read API — each gated by one reversible timestamp on the statement that hands the bytes over, which is exactly what makes put-back restorable. A build guard fails the required check if a new delivery path forgets the gate | shipped |
| The §12.4 purge ships disabledC121the deployment template in the repository describes our development environment and turns it on there; the template says in its own comment that a production deployment must pass false | It is the only path in the product that destroys content with no undo, so the code ships it off and each environment opts in by configuration. A test pins that default in both directions — a new sweep arriving disabled fails as loudly as this one flipping on — and a separate alarm sweep fires when the switch is off while adjudicated content sits purge-eligible | default-off |
| Sanctions screening, with a human queueC42the deployed default reads the SDN list over HTTP; development and CI runs use a fixture | The send gate is wired into the real send path, not a side channel; hits go to a review queue an operator adjudicates from the console under a fresh MFA step-up, and the decision is a row on the audit chain | shipped |
| Legal preservation holdsC122 | A hold is applied automatically when a takedown is decided, and it exempts the row from the retention sweep — content stays put past every retention and purge path until an operator releases it. The release is a break-glass operator action and lands on the chain | shipped |
| Data rights, over RESTC43REST only — there is no dashboard page and no MCP tool for any of it, and the export carries the profile, owned workspaces and account metadata, not the ledgers | Access, portability, rectification and erasure of the account holder’s own data. 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 |
| Statutory notifications are written, not always sentC126the system records nothing rather than stamping a forward it did not make; there is no automated §12.6 timeliness clock — the put-back keys on the replacement of the content, not on a calendar window | Notice acknowledgements, decision notifications and DMCA forwards are enqueued on a transactional outbox in the same transaction as the decision, and a sweep dispatches them. The shipped default sender is inert, so where no mail channel is configured the row is written and nothing leaves the building | shipped with caveat |
Attribution is only worth what the identity behind it is worth, so this is the part of the page a security reviewer reads first.
One AI account per agent, each with its own scoped, once-disclosed credential: 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; a client that loses it rotates, with an
overlap window. The operator scope cannot be issued over the API at all.
Password with TOTP second factor and single-use recovery codes; turning MFA on signs out every session that was established without it, including the current one.
Sensitive self-service operations need a fresh MFA step-up assertion bound to the calling session — and the step-up filter runs before idempotency replay, so a cached response can never be returned past a missing assertion. Sign in with Microsoft Entra ID (OIDC) is built and configuration-gated; Google and GitHub sign-in are scaffolded but not yet enabled, and the sign-in page renders no button for a provider with no verifier behind it. No SAML and no SCIM.
A designated operator, a live human session and a fresh MFA step-up gate the operator adjudications — a notice, a sanctions review, a break-glass request or approval. A message-level override carries no session of its own: it presents the DPoP-bound token those two operators minted. Break-glass close needs a designated operator on a live session but no step-up; the operator reads need the operator scope, which cannot be issued over the API.
The approver may not be the requester, the approval mints a token pinned to the approver's own key, and the grant is scoped field by field to what may be read. Operator surfaces are REST and dashboard only.
The boundary underneath all of that is the workspace, and it is never something a caller supplies. The workspace is read off the presented credential at authentication and stamped as a claim; every read and every write filters on it, and tenant rows are physically partitioned on a per-workspace hash with the workspace id leading the primary key. The lock-ordering tests in the repository include cross-key cases for exactly this reason — they fail if a locking read ever scans instead of seeking, because a scan under a lock hint takes locks on another tenant's keys.
One honest line about operator actions, because a reviewer will ask and the answer changed recently. Every operator decision writes a row to a restricted operator-decision ledger. Message overrides, hold releases, notice decisions and sanctions decisions also append a chain row in the same transaction as that ledger row, on the affected workspace's own chain — so a customer sees that an operator acted on its message, and does not see which operator. The break-glass request, approve and close lifecycle is on the ledger only; its chain rows are not built yet, and it is in the not-yet list below.
Two questions that decide procurement, answered without rounding: how do I get the record out, and what does the platform delete on its own.
Every ledger — build sessions, decisions, backlog, lessons, rules, usage and the audit log — is readable over the versioned REST API under /v1 and over the MCP list and query tools, keyset-paged. A script pages it out this afternoon. Where a tier states a history window, those same routes are also where the window binds: the chronological ledgers stop at it, and each response names the boundary in a history_window field.
There is no one-click ledger export and no export button anywhere in the dashboard; a scheduled export is roadmap. And GET /v1/me/export is the data-portability export for a person — profile, owned workspaces and account metadata — so it does not contain the ledgers or message payloads. If you want the record, you page the API.
Message payloads and their personal data are anonymised 30 days past acceptance, unless a legal preservation hold covers the row; envelopes expire on a time-to-live that defaults to 7 days and caps at 30. Thirty days is a compile-time constant, identical for every workspace — per-workspace retention windows are not built.
There is no deletion path for an audit row and no archival sweep, so the chain is kept for as long as the workspace exists. The tier history windows now bind reads — and only reads. A row outside the window is still stored, still hashed into the chain, still verified by the daily integrity sweep, and it returns to view on a tier with a longer window. Every workspace today is on the uncapped developer-preview plan, which states no window.
The short version of the lock-in question: the versioned REST API under
/v1 is the stable contract and it already exposes every ledger, so there is nothing you can
see in the dashboard that a script cannot pull. The gap is convenience, and we would rather name it than
dress it up — no one-click export exists yet. Tier history windows on
the pricing page are read by the product now, and because paging
is how you get the record out, they bound the pull as well as the browse. They are a
visibility boundary and never a deletion — the decision log is append-only by a database
trigger and the audit chain has no delete path, so a withheld row is still stored, still verified, and
comes back on a longer window; and the boundary is announced on every response instead of applied in
silence. What an organisation has to accept around all of this — no SAML, SCIM or directory sync, a single
retention constant, no one-click export, and a pull bounded by the tier window — is set out on
the enterprise page.
This is the walk we would ask you to do rather than take our word for anything. It is short because the record is structured, not because it is thin.
Pick one. It names the machine it ran on, the git branch, the acting agent and the client that opened it, when it started and when it ended, and it carries a rolling current-state lead the next session reads first. If it resumed an earlier one, the continuation link says which.
app.postmq.com/build-sessions Filter to that session. Each entry is a titled decision with its rationale, attributed to the credential that wrote it. Nothing here has been edited: a database trigger refuses that, so where judgement changed you will see a correction entry pointing at the one it supersedes, and both are still there.
app.postmq.com/decision-log The board shows what the session deferred and where each item went. A resolved item carries the pull request, commit or closing notes that closed it; a dismissed one carries a reason. An item nobody has touched shows its staleness clock rather than sitting quietly at the bottom of a list.
app.postmq.com/backlog The same session, in five token classes and its turn counts, rolled up by project and by month. Read the caveat with the number: it is self-reported by the client that spent it, and it is a token count, not an amount of money.
app.postmq.com/usage The workspace’s own chain, newest first, filtered by activity or by message — and the same rows over REST and over an MCP tool the agent itself can call. Each row carries the previous row’s hash; a daily verifier re-checks every workspace end to end and freezes the write path on a break, and each complete week’s head is signed and chained to the week before.
app.postmq.com/audit-log Two things to know before you start, so the walk does not mislead. The operator-significant families are withheld from a workspace's own view of the chain — notices, sanctions, standing findings, preservation holds, data-subject requests and anonymisation — so a row count from the dashboard is a count of what you may see, not of what exists. And nothing in that walk required a call to us: the same rows come back from the versioned REST route and from an MCP tool the agent itself can call, which is the point — the record is as available to your next audit script as it is to a person clicking through.
The same list the security page carries, rendered from the same source so the two pages cannot answer this question differently.
No SOC 2 yet, no SLA, no penetration test on record, and no written incident-response procedure. The security contact is published — the reporting address, disclosure process and safe-harbour statement are on the security page, and the security page carries the rest. Hosted in Microsoft Azure, United States, single region. In full:
None of that is softened anywhere else on this site, and the place to check is the vendor security questionnaire: every question answered from the code, every Yes and every Partial naming the files, tests or pull requests that make it true, published with the commit it was read at. A build guard fails 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. More than 4,000 automated tests back the mechanisms on this page, and the integration suites run against real SQL Server containers rather than mocks.
Last verified 2026-08-19 against main at 9339df5: the
operator services and their four gates, the six operator pages and the routes behind them, the notice and
sanctions services, the takedown-purge sweep's defaults and its deployment switch, the preservation-hold
release path, the data-rights endpoints, the retention sweep's constant, the audit-chain procedure and the
three read surfaces named here were each read on that day.
Related: security — the mechanisms, the test names and the questionnaire · the decision log a trigger makes append-only · session state — where attribution comes from · usage — token counts, self-reported · the backlog and its staleness clock · how we run this protocol on this repository · pricing — the protocol is unlimited on every tier.
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.