Security questionnaire

Our AI agents act on accounts only through a fixed set of tool functions ([tool names]). Each of these tools is wrapped with signafAIde, an open-source (Apache-2.0) recording SDK.

• Before a tool runs, the agent writes a decision record: tool name, inputs, time and agent identity. After it returns, it writes an outcome record with the result, or the error if it failed.
• Each record is signed with that agent's own Ed25519 key and hash-chained to the agent's previous record.
• The records are sent to the signafAIde witness service (AIME TECH UK LIMITED, hosted on Google Cloud in London). The witness checks each signature and chain link and co-signs the records in batches. Each batch carries a public drand randomness round, and about every hour the batches are anchored to a public timestamp.
• [Tools that move money or freeze accounts] run in strict mode: the action runs only after the witness has co-signed its decision record. If the witness cannot be reached, the action does not happen.
• [If stored content is on: Inputs and outputs are stored with signafAIde, encrypted with AES-256-GCM under a per-organisation key, for 1 year, or 7 years with the retention add-on.]

• Each record carries two independent signatures: our agent's key and the signafAIde service key. signafAIde holds none of our agent keys, so it cannot forge or edit a record, and we cannot change a record it has co-signed.
• Each record is fixed in time between a public randomness round ("not before") and a public timestamp ("not after").
• The service keys are published at /.well-known/signafaide-keys.json and fixed by those public timestamps. We give you our agents' public keys as a self-signed manifest, and our newest signed head per agent.
• The open verifier (Rust, Python or TypeScript) runs 12 checks on your own machine, without signafAIde. Editing, deleting, reordering or adding a record, or cutting records off the end, fails verification.
• What this proves is integrity and timing, not that a decision was correct. A record's exact time is the agent's claim; what is proven is the window between the randomness round and the public timestamp.

• We create a read-only auditor link for the production environment and the period you choose. It needs no account, has an expiry we set, and we can revoke it at once.
• The link shows each recorded action (agent, tool, time and, where content is stored, the inputs and outputs) and a summary of the chains and timestamps.
• It downloads a zip with the verification pack, our agent keys, our signed heads and a README with the exact command to verify the pack offline.
• We can also give you a printable verification report (HTML or PDF) for the period.

• Actions that do not go through a wrapped tool are not recorded, and nothing detects their absence. Our control is that agents have no other path to [account operations].
• For tools not in strict mode, a record is written locally before the action and sent in the background. An outage of the witness delays co-signing but never loses records already written. Records on a disk that is lost before they are sent are lost with it; we keep the local state on [a persistent volume].
• If an instance restarts on an empty disk, its first record is a signed note saying it continues the chain. When the earlier instance ended cleanly it signed a stop note first, and the restart is counted as clean. When it did not (a crash or a kill), records it had not sent are not known; the verifier, the console and the auditor view count these as unclean starts.

• The service runs on Google Cloud Platform in London (europe-west2). Records and account data are stored in the United Kingdom by default; Enterprise customers can choose the EU.
• By default only the record envelope (tool name, agent name, time, sequence number, chain link) and a salted hash of the content leave our systems. Inputs and outputs are sent only if stored content is turned on.
• Requests pass through Cloudflare, which terminates TLS at its edge and so can see traffic in transit. [If stored content is on: our agents' inputs and outputs travel the same way, so Cloudflare can see them in transit, before signafAIde encrypts them at rest.]
• Encryption: HTTPS in transit; Google Cloud encrypts data at rest; stored content is also encrypted by signafAIde itself with AES-256-GCM under a per-organisation key.

signafAIde commits to 99.5% availability of the hosted witness each calendar month. The witness runs on a single machine, so maintenance and failures of that machine count against the figure. A witness outage delays co-signing but never loses records already written: the SDK keeps them in a local outbox and sends them with their original times when the witness is back. Service credits are available only under an Enterprise order form.

• signafAIde backs up its database daily, inside the UK hosting region, and keeps backups for 30 days. Google Cloud encrypts the backups at rest.
• The service can be restored from a backup to a new machine. signafAIde states no recovery time or recovery point objective; with daily backups, a restore could lose up to a day of the service's own copy.
• Our own copy does not depend on that restore: the SDK keeps every record with its receipt in our local evidence store, which we keep on [a persistent volume], and verification packs we have exported keep verifying offline.

• Under its data processing agreement (section 9), signafAIde notifies us without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting our data. The notice goes to our organisation's owners and admins by email and is posted in the console.
• The notice describes, as far as known at the time, the nature of the breach, the categories and approximate number of people and records concerned, the likely consequences and the measures taken or proposed.
• We notify you [within the time our contract with you sets].
• By default signafAIde holds only record envelopes and salted hashes of the content, so a breach of the service would not expose our agents' inputs and outputs. [If stored content is on: stored content is held encrypted under a per-organisation key.]

• signafAIde staff reach the operator admin only through Cloudflare Access, limited to the company's email domain, and the service checks the access token on every admin request. The admin shows usage analytics and plans; it has no view of stored content. Staff actions in it are logged.
• Access to production servers and databases is limited to named AIMETECH engineering staff, each with an individual account, and is reviewed when staff join or leave. The service key and the content master key are held as secrets in the production environment, not in the code repository.
• signafAIde's published measures do not say whether multi-factor authentication is enforced for staff accounts, so we make no claim about it here. [If you need it confirmed, we will ask the supplier in writing.]
• On our side, console access is by one-time email link, GitHub sign-in or, on Enterprise, single sign-on through our identity provider, where our own multi-factor rules apply. Roles are owner, admin, developer and read-only auditor.

• Vulnerabilities are reported to [email protected]. signafAIde confirms receipt, says what it does about the report, and takes no action against good-faith research that avoids other customers' data and does not disrupt the service.
• In November 2026 AIMETECH ran internal adversarial security reviews of the protocol, the server and the SDKs, fixed the findings, and checked each fix against the review's own reproduction.
• signafAIde publishes no fixed times for fixing a reported vulnerability, and no external penetration test has been done yet.

• Record envelopes, signatures and receipts are kept with no time limit while our account is active.
• Stored content is kept 1 year, or 7 years with the retention add-on (£10 a month on Team), then deleted; the records stay verifiable without it.
• We keep exported verification packs in our own archive for [retention period].

Google Cloud (hosting, UK), Brevo (transactional email, EU), Stripe (payments), Cloudflare (edge network and staff access control) and GitHub (optional sign-in). The current list, with locations and transfer safeguards, is at /legal/subprocessors. New sub-processors are announced at least 30 days in advance.

signafAIde does not hold ISO/IEC 27001 certification or a SOC 2 report. Its hosting provider, Google Cloud, holds ISO/IEC 27001 certification and SOC 2 reports for its infrastructure; those cover Google's data centres and platform, not signafAIde's own controls.

No external penetration test has been done yet. In November 2026 AIMETECH ran two internal adversarial security reviews of the protocol, the server and the SDKs, and fixed the findings. The protocol is a public specification with test vectors, and three independent verifiers must agree on every one of them.

• Under the signafAIde terms (section 18.3), each party's total liability in any 12-month period is limited to the greater of the fees paid and payable for the service in the 12 months before the event, and £100.
• Neither party is liable for loss of profits, revenue or goodwill, loss or corruption of data (except signafAIde's obligation to restore from backups where available), regulatory fines to the extent the law allows, or indirect loss (section 18.2).
• Nothing limits liability for death or personal injury caused by negligence, fraud, or anything else that cannot be limited by law (section 18.1).
• signafAIde is not liable for the content of our records or the decisions and actions of our agents (section 18.4). The service attests integrity and timing, not whether a decision was right.

• AIME TECH UK LIMITED gives at least 12 months' notice before the signafAIde service stops.
• The export tools work throughout.
• If AIMETECH winds the service down, it releases the witness server's source code under the Apache License 2.0.
• Exported verification packs keep verifying offline with the open-source verifier, whatever happens to signafAIde.
• signafAIde can end our contract without cause only on at least 90 days' notice, with a pro-rata refund of prepaid fees, and we can export for 90 days after it ends.

These commitments are in the signafAIde terms of service, sections 16.3, 16.4 and 16.7.

• An owner can delete a project or the whole organisation in the console, and any user their own account; this takes effect at once.
• After termination, data is deleted within 30 days, and backups expire within a further 30 days.
• Kept after deletion: the hashes in public timestamps (published permanently by third parties) and, for anchored batches, the batch hash and its path in the anchor, which identify no one and contain no record content.

AIME TECH UK LIMITED, registered in England and Wales, company number 16819323, 42 Beaufort Court, Admirals Way, London, E14 9XL. ICO registration ZC169006. Security contact and responsible disclosure: [email protected]. Terms, privacy notice, data processing agreement and sub-processors: /legal/terms.