Security, change control and audit sign first. Then the agent works.
AI agents that clear your security review, change control and internal audit before they touch a queue. Signed rules. An approver from your own team. Your cloud if you want it. A record your auditors can replay.
The shared-services queue. The pilot a business unit already runs. The policy desk. All under one signed file of rules your CISO can read, the manifest. Every action is checked against it before it runs. Hard calls wait for a person you name. The manifest is your change-control artefact. The record is your audit artefact.
Pick a queue. What the agent reads and touches, what it may do, where it must stop, and what goes on the record. Then one run of it, simulated.
Written scope · Gate in front · Record behind
A team built an agent that works. Nobody in security will sign for it. We find what it does, write it down and put Gatehouse in front. The agent stays. The gate is new.
refused · not in manifest
anything the manifest does not name is refused
THE AGENT STAYS · THE GATE IS NEWAn existing pilot's first run under a manifest: one action refused, one held.
Invoice matching · PO exceptions · Vendor onboarding
Matching, exceptions and onboarding checks across every entity. Release, posting and vendor bank details stay with the people your controls already name.
ONE MANIFEST PER ENTITY · ONE RECORD ACROSS ALL OF THEMA vendor onboarding held at the bank detail check, in one of several entities.
Policy questions · Access requests · Escalation by name
Policy questions answered from your approved set, clause cited. Anything outside it goes to the owner you name. Access changes wait for a person.
ANSWERS CITE THE CLAUSE · ACCESS CHANGES GO TO A PERSONTwo employee questions: one answered from policy v7, one escalated to a named owner.
Manifest versions · Re-signing · Export to your archive
Every change to what the agent may do is a new version, signed again. Every run exports to your archive or SIEM in open formats. Internal audit reads it without us.
EVERY VERSION KEPT · EVERY SIGNATURE KEPT · READS WITHOUT GATEHOUSEThe manifest as a change-controlled document: three versions, each signed.
Or the shared-services exception queue. Or the policy desk. Business owner and security in the same room. We write rules both can sign, then run the agent. NDA and DPA first, before any business material moves.
Business owner and security, one session. The queue, the systems, the controls, who signs today. You keep the write-up.
The manifest goes through your change control like any other change. Then the agent runs under it. Your cloud or ours. You decide, and the manifest records it.
Your approvers clear the first stopped actions. Every run exports to your archive. We review the record with internal audit when you say.
What does the pilot actually do, and who signs for it today?
Queue: The pilot a business unit already runsWhich actions did the agent attempt that the manifest refused?
Queue: The pilot a business unit already runsWhich exceptions across entities waited longest for a controller?
Queue: Shared-services AP and procurementWhich vendor onboardings this quarter had an unverified bank detail?
Queue: Shared-services AP and procurementWhich policy questions did the agent answer, and which did it escalate?
Queue: Employee policy and help-desk answersWho changed the manifest, when, and who signed the change?
Queue: Change control and audit exportFour controls. Your technical team gets the detail on the Gatehouse page.
Systems, actions, limits and approvers on one signed document. It is the change-control artefact: every change is a new version, re-signed.
Every action is checked against the signed version as it happens. Anything the manifest does not name is refused, and the refusal is recorded.
Held actions go to one named person with the evidence gathered. Overriding a block takes two names, and both are saved.
Each run is chained by SHA-256 and exports as JSON and CSV your archive, SIEM or GRC tooling can ingest. Internal audit reads it without Gatehouse installed.
Signed before any business material moves. Security questionnaires answered in writing, with a person's name on the answers.
Every action is checked against your rules as it happens. Not named means refused. The refusal goes on the record.
Hard calls wait for one person you name, evidence attached. Overruling a refusal takes two names. Both are saved.
Your cloud or ours. You decide, and the manifest records it. Encrypted in transit, and at rest in the stores we control. Least-privilege access, and every access logged.
Your cloud or ours. You decide, and the manifest records it.
No SOC 2 report or ISO 27001 certificate today. Your security team gets a walkthrough of the four controls and where the deployment runs. We answer your questionnaire in writing and tell you where certification stands.
Read the security answersBuilt from more than one engagement. Names and figures changed. No performance figures, because none were measured on a single engagement.
Every file had to be checked for completeness before a handler could start.
The first pass runs around the clock. Every routing decision carries its reason.
Each one answered in full, with its sources. No sign-up to read them.
Not here? Write to support@surehand.io. A person replies, usually inside two business days.
Talk to the people who run it
What do you need from procurement to start?An NDA and a DPA, signed before any business material moves. Then a teardown of one queue with the business owner and your security team. The teardown document is yours whether or not we go further.
Can we deploy in our own VPC?Your cloud or ours. You decide, and the manifest records it. The manifest names the systems the agent may read and write, and the sub-processor list on the security answers page names everything else.
How are changes to what the agent may do controlled?Every change is a new manifest version, signed again by the accountable person. Every version is kept. Anything the current version does not name is refused. The refusal is recorded.
Who can override a block?Two named people, and both names are saved in the record with the reason. One person cannot do it alone, and the agent cannot do it at all.
Does it work with our SSO?The approver is a named person in your organisation. How that person signs in is agreed in the security review with your identity team and written into the deployment record. We will not claim an integration on this page that your review has not seen.
Are you SOC 2 certified?Not today. Your security team gets a walkthrough of the controls and where the deployment runs. We answer your questionnaire in writing. You hear it from us first when this changes.
What happens if we stop working with Surehand?You keep the rules, the records and the corrections, in open formats that read without Gatehouse. What happens to the agent itself is in the contract.
Tell us what comes in, who handles it and where it waits. We study it with your team and tell you straight if an agent belongs there. A person replies, usually inside two business days.
support@surehand.io