Trust & Security Posture
Last updated August 2026
swaudit is a tool whose entire job is to tell an organization that some piece of software cannot be trusted on the evidence. That only works if we hold ourselves to the same standard. This page states plainly what we can independently demonstrate and what we cannot yet claim — with no attestation, certification, or compliance status we do not actually hold. Where we are unsure whether we hold something, we say “not claimed” rather than assert it.
Section 1Posture at a glance
We hold no third-party security attestation. Stated up front.
swaudit does not hold, and does not claim, a SOC 2 report (Type I or Type II), ISO 27001, or any other independent security certification or attestation. We have not engaged an external auditor and no examination is in progress.
Formal attestation is on our roadmap and is deferred until funded. Consistent with our own honesty rules, we will not reference an attestation, or message any target date for one, until a report is physically in hand.
What follows is not a substitute for that. It is a description of controls and results that a prospective buyer, or their security team, can ask us to demonstrate — several of them proven on live hardware, each stated as a capability we can show rather than a certification we hold.
| Item | Status | Note |
|---|---|---|
| SOC 2 (Type I / Type II) | Not held | Deferred until funded; no auditor engaged. |
| ISO 27001 / other certification | Not held | Not claimed. |
| Independent penetration test report | Not held | Not claimed. |
| Live-proven detection & isolation results | Demonstrable | See Section 2 — reproduced on real hardware. |
| Signed, independently verifiable reports | Deployment-enabled | Ed25519 signatures, offline verification — minted only where an operator has configured a signing key. A report from a deployment without one carries no signature and says so on its face. See Section 2. |
| SSO / RBAC / per-tenant isolation | Demonstrable | Enforced in the product today. |
| Internal governance / readiness review | In progress | Not an attestation; has open findings. |
Section 2What is independently demonstrable today
Everything below is a capability we can show, not a certification we hold. Several results were reproduced on real hardware; where a control is only tested off-VM, or a check is implemented but not yet run live, we say so in the same breath.
Honeytoken exfiltration → REJECT, on real hardware
Before a candidate runs, we seed unique marker credentials (“honeytokens”) into the sandbox. There is no legitimate reason for that exact string to ever leave the machine. In live validation (August 2026, reproduced across three independent VM runs), a candidate that read a planted marker and shipped it over TLS was detected (honeytoken_hit) and the verdict was REJECT — and the authoritative detection was run on the exact intercepted plaintext pulled back from the guest, traced to the specific event that carried the marker.
The result means something only because of a negative control: the same markers planted, a benign candidate that steals nothing, and zero hits. A positive without that negative would prove only that the detector reacts to tokens existing, not to them being stolen.
The candidate cannot forge a clean verdict — escape matrix, proven live
The collector shares the swaudit Windows VM with the untrusted candidate, so a defensible verdict has to prove the candidate cannot forge a clean result, fabricate or destroy evidence, steal the answer key to the planted credentials, or escalate out of the sandbox into our cloud account. This was tested by a probe that runs as the de-privileged candidate itself (and is thrown out as untrustworthy unless it genuinely ran as that account — a control that “blocked” a privileged probe would prove nothing). Proven live in the same run whose candidate still successfully exfiltrated its markers — the isolation fences the candidate without blinding the detection it protects.
| What the candidate tries | What it would win | Result |
|---|---|---|
| Read the collector’s authentication key from the instance metadata channel | Sign a forged batch of evidence → hand back a clean approval | Blocked |
| Read that key where it sits at rest on the machine | Same — forge a clean verdict | Blocked |
| Write into, or delete from, the evidence queue | Plant fake benign evidence, or erase the record of its own theft | Blocked |
| Mint the sandbox’s own cloud credentials | Break out of the sandbox and pivot into the cloud account | Blocked |
| Read a planted-credential file with no restriction on other accounts | Read the marker in a way that breaks attribution | Restricted |
Kept honest: the honeytoken-file result above is the DACL scan (no world-readable access on the planted file), proven live. The stronger cross-user negative — a second, unrelated de-privileged account being denied the same marker — is implemented but has not yet been run on a live VM, so we do not yet claim it as proven. One correctness guard in this family (baseline-comparability) is verified off-VM only. An audit run with the candidate granted administrator rights is out of scope by design and is floored to inconclusive rather than trusted.
Signed reports — a deployment-enabled control, and what a verifier can conclude
Reports and evidence-pack manifests are signed with Ed25519. The signature is a separate sidecar file, and it is checked offline with our verify-report tool on a machine of your choosing: you need the report, its sidecar, and the signing deployment’s public key, and nothing else. The signature covers the report’s digest and every field of the envelope around it, so altering either one invalidates it — and a report re-rendered after it was signed shows an invalid signature rather than being quietly re-signed over the top.
Stated precisely rather than absolutely: signing is enabled per deployment, not universal. Signatures are minted by the server that serves the report, using a private key an operator configures; a deployment with no signing key configured mints no signature at all. That case is not disguised — such a report says “no sidecar — report integrity not signed” on its own run page, and the endpoint that would serve a public key returns nothing to verify against. So “is this report signed?” is a question answered by the artifact in your hand, not by this page.
| What you have | What verification proves | What it does not prove |
|---|---|---|
| Signature sidecar, checked against a public key you obtained separately from the report | Integrity and authenticity: this is byte-for-byte the report that key signed, unedited since. | That the audit itself was right. A signature attests to the artifact, never to the verdict inside it. |
| Signature sidecar alone, checked against the key carried inside it | Internal consistency only: report and envelope match each other. | Authenticity. Anyone re-signing an edited report embeds their own key. The tool warns and exits with a distinct status instead of printing “OK”, so an automated check cannot mistake it for a pass. |
| A checksum sidecar only | Integrity against accidental corruption or truncation. | Anything about authorship — whoever can edit the report can regenerate its checksum. It is a checksum, not a signature, and both the report page and the tool label it that way. |
| No sidecar at all | Nothing. There is nothing to check, and verification says so rather than passing. | The report may be perfectly genuine — but you cannot distinguish it from one edited after the audit, and it should not be treated as tamper-evident. |
One timing caveat we would rather state than have you discover: signatures are minted when a report is first served, so switching signing on at a deployment that already holds older reports signs them at that moment. The timestamp inside such a signature is the date signing was enabled, not the date of the audit — it attests to what that server held then, not to what the original run produced. Only a signature timestamped at or after the audit’s own run window means what it appears to mean.
Signed, verifiable reports & evidence packs
Where a deployment is configured with a signing key, reports and evidence packs are Ed25519-signed, and anyone — a regulator, a board member, a vendor — can verify offline that a report is exactly the one that deployment produced and has not been edited. Where it is not, the report states its own lack of a signature rather than looking signed. The table above sets out what each case does and does not prove.
SSO, RBAC & API tokens
Single sign-on behind any OAuth2 / OIDC reverse proxy you already run; three enforced roles (submitter, auditor, approver) mapped from your identity provider’s groups; and revocable API tokens stored hashed, with the plaintext shown once.
Per-tenant isolation
Runs, tokens, reports, and artifacts are scoped per tenant and enforced on every read and write. A dedicated support role can cross tenants only through a crossing that is itself recorded in the audit log.
Hash-chained meta-audit log
Every request — submit, view, sign-off, policy view — is recorded append-only with actor, action, target, status, and IP, each entry SHA-256 hash-chained to the last so edits, reorders, and deletions are detectable. Tamper-evident — see the limitation in Section 5.
Retention, deletion evidence & legal hold
Uploaded binaries are deleted by a background sweeper a short, configurable period after the audit completes, and every deletion is recorded in an append-only log so the removal itself is verifiable. An auditor-gated legal hold exempts a run from deletion until released.
“Could not observe” never reads as “clean”
A collector that goes silent, a telemetry batch that fails its authentication check, a candidate that never launched, or a channel we could not decrypt all floor the verdict to review or inconclusive. An audit that could not see clearly never returns a clean approval.
Section 3Data handling
The hosted service touches two kinds of material: the software you submit for analysis, and the artifacts an audit produces about that software’s behavior. We describe both here; the full legal treatment is in our Privacy Policy.
What we process
- Submitted software. The candidate binary or script you upload, used only to perform the requested audit and produce its report — not for any other purpose. Do not include personal data in a submission unless you are authorized to share it with us.
- Audit artifacts. Process, file, and network event logs; the candidate’s intercepted network traffic inside the sandbox, including decrypted TLS content; planted-credential hit records; screen recordings of interactive sessions; and the resulting reports. These describe the behavior of the analyzed software.
- Account & contact data. An identifier such as your email, name, and role when you sign in or use a token; and whatever you choose to provide on a contact or demo-request form.
- Operational data. IP address, user-agent, request logs, and the server-side audit log, kept for security and accountability.
How long we keep it
- Submitted binaries are deleted automatically a short, configurable period after their audit reaches a terminal state (default 24 hours), enforced in code by a background sweeper, unless a legal hold applies. Every deletion is written to an append-only deletion log.
- Reports, event logs, and session recordings are retained so audits remain reviewable and verifiable, and are deleted on request where we have no overriding obligation to keep them.
- Contact and demo-request records are kept while we have an ongoing business reason, and deleted on request.
Protections in place
- Analyzed software runs in a disposable, per-audit Windows VM — created for one audit, destroyed after it, sharing no kernel, filesystem, or namespace with the audit infrastructure, and never reused between audits.
- Encryption in transit; role-based access control; an append-only audit log of actions in the service.
- Data is processed in a United States region.
- Self-hosted deployments: reports, evidence packs, binaries, and the audit log stay in the deploying organization’s own storage and cloud account, under credentials it supplies. Note the deliberate trade below in Section 5 — audits still execute in a real VM, so the candidate leaves the local network for the configured cloud account.
Section 4Subprocessors
We use a small number of service providers to operate the hosted service, acting on our instructions. We list them by category. We do not sell personal information, and we do not share it with third parties for their own advertising.
| Category | Purpose | Region |
|---|---|---|
| Cloud infrastructure (IaaS) | Hosts the control plane and the disposable Windows VMs in which candidate software is analyzed. | United States |
| Transactional email | Delivers requested messages such as demo-access links and, where configured, notifications. | United States |
| DNS | Resolves the service’s domain names. | Global |
Integrations you configure (for example chat, ticketing, or generic webhook destinations) are not subprocessors: the service sends only what you configure it to send, to a destination you choose and control. Self-hosted deployments run on the deploying organization’s own infrastructure and its own choice of providers, which are outside this list.
Section 5Known limitations
Stated deliberately, because a trust page that hides its own limits is exactly the failure mode this product exists to catch. A visitor should leave this page knowing precisely what is proven and what is not.
No independent attestation yet
As stated up front: no SOC 2, no ISO 27001, no independent penetration-test report. Deferred until funded. Do not treat this page as an attestation — it is a description of controls we can demonstrate, not an examination by a third party.
The audit log is tamper-evident, not tamper-proof
The meta-audit log is an unkeyed SHA-256 hash chain stored beside the records it protects. That makes it tamper-evident against accidental corruption and casual edits — but not tamper-proof against an actor with write access to the host, who could recompute a consistent chain or truncate the newest entries. A local key would not close this, because the same access that writes the log can read the key. The real fix is anchoring the chain head to an off-host, append-only store, which is on the roadmap and not yet shipped.
Single-host, single-writer deployment
State lives on a single local filesystem, and the audit log uses an exclusive single-writer lock — a second writer refuses to start rather than corrupt the chain. Consequently the web tier does not run as multiple replicas, and there is no supported high-availability, backup/restore, or migration procedure. The supported self-hosted artifact is a container-compose bundle; there is no Kubernetes, Terraform, or bare-metal installer.
Detection blind spots we assert rather than hide
We do not claim to catch: a marker that is encoded (e.g. base64) before it leaves; plain http:// traffic; a client that pins its own certificate, opens a raw TLS socket, or otherwise ignores the sandbox proxy; or a marker deliberately split across writes beyond the reassembly window. Each of these has a test that asserts it evades, so the coverage claim cannot quietly drift into an overclaim.
Administrator candidate is out of scope by design
Every candidate-isolation control assumes the candidate runs de-privileged. A candidate granted administrator rights can defeat the in-guest controls — so such a run is floored to inconclusive rather than trusted, and the report names it. The durable fix is out-of-guest, hypervisor-protected collection, which is on the roadmap.
Not air-gapped; cloud credentials required
Every audit runs a real VM, so the candidate binary leaves the local network for the cloud account you configure. That is a deliberate trade — a hypervisor boundary is a stronger isolation guarantee than a container — but it means fully on-premise and air-gapped operation are not supported, and neither is any deployment without cloud credentials. If binaries are contractually barred from leaving your premises, swaudit is not currently a fit, and we would rather tell you here.
Some capabilities are operator-configured, not on by default
Report signing and the meta-audit log are enabled by configuration — in any deployment, ours or yours, not only self-hosted ones. A deployment that has not enabled them does not have those properties, and nothing in the report’s appearance implies otherwise: an unsigned report states its own lack of a signature, and the endpoint that would serve a public key returns nothing. We say this so that “signed reports” and “audit log” are read as capabilities that have to be switched on and checked, rather than guarantees that are always present. This is not hypothetical: we found a deployment of our own serving unsigned reports while this page described them as signed without qualification, which is why the wording above is what it is. If a signature matters to your process, verify it on the specific report you were handed, against a public key you asked us for — that key is the only thing that proves authorship.
Our own governance review is in progress and has open findings
We have run an internal governance and readiness review of swaudit itself. It is not an attestation, and it recorded open findings — several of which are the same items listed above (off-host anchoring, operator-configured controls). We are working through them and will not represent them as closed until they are.
Questions from a security team are welcome, and we would rather answer them directly than gesture at a badge. Use the contact form or email rapidvps@gmail.com.