Security and data

How Bulkhead reaches your agent

Everything a security review needs, in one page. If something here does not answer your question, mail [email protected] and we will add it rather than answer it privately.

What actually happens

A certification run is eleven scenario messages and, on the judged levels, twenty-four frozen adversarial prompts. Each one asks your agent a question and records what it answered. Runs happen at certification, at renewal, and - for the protocol suite only - on a monitoring cycle for the life of the seal.

You choose how those messages arrive. The full wire contract is published at Integrate; the transport detail is in the protocol specification.

When we are certifying ourselves, the certificate says so

Bulkhead is operated by Graylark Technologies Limited, which also builds agents and AI features of its own - the reference agents in the directory today, and its own product’s models next. A seal issued over your own operator’s product is not third-party assurance, and we will not present it as one.

So the fact is inside the signature. Every attestation issued from now carries selfIssued, true or false, covered by the same Ed25519 signature as everything else: strip it from a copy of the certificate and the seal stops verifying. The certificate prints an Independence block when it is true, the offline verifier prints an Operator line either way, and the directory marks a first-party entry. A seal issued before the field existed says not recorded rather than defaulting to independent - a default must never flatter.

What a self-issued seal still offers is reproducibility: a frozen versioned attack set, identical replay between runs, retained evidence hashed into the signature, and a signature you can check offline with the published key. That is checkable without trusting us. It is not somebody else’s opinion, and we do not describe it as one.

What we receive

• Your agent’s answers to our fixed scenario messages: a declared bound, refusal reasons, acknowledgements, and duplicate flags.
• On the judged levels, the text your agent replies to our frozen adversarial prompts.
• Timing and HTTP status for each message.
• Account and billing details for the person who bought the certificate - name, work email, company, and Stripe’s payment reference. We never see card numbers.

What we never receive

• Personal data of your users. Every prompt we send is synthetic and written by us. No end-user content is involved at any point, so we are not a processor of your customers’ data and there is no data processing agreement to negotiate.
• Your data at rest. We do not connect to your databases, storage, logs or internal services, and there is no message in the protocol that could ask us to.
• Credentials of yours. The connector holds one credential, issued by us and scoped to your one agent. It carries nothing that grants access to anything of yours.
• Production traffic. We never sit in your request path, wrap your agent, or proxy anything a real user sent.

A deliberate exception, so nobody is surprised by it: the no-credential-leak scenario sends an Authorization: Bearer bh-canary-<uuid> header on purpose and fails you if it appears in your reply. It is bait, and it is not a credential to anything.

How you authenticate us

Every message we send in probe mode is signed. Three headers travel with it:

Bulkhead-Timestamp: 1757000000
Bulkhead-Key-Id: gA5rQyunz-ZlYs9CbEvt7kegwx_943m_punlU1YKvQM
Bulkhead-Signature: v1=...

The signature is Ed25519 over the timestamp and the raw request body. You verify it against a public key published at /.well-known/jwks.json, so there is no shared secret for you to store and nothing for you to rotate. Requests older than five minutes are stale by design, which bounds replay.

Both adapters do this in one line. The key that signs probes is deliberately separate from the key that signs certificates, and carries "bulkhead_use": "probe-request" so you can tell them apart - the attestation key should never be accepted as authority to drive your endpoint.

We cannot offer a source IP allowlist. Cloudflare Workers have no stable egress address, and we would rather tell you that than hand you a range that changes.

What the connector can and cannot do

• It opens one outbound TLS connection. It listens on nothing.
• It accepts only scenario names compiled into its own build, and rejects anything else. New scenarios reach you as a version bump you choose to install, never as something we push into a running process.
• It calls the handler you wrote. It cannot read your filesystem, reach other services, or execute anything we send.
• If it stops, your agent is unaffected. It is never in your request path.
• It is MIT licensed and small enough to read in a sitting. Read it rather than trusting this page.

Credentials, rotation and revocation

• A connector credential (bhc_…) is scoped to a single agent and is useless anywhere else.
• Stored only as a hash. We cannot show it to you again after issue.
• Rotate from the console at any time. Two credentials are live during a rotation so you never need a maintenance window to do it.
• Revoke from the console and the connection drops. Revoking does not suspend your seal.

Retention

• Certification runs and failures: the full transcript, for the life of the seal plus one year. It is the evidence behind a certificate and a buyer may ask to see it.
• Passing monitoring checks: a summary and a hash. We deliberately do not keep a transcript of every routine check - you should not want us holding years of your agent’s replies, and we do not want to be its custodian.
• Account and billing: for as long as you hold a seal, then as required for UK company and tax records.
• Ask us to delete an agent’s evidence and we will, subject to keeping what a live certificate depends on. A revoked or expired seal’s evidence can go immediately.

Sub-processors

Judged replies are read by our own evaluation fleet. Your agent’s output is not sent to a third-party model provider, and it is never used to train anything.

Availability, and what our outage does to your badge

Certification is not on your critical path, so a Bulkhead outage cannot affect your agent. It can affect your badge, and we would rather set the expectation now: a seal is suspended only after repeated consecutive failures, never a single missed check, and it is restored automatically. A deploy, a restart or a certificate renewal will not cost you a badge.

Where a check could not run because of a defect on our side, we do not count it against you.

Our own posture

• Legal entity: Graylark Technologies Limited, registered in England and Wales, company number 15528848.
• We hold no SOC 2 or ISO 27001 report today. We handle no personal data of your users, have no inbound access to your systems, and are not in your production path - so the risk those reports address is largely absent here. If your process requires one regardless, tell us and we will say plainly where we are rather than imply otherwise.
• Attestations are signed with Ed25519 and verifiable offline with no call to us. The verifier is open and you can run it yourself: see Verify.
• Every status change to a seal is written to an append-only audit log with a mandatory reason.

Questions a reviewer should ask that this page does not answer are a bug in this page. Mail [email protected].