Security

• On your machine. The SDK wraps the tools your agent uses. Each call writes a record that is signed with the agent's own Ed25519 key and chained to the record before it, in .signafaide/ in your project. This works with no network and no account.
• The witness. Once a person opts in, the SDK sends records to the signafAIde service (or to a witness you host yourself). The service checks each signature and chain link, signs each batch and the agent's newest record, and adds a public randomness round from drand ("not before").
• Public timestamp. About every hour the service combines the new batch hashes of all customers into one hash and submits it to public timestamp services ("not after"). Only that hash is published.
• Anyone can check. A verification pack can be checked with the open verifier, in Rust, Python or TypeScript. The protocol is a public specification with test vectors, and the SDKs and verifier are open source.

By default each record sends its envelope: the tool name, the agent name, the time, the sequence number, the link to the record before, and the content hash. The content hash is salted with 16 random bytes that stay on your machine with the content, so the service cannot work out the content from the hash, even content with few possible values. Inputs and outputs are sent only if you turn on stored content.

Tool and agent names are sent as you write them: do not put personal data in them. The SDKs also send a client header (SDK version, language, framework adapter and detected coding agent) for usage metrics; SIGNAFAIDE_TELEMETRY=0 leaves out the adapter, the coding agent and the usage events.

• In transit: HTTPS between your systems and the service.
• At rest: the database and backups are on Google Cloud, which encrypts stored data at rest by default.
• Stored content: encrypted by the service itself with AES-256-GCM, under a data key per organisation, bound to each record. On Enterprise you can supply your own key, which wraps those data keys; revoking it makes the content unreadable while the records stay verifiable. Stored content is deleted after one year, or after seven years with the retention add-on (Team, £10 a month).

• Agent keys are generated on your machine and never leave it. Only public keys are registered, each with a proof that the registrant holds the private key. A key is replaced with signafaide keys rotate, signed by the old key, and signafaide keys export writes the list of your agents' public keys for an auditor, each entry signed by its own key.
• The service key signs batches, heads, anchors and exports. Its public history is published at /.well-known/signafaide-keys.json and is fixed by every public timestamp, so it cannot be rewritten later without detection.
• API keys are shown once and stored only as hashes. They can be rotated and revoked in the console.

The service runs on Google Cloud Platform in the London region (europe-west2), so records and account data are stored in the United Kingdom by default. Enterprise customers can choose EU residency. Google Cloud's infrastructure holds ISO/IEC 27001 certification and SOC 2 reports; those cover Google's data centres and platform, not signafAIde itself, which holds no certification of its own (see Testing done). Requests reach the service through Cloudflare, which terminates TLS at its edge, so Cloudflare can see traffic in transit, including stored content when you send it. Emails (sign-in links, invitations, alerts) are sent through Brevo. The sub-processors are listed on the sub-processors page.

Running the witness in your own environment is offered under an Enterprise contract: the witness server is proprietary software, licensed with that contract (self-host). What keeps you independent of us is open: the protocol specification, the SDKs and the three verifiers are Apache-2.0, and an exported verification pack verifies offline, without our service, for as long as you keep it.

• Uptime. We commit to 99.5% availability of the hosted witness each calendar month, which allows about 3 hours and 39 minutes of downtime in a 30-day month. It runs on a single machine, so a failure or maintenance of that machine counts against the figure. If we miss it in a month, we tell the affected organisation owners the measured figure and the cause. Service credits come only with an Enterprise order form.
• An outage never loses written records. While the witness cannot be reached, the SDK keeps each record in the local outbox and sends it, with its original time, when the witness is back (records up to 7 days old are accepted). Co-signing and the public timestamp are delayed, not lost. Tools wrapped in strict mode do not run until the witness answers.
• Your own disk matters. Records on a disk that is lost before they are sent (an ephemeral container that stops) are lost with it. The production guide lists what to persist. A new instance that continues a chain after such a loss writes a signed note saying so, which the verifier, the console and auditors see.

• Roles. Every member of an organisation is an Owner, Admin, Developer or Auditor. Auditors can read and export but change nothing; key and member changes need Developer or Admin.
• Single sign-on through your identity provider (OpenID Connect), on Enterprise. What each plan includes is on the pricing page.
• Auditor links are read-only, scoped to one project and environment, optionally to agents and dates, expire within a year and can be revoked at once.
• Audit logs. Key changes, exports, auditor links, plan changes and deletions are written to the organisation's audit log in the console.
• Staff access. The operator admin is served only behind Cloudflare Access in production, and every staff request that reads or changes data is logged.

What each party can and cannot do, and what signafAIde does not cover.

Limits to know:

• Unwrapped actions are not recorded. signafAIde records the tool calls you wrap with record() or wrapTools(). An action that skips the wrapper leaves no record, and nothing detects its absence.
• Backdating window. A record's own time is the agent's claim. The proven window is between its batch's drand round and its anchor's public timestamp; the console and the audit pack show both, and flag records sent late.
• Two parties. The guarantee that neither side can rewrite a record alone needs the witness to be run by someone other than the agent's owner. If you self-host the witness, have it run by a separate team or an independent operator, or the two signatures come from the same party.
• Integrity and timing, not correctness. A record proves what was decided and when, never whether the decision was right.

• Internal adversarial reviews. In November 2026 AIMETECH engineering ran two adversarial security reviews of the protocol, the server and the SDKs, using AI-assisted review: forged and tampered packs, records dropped or replayed, key and timestamp games, cross-project access, sign-in and single sign-on, and requests to internal addresses. The findings were fixed and each fix was checked against the review's own reproduction before this release. These were internal reviews, not an independent assessment.
• Three verifiers, one answer. The Rust, Python and TypeScript verifiers are run on the same packs, valid and tampered, and must give the same result for every check. The test vectors in the specification include one tampered pack per rule.
• Not yet done: an external penetration test or a certification audit. signafAIde holds no ISO/IEC 27001 certification and no SOC 2 report of its own. We will publish here when one is done.

• Notice. We give at least 12 months' notice before the service stops for all customers.
• Export. The export tools (verification packs from the console and the API, signafaide keys export) keep working throughout.
• Source release. If AIMETECH winds the service down, we release the witness server's source code under the Apache License 2.0, so you or anyone else can run it.
• Packs keep verifying. A verification pack you have exported checks offline with the open verifier, without our service, whatever happens to us.
• Ending one customer's contract. Without cause we can end a single customer's contract only on at least 90 days' notice, with a pro-rata refund of prepaid fees, and that customer can export for 90 days afterwards.

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

If you find a vulnerability, email [email protected] with the details and a way to reproduce it. We will confirm we received it and tell you what we do about it. We will not take action against good-faith research that avoids other customers' data and does not disrupt the service, and we will credit you if you wish once it is fixed.