Enterprise-grade by construction, not by checklist.
pm.gold's guarantees are enforced in the data layer, so they hold even when something above them has a bug. This page describes what is built and provable today, and what is on the certification roadmap — labeled honestly, because that is the product's own standard.
Architecture guarantees
Enforced structurally in the database and proven by automated checks that run against the live system.
Tenant isolation, fail-closed
One private workspace per company. Row-level security is enabled and enforced on every content table, and it fails closed: a request without verified workspace context returns nothing — no context, no data. Cross-tenant isolation is exercised by live checks, not assumed.
Unforgeable identity context
Workspace and permission context is derived server-side from the verified session — never from client-supplied values. Membership and role are checked live on each request, so revocation takes effect on the next request, not the next login.
Permission-faithful knowledge
Source-level permissions are captured at ingest and enforced at retrieval through a single choke point. Content with unknown or missing permissions is quarantined — fail closed. Derived artifacts inherit the intersection of their sources' permissions; widening happens only through a governed, human-approved declassification step.
Human-in-the-loop commit gate
Agents propose; a person approves or rejects. Maker and checker are separated at the type level — the generation path has no commit capability. Nothing enters the record automatically.
Append-only audit
Every agent action, generation, approval, override, and administrative action is recorded with actor, timestamp, and source. The audit trail is append-only by database grant: no application role — including platform operators — holds permission to edit or delete entries. Audit records are content-free and outlive the records they describe.
Operators cannot read your content
Platform administration is a separate plane with zero grants on content tables — a content read by an operator is denied at the database, a property we probe directly. Any operator joining a workspace is an explicit, audited membership event that cannot be hidden or erased by the operator. There is no impersonation feature, by decision.
Prompt-injection defense
Ingested content is treated as data, not instructions. The structural injection paths are closed deterministically, and synthesis-content integrity is measured and reported as a metric — not claimed as an absolute.
Real deletion
Erasure both revokes access immediately and destroys the verbatim content — stored text, embeddings, and cached citation snippets — across all versions, in one atomic operation, leaving a content-free tombstone. Derived sections that mixed erased and surviving sources can be re-grounded from surviving sources only, making the replacement byte-clean by construction.
Honest scope. "Append-only" here means append-only against every application and operator role — the threat model that matters for insider misuse. It is not yet a cryptographic WORM store; a tamper-evident hash chain is the named upgrade for buyers who require provably untampered audit.
Identity & access
Bring your identity provider; keep your access rules.
SSO through your identity provider (Microsoft Entra ID or Google) via OIDC/SAML, bound to your tenant — we never see passwords. SCIM directory sync keeps membership and groups current, so your directory remains the source of truth for who can see what. RBAC separates what users can do (owner, admin, member, viewer) from what they can see (content permissions) — a workspace admin does not automatically read restricted content. First sign-in provisions a least-privilege account just in time.
Encryption & infrastructure
In transit: TLS 1.2 or higher. At rest: AES-256 via our managed cloud infrastructure. Secrets are held by environment reference only — never in code or documents. Dedicated single-tenant deployment is available for pilot customers with isolation requirements. Schema changes are forward-only and versioned.
AI & model security
Foundation models are accessed through commercial APIs behind a model-agnostic seam. Your content is not used to train generalized models — by API terms, and contractually in our DPA, passed through to subprocessors. Each generation cites its sources, and ungroundable claims are flagged rather than fabricated. Model calls carry cost and latency telemetry with personal information redacted. Bring-your-own-key is supported for teams that prefer their own provider relationship.
Two AI providers, both enterprise-termed, deliberately. Text generation runs on Anthropic; retrieval embeddings run on Microsoft Azure OpenAI, where content stays inside the deployment's Azure region. We keep this list as short as we can — in July 2026 we removed a third embedding vendor whose default terms claimed a training licence, and replaced it with Azure after measuring that retrieval quality did not suffer. Fewer AI processors is a design goal, not an accident of procurement.
AI-generated content is marked
Anything an assistant drafted says so, in a form a machine can read. Every proposal in the review queue and every row in an audit export carries a marking that states whether the text was artificially generated and, when it was, which agent produced it. This is our implementation of the EU AI Act's requirement (Article 50(2)) that artificially generated output be marked in a machine-readable format.
The marking is derived, not declared — and that distinction is the reason to trust it. A flag somebody remembers to set is a flag somebody eventually forgets to set, and the failure is silent and in the worst direction: an unmarked AI artifact looks exactly like a human one. So the marking is computed from the recorded author of each artifact, every agent that can propose stamps its own identity, and an automated test refuses to let a new agent merge without naming itself. An unmarked AI artifact is not something we rely on people to prevent.
Approval does not erase the marking. When a person reviews an assistant's draft and commits it, the artifact stays marked as generated. Approval records that a human took responsibility for the claim — it does not make them its author, and collapsing the two would quietly strip the marking from every AI artifact at the exact moment somebody clicked approve.
Where authorship is not recorded, we say "unknown" rather than "human." Assuming human is the one direction that hides an AI artifact.
The limit of this control, stated plainly: it marks provenance inside pm.gold's own responses and exports. It is not C2PA, it carries no cryptographic signature, and it does not survive the text being copied into another document. A compliance control that overstates its reach is worse than one that states its edge, because the overstatement is what a reviewer relies on.
Outbound fetching
pm.gold fetches public web pages on your behalf, on a schedule. When a member starts watching a page, or an assistant is asked to capture a URL, our servers request that page directly — and a nightly job re-requests every watched page to see whether it changed. We are telling you this plainly because it is the one place the product reaches out rather than in: the target site sees a request from us, identified as pm.gold-crawler, and we honour robots.txt at the moment a watch is created rather than only when we crawl.
What that reach cannot do. Only http and https. Every URL is resolved before it is fetched and refused if it lands on a private, loopback, link-local or reserved address — the cloud metadata endpoint included — and every redirect hop is re-checked, so a public address that redirects inward is refused at the hop. Responses are size-capped and time-bounded. No cookie, credential or authorization header is ever sent, so nothing we retrieve is anything the open internet could not retrieve. Requests originate from our application servers, not from your network. One residual we would rather state than omit: a host that changes its DNS answer between our check and our fetch (DNS rebinding) is not fully prevented by resolve-then-fetch; pinning to the resolved address is a planned hardening.
And what it fetches is data, never instruction. Page text is stored as evidence and is never executed as a prompt. Anything an assistant derives from it arrives as a proposal in a human's review queue with its citations attached — a page an attacker persuaded us to read can reach a reviewer, which is what a review queue is for. It cannot reach the record.
Sending a digest out
pm.gold can send you a weekly digest of your own workspace, and a digest is data leaving the system — so the controls are described here rather than only on the product page. Nothing is ever sent automatically: a digest goes out when a person clicks send.
Email goes only to the requester’s own verified address. There is no field to type a destination into, which is what keeps this a convenience rather than a way to move a workspace’s state to an arbitrary inbox.
Slack cannot copy that constraint, so it earns a different one. A webhook URL genuinely is something a person supplies, because it identifies their channel. So the destination is configuration, not a request parameter: set once by an administrator, stored encrypted, constrained to Slack’s own webhook host before it is stored, and re-checked again at the moment of sending. No read path returns it — an administrator sees a channel name and a fingerprint, enough to confirm which webhook is configured and to notice that it changed, and nothing a screenshot could leak. A “send this digest to <url>” field would let anyone who can read a workspace forward its state anywhere, on every future click, with the audit trail showing a legitimate feature being used legitimately.
What a digest contains is deliberately thin: counts, titles and links into the product — never evidence text, never quotes from a source. A channel is if anything a wider audience than an inbox: membership drifts, people are added, and history stays searchable by everyone in it. An item the recipient may not be entitled to see is counted but not named. Every send is audited with the destination fingerprint; the message body is not recorded.
A webhook to your own Slack sends data to your provider under your agreement — no subprocessor of ours is added by it. Email is different: it is delivered by our processor, named in the subprocessor list, and the send refuses to run at all until that disclosure is in place.
Build & operations
No change reaches production unreviewed. Every push and pull request runs an automated gate: the application must build, the full offline test suite must pass, and a set of structural locks must hold — assertions that the invariants above cannot regress. Those locks check that workspace context is always derived server-side and never taken from a client, that an agent can propose but has no path to commit, and that connector permission mapping fails closed on an unknown access list. A change that breaks one of them cannot merge.
Separate environments. Development and automated testing run against a separate database. Production credentials are not present in a developer environment, so a test run cannot reach customer data.
Abuse limits. Public, pre-authentication endpoints — the demo-request form, the agent-access OAuth endpoints, and the agent protocol surface — are rate limited per caller, with the strictest limits on the two unauthenticated endpoints that write: client registration and the demo-request form. Limits are enforced in the database, so they hold across every server instance rather than per process.
Failure visibility. Server errors are recorded with route, type and stack trace, grouped so a recurring fault is one entry rather than many. Request bodies are never recorded. The error log is write-only to the application role and readable only by the operator plane, and it lives in our own database rather than a third-party monitoring service — error messages are the telemetry most likely to contain customer content by accident. A health endpoint checks database reachability, not just that the web tier answers.
Stated as built. We do not yet run alerting, distributed tracing, or a managed observability service; if a customer requires one it becomes a named subprocessor by agreement, not by default.
Compliance & certification roadmap
Where we are, stated plainly. Documents available on request under NDA: security@pm.gold.
| Item | Status | Notes |
|---|---|---|
| DPA with no-training commitment | AVAILABLE | Standard DPA for pilot customers; AI no-train terms passed through to subprocessors. |
| Security questionnaire (CAIQ-Lite) | ON REQUEST | We complete a CAIQ-Lite self-assessment on request for security reviews. |
| Subprocessor list | PUBLISHED | See Privacy Policy §7; change notice per DPA. |
| SOC 2 Type I | PLANNED | Targeted as we onboard our first production customers; controls are being built toward it. |
| Penetration test | PLANNED | Independent test planned; summary shareable under NDA once complete. |
| SOC 2 Type II / ISO 27001 | PLANNED | Follows Type I on the certification ladder. |
| Data residency options | PLANNED | Regional deployments when customer requirements demand. |
| DSR (subject-rights) workflows | AVAILABLE | Erasure, access (Art. 15) and portability (Art. 20) are built. The export is machine-readable and names what it excludes and why: identity, self-stated context and issued credentials in full; activity as an index of what the person did and when; not the text of the company's decisions, which is the controller's data rather than the subject’s. Rectification (Art. 16) is deliberately not a separate workflow — a correction is a new version through the ordinary gate, and the original stays in history. |
Responsible disclosure
If you believe you've found a vulnerability, email security@pm.gold. We commit to acknowledging reports within 2 business days, will not pursue good-faith research conducted within scope, and will credit reporters who wish to be named.
Questions
Security reviews move faster with the right documents. For the DPA, questionnaire responses, or a walkthrough of the architecture above: security@pm.gold.
Status markers reflect our program as of the date above and will change as we progress — we label what is built versus planned honestly and update this page as milestones are met. We are also finalizing our formal documentation with counsel. Provided for transparency; not legal advice.