Written for your reviewer

Security answers you can check.

Send the questionnaire

Read this before the first call. It covers the audit trail, where your data goes, and the certifications we do not hold yet.

Where we start

Weassumeyoursecurityteambelievesnothingwesay.Good.Soeachansweronthispagepointstosomethingtheycancheckforthemselves.

In place today

Four measures your reviewer can check.

Each one leaves something your team can look at for itself.

  • In place

    NDA and DPA signed first

    Both are signed before any business material moves. Your counsel can mark up our standard terms.

  • In place

    Encryption in transit and at rest

    TLS for data in transit, and encryption at rest in the stores we control.

  • In place

    Least-privilege access, itself logged

    Each access is logged in the trail, with who read what, for which run and under which scope. You can look it up yourself.

  • In place

    Tamper-evident audit trail

    Your team checks the records on its own side, without Gatehouse installed. The full trail exports in open formats.

You can test the record chain on this page. Try to break it

The evidence

Four questions reviewers ask.

Each answer says how the system works. Each one comes with a simulated screen, labelled as such.

Audit trail

Simulated
trail / RUN-7F2K4sealed
record written as it runsholds context · sources · decision cost · approverlogging automaticchain SHA-256 · prev digestverify your side · open formats
14:31:52 run opened manifest v1414:31:58 invoice matched INV-4021814:32:00 payment held bank-detail-change14:32:19 declined record sealed

Where is the record? In the trail.

Each action is written to the trail as it runs, with its context, sources, decision, cost and approver. A record can't be changed without the change showing. The step that enforces the rules also writes the record, so nobody has to remember to log.

Data path

Simulated

The trail points at your material. It does not hold it.

In the trail

  • Links back to the source.
  • Each crossing, logged: what was read, for which run, under which scope.
  • One path across the boundary, encrypted in transit.
  • Proof of what happened, even after you revoke our access.

Not in the trail

  • A copy of your business material. The trail links to it instead.
  • The documents an event touched. The trail proves the event without showing them.
  • Reads outside the approved purpose. Access is least privilege, limited to that purpose.
  • A copy of your data. No path copies it into the trail.

Where does the data go? Only inside the manifest's scope.

No path copies your data into the trail. Material reaches a model provider only inside the manifest's scope, under API terms that exclude training, and each crossing is logged.
Sub-processors are listed on the Surehand trust page
Purpose limits at runtime

Approvals

Simulated

Export · INV-40218open formats

  • INV-40218.pdfInvoice · 2,400.00
  • bank-detail.pngEvidence · first seen today
  • decision-note.pdfDecision · AP lead
  • trail · RUN-7F2K4Record · 6 events
  • manifest v14 · signedPolicy · signed
threshold above · run holdsroute one named personevidence gathereddecision recorded · name on itoverride a block, two namestrace override recorded

Who approves? One named person.

Above your risk threshold, the run holds and goes to one named approver with the evidence gathered. The decision is saved with their name. Overriding a block takes two names, both saved with the override.

Drift

Simulated
manifest/v14.yamlsigned
1scope: accounts-payable 2role: ap-agent 3limits: 4 autopay: 250.00 5approver: ap-lead 6rules: 7 bank-detail-change: hold 8default: refuse
engine in the execution pathaction out of policyresult refusedrefusal recordedeval checks vs current policydrift shows in the trail

What stops drift? Enforcement at runtime.

The policy engine sits in the path of each action. An action outside policy is refused before it runs, and the refusal is logged. Continuous evaluation re-checks past decisions against the current policy, so drift shows up in the trail.

Verify it yourself

The chain breaks in front of you.

Each record holds the SHA-256 digest of the one before it. Change one field and each digest after it stops matching.

trail / RUN-7F2K4 · manifest v14Simulated

Your turn

Change any field below and watch the chain break.

  • Record 01

    Checking

    prev 00000000 · pointer verified

    sha256 ········

  • Record 02

    Checking

    prev ········ · pointer verified

    sha256 ········

  • Record 03

    Checking

    prev ········ · pointer verified

    sha256 ········

  • Record 04

    Checking

    prev ········ · pointer verified

    sha256 ········

Computing SHA-256.

Edit anything. The digests update as you type.

Simulated records, real SHA-256, computed in your browser.

Certifications

What we hold, and what we do not.

We are a small, early firm. This list shows what we have today and what we do not.

  • In place

    Questionnaires answered in writing

    Completed in writing, with a person's name on it.

  • Not yet

    SOC 2 Type II

    Not yet. We have no SOC 2 audit report to show you today.

  • Not yet

    ISO 27001

    Not yet. We do not hold ISO 27001 certification today.

  • Not yet

    Third-party penetration test

    Not yet. We have no third-party penetration test report to show you today.

  • Not yet

    A named security officer

    Not yet. There is no named security officer today. Each questionnaire answer carries the name of the person who wrote it.

No SOC 2, no ISO 27001 today. You hear it from us first when this changes.

Surehand answers twelve AI vendor questions on its trust pageWho is behind this

Before you ask

Six common questions, answered.

Send your own questionnaire as it stands, spreadsheet and all. We answer it in writing and send it back, usually inside two business days.

  • Yes. Records are chained by SHA-256, so any change shows, and the checks run on your side. The full trail exports in open formats and reads without Gatehouse installed.

  • No. Your data reaches a model provider only inside the manifest's scope, under API terms that exclude training on your material. The trail holds links to your material, not copies of it. An agent that reaches outside its approved purpose is refused, and the refusal is logged.

  • Access is least privilege and scoped to each deployment. Each access is logged in the trail, with who, what, which run and which scope. You do not need to ask us who touched what. You can look it up.

  • It is refused before it runs. The policy engine sits in the path of each action, so the check comes first. The refused attempt is logged in the trail with its full context.

  • Article 12 requires high-risk AI systems to allow automatic recording of events (logs) over their lifetime. The trail records each action automatically as it runs. It exports per decision, with sources and the approver's name, so your counsel can check the mapping field by field.

  • Maybe you should not, yet. Some reviews require an audit report first, and we respect that. What we can offer today is a trail your team checks for itself, at any time. It does not replace an audit report, and we will tell you when our position changes.

Send the questionnaire.Get it back in writing.