Autonomous where the rules allow. Held where they don't.
Gatehouse treats the agent as untrusted.
Every action clears four gates before it reaches your systems: the rules, the check, the approver, the record. In code, on every action. Not by promise.
One worked example runs through these pages. The screens are simulated, the figures are invented, and each one says so. No SOC 2, no ISO 27001 today. You hear it from us first when this changes.
Four measures your reviewer can check.
Each one leaves something your team can look at for itself.
NDA and DPA signed first
Both are signed before any business material moves. Your counsel can mark up our standard terms.
Encryption in transit and at rest
TLS for data in transit, and encryption at rest in the stores we control.
Least-privilege access, itself logged
Each access is logged in the record: who read what, for which run, under which scope. You can look it up yourself.
A record that shows any edit
Your team checks the records on its own side, without Gatehouse installed. The full record exports in open formats.
Follow one action.
Four gates clear before an action reaches your systems. In code, on every action, never by promise.
- 01The rulesThe agent runs under the signed version only.
- 02The checkChecked before it runs. Every action, every time.
- 03The approverHeld actions go to one name. Overrides take two.
- 04The recordEvery action ships with its receipt.
the actionINV-40218 · schedule payment 2,400.00 · bank detail changed
- 01 / 04
The rules
Before the run opens, Gatehouse loads the rules this deployment runs under. Only a signed version runs. It names the scope, the role the agent acts in, and who signs.
The rules/ fig. 01The version this action runs under. Simulated. - 02 / 04
The check
The action is checked against the signed version as it happens. A changed bank detail matches a hold rule, so the payment stops before it reaches the bank portal. The stop is recorded.
The check/ fig. 02The action meets the rule that holds it. Simulated. - 03 / 04
The approver
The held payment goes to the AP lead, with the evidence attached. They decline it and give a reason. Overriding a block would take two names, both saved beside the rule.
The approver/ fig. 03One name decides. The reason is kept. Simulated. - 04 / 04
The record
Every event of the run is written as it happens and chained by SHA-256. The run seals at the close. It exports in open formats, and your team checks it without Gatehouse installed.
The record/ fig. 04The receipt the action leaves. Simulated.
Try to break it.
Each record holds the SHA-256 digest of the one before it. Change one field and every digest after it stops matching. The hashing runs in your browser.
- record 01CHECKING
prev 000000000000
sha256 ············
- record 02CHECKING
prev ············
sha256 ············
- record 03CHECKING
prev ············
sha256 ············
- record 04CHECKING
prev ············
sha256 ············
Computing SHA-256 in your browser.
Where your data goes.
Your business material stays in your own store. The record holds links to it, not copies.
Material reaches a model provider only inside the scope your rules allow, under API terms that exclude training. Each crossing is logged.
Every processor we use today is listed on the trust page, with what it touches and where.
Sub-processorsWhat we hold, and what we do not.
We are a small, early firm. Both columns, in full.
- NDA and DPA signed first
- Questionnaires answered in writing, with a name on them
- Encryption in transit, and at rest in the stores we control
- Least-privilege access, itself logged
- Sealed records, chained by SHA-256
- Export in open formats that reads without Gatehouse installed
- SOC 2 Type II
- ISO 27001
- Third party penetration test report
- A named security officer
No SOC 2, no ISO 27001 today. You hear it from us first when this changes.
What security reviews ask.
Not here? Write to support@surehand.io. A person replies, usually inside two business days.
Book a walkthrough
Can our team check the record without trusting you?
Yes. Records are chained by SHA-256, so any change shows, and the check runs on your side. The full record exports in open formats and reads without Gatehouse installed.
Does any of our data train a model?
No. Your data reaches a model provider only inside the scope your rules allow, under API terms that exclude training on your material. The record holds links to your material, not copies of it.
Who can access our environment, and how would we know?
Access is least privilege and scoped to each deployment. Each access is logged in the record, with who, what, which run and which scope. You do not need to ask us who touched what. You can look it up.
What happens on an out-of-policy action?
It is refused before it runs. The check sits in the path of each action, so it comes first. The refused attempt is logged in the record with its full context.
How does this map to EU AI Act record-keeping?
Article 12 asks high-risk AI systems to allow automatic recording of events over their lifetime. The record is written automatically as each action runs and exports per decision, so your counsel can check the mapping field by field.
You do not have SOC 2. Why should we proceed?
Maybe you should not, yet. Some reviews require an audit report first, and we respect that. What we can offer today is a record 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, with a name on it.
Send your own questionnaire as it stands, spreadsheet and all. A person answers it in writing, usually inside two business days.
support@surehand.io