Trust & Security

Security posture

• Hosting: Canada and the United States live today; a European Union deployment is planned.
• Encryption: TLS 1.2+ in transit; AES-256 at rest via managed key-management.
• Identity: Managed identity provider with MFA required for all users; least-privilege access control across the platform.
• Audit: Comprehensive audit logging enabled across all production accounts; logs retained per our audit-storage policy.
• Network: All public web endpoints are protected by a web application firewall.

Compliance

• PIPEDA-aligned (Canada). Privacy Policy at /legal/privacy.
• GDPR-ready. All data-subject-rights workflows operational; SCCs and UK IDTA appendix will be added when the EU deployment ships.
• EU CRA vulnerability-handling commitments active. See /security.
• No attestation claims. PulseAI does not claim attestation against ISO 42001, the EU AI Act, or Canada's Directive on Automated Decision-Making. See /audit-ready for our governance approach to producing audit-ready evidence.

Verifying evidence bundles

PulseAI's Evidence Vault seals five kinds of governance record into write-once storage as they happen: an attestation certified, an AI Impact Assessment approved, a shadow-AI application resolved, an AI policy activated, and the weekly health report. Your administrators can cut any scope of those records into a signed evidence bundle to hand an auditor: a ZIP holding manifest.json, a detached signature manifest.sig, the raw stored bytes of every record under payloads/, and a summary PDF. Anyone holding the bundle can check it offline with standard tooling, against the public keys published on this page. No PulseAI account, no PulseAI software, no network access.

Signing keys

Each hosting jurisdiction is a separate deployment with its own signing key: ECDSA on curve NIST P-256, held in a managed key service whose private half has no export path. The public halves are published here. Accept a key from this page and from nowhere else, including from whoever handed you the bundle: anyone able to substitute the key can also hand you a chain it signs. Confirm the fingerprint before trusting a result, and record it in your own files at onboarding so a later substitution shows up as a mismatch rather than a surprise.

Each key file is named by the date it became active and is never replaced at that address: a rotation adds a new row and a new file, and the retired key stays listed with its retirement date and stays downloadable. Signatures made under a retired key remain verifiable against it forever, because verification is a pure function of the bytes, the signature and the public key, and needs nothing from PulseAI. Evaluation environments use their own keys, supplied with the evaluation materials; they are not listed here.

Verify a bundle

Everything below runs from the unzipped bundle plus the key, in bash or zsh, with openssl, shasum, jq and the usual diff, sort and sed. The commands assume the bundle is unzipped into bundle/ and the key for your jurisdiction is saved as pulseai-evidence-signing.pem. Steps 2 and 3 are the cryptographic checks, and none of the steps needs any PulseAI software.

1. Confirm the key. The hash must equal the fingerprint in the table above.

   shasum -a 256 pulseai-evidence-signing.pem

2. Verify the signature. manifest.sig is a small JSON file whose signature field is the base64 of a DER-encoded ECDSA signature over SHA-256 of manifest.json's exact bytes. Decode it, then let openssl do the rest:

   jq -r .signature bundle/manifest.sig | base64 -d > manifest.sig.der openssl dgst -sha256 -verify pulseai-evidence-signing.pem -signature manifest.sig.der bundle/manifest.json

   Verified OK means PulseAI produced this manifest and it has not changed since. Verification failure means the manifest's bytes are not the bytes that were signed, the signature was replaced, or you hold the wrong key for this jurisdiction or key era.
3. Re-hash the payloads. Each entry in the manifest's receipts carries a contentHash of the form sha256:<hex>. Hash each payload's raw bytes and compare; never re-serialize before hashing:

   jq -r '.receipts[] | "\(.contentHash[7:]) bundle/payloads/\(.evidenceId).json"' bundle/manifest.json | shasum -a 256 -c

   A payload that fails here while step 2 passed means the manifest is authentic and that file was altered after signing.
4. Check the set is exact. recordCount must equal the number of receipts, and payloads/ must hold exactly the files the manifest names. A file no receipt names sits outside everything the signature covers; treat it as a finding, not a packaging quirk:

   jq '.recordCount == (.receipts | length)' bundle/manifest.json diff <(jq -r '.receipts[].evidenceId' bundle/manifest.json | sort) <(ls bundle/payloads | sed 's/\.json$//' | sort)

5. Tie it to the sealed chain (optional). The manifest's digestChain names the weekly digest links that cover its records. Ask PulseAI for those digest files and their signature sidecars, verify each against the same key with the step 2 procedure, and confirm the link covering the manifest's cutAt carries a bundleReceipts entry whose exportId matches the manifest's and whose sha256 (after its sha256: prefix) equals shasum -a 256 of the ZIP itself. This is what turns "PulseAI signed this manifest" into "PulseAI sealed this disclosure into a signed weekly chain, where any later change to the record shows up as a link that disagrees with its predecessor".

What the checks prove, and what they do not

• The signature proves authenticity: PulseAI produced this manifest, and it has not been altered since.
• Re-hashing proves internal consistency: the payload files are the ones the manifest names.
• Neither proves completeness. The manifest's scope block states the filters the bundle was cut with, and its unsealedCount states how many records no weekly digest link has sealed yet. A non-zero count is normal for a bundle cut mid-week, not a defect; request a bundle cut after the next weekly seal if you need chain coverage for those records.
• The summary PDF is a rendering, not evidence. It is not hashed by the manifest and is not checked by any verifier. Read it for orientation, never as an assertion.
• The chain is fork-resistant, not fork-proof. PulseAI holds the signing authority, so PulseAI could in principle sign an alternative history from some point forward. Publishing digest roots to an independent external anchor, which would make even that detectable, is deferred work; we state the limit rather than imply it away.

This page is the complete customer procedure. PulseAI's Evidence Vault verification guide is the long form: it specifies the wire formats, covers the weekly digest chain in full, and ships a dependency-free verifier that performs steps 2 to 4 in one command. Both are available to customers and their auditors from support@pulseai.now, which is also where to report a verification failure. The openssl signature check and the per-record hash comparison are exercised against tampered and wrong-key fixtures in PulseAI's build on every change; the jq, shasum -c and diff lines above were run against a synthetic signed bundle, including the tampered-payload, extra-file and wrong-key cases, when this page was written.

Quick links

Our Data Processing Agreement is provided on request: legal@pulseai.now.

Contact

Security disclosures

security@pulseai.now

Privacy questions

privacy@pulseai.now

Legal / DPA

legal@pulseai.now