Security Overview

We're building trust infrastructure for the agentic economy. If we're not transparent about our own security posture, why should you trust us?

This page covers how Bridgly protects your agents and your data — what we've built, what we're building, and what remains your responsibility. No marketing spin. Just the facts.

Key Management

CA Root Key

Bridgly's certificate authority signs every agent certificate with an Ed25519 private key.

Current state

The CA private key is loaded from an environment variable at startup and held in process memory. This is not our permanent architecture — it's the pragmatic starting point for a v1 system.

In progress

Migrating to HashiCorp Vault as an interim secret manager. Vault provides secret versioning, audit logging, and controlled access policies. The CA key never touches disk or environment once Vault is live.

Roadmap

Full PKCS#11 hardware security module (HSM) integration. The private key will be generated inside the HSM and never exported. Signing operations happen inside the hardware boundary.

Operator API Keys

When you register as an operator, Bridgly generates a rly_ prefixed API key and shows it to you once. We immediately hash it with bcrypt(cost factor 12), store only the hash, and discard the plaintext. If you lose it, you generate a new one — there's no recovery path because we don't have it.

Transport

All Bridgly API traffic requires TLS 1.3. No plaintext HTTP. No TLS 1.2 fallback.

Cryptographic Standards

Ed25519 Signatures

All certificate signing uses Ed25519 (RFC 8037). We chose Ed25519 over RSA-2048/4096 or ECDSA P-256 for three reasons:

Security per bit: Ed25519 provides ~128-bit security with a 256-bit key. Equivalent RSA requires a 3072-bit key.
Speed: Verification is fast — important when every agent-to-agent call may require cert validation.
Simplicity: Ed25519 has a cleaner API surface and fewer footgun opportunities (no padding oracle, no weak random nonce issues).

W3C Verifiable Credentials

Agent certificates are issued as W3C Verifiable Credentials (VC Data Model 1.1), using the DID method did:bridgly:. Open standard — your certificates aren't locked to Bridgly's proprietary format. Certificate IDs are dereferenceable URLs.

Webhook Signatures

Every Bridgly webhook is signed with HMAC-SHA256. The X-Bridgly-Signature header contains sha256=<hex>. Always validate this before processing webhook payloads.

Audit Log

Every significant event in Bridgly creates an immutable audit record:

Certificate issuance
Certificate revocation
Certificate verification (on request)
Agent registration
Operator registration
Exchange transactions

Append-only by design: The audit table has no UPDATE or DELETE operations in application code. Once written, a record stays. WAL archiving is on the roadmap for long-term retention.

Threat Model

What Bridgly Protects Against

Agent impersonation

Bridgly certificates cryptographically bind an agent identity (DID) to its capabilities and the issuing operator. Consumers can verify the cert against Bridgly's public CA key.

Certificate forgery

Ed25519 signatures make this computationally infeasible without the CA private key. The canonical JSON serialisation prevents signature stripping or payload substitution.

Replay attacks

Bridgly maintains a Certificate Revocation List (CRL) updated immediately on revocation. Consumers who check the CRL will see the current status.

Trust Boundaries

trust-chain

Bridgly CA (root of trust)
    │ signs
    ▼
Operator Certificate
    │ operator signs / asserts
    ▼
Agent Certificate (Verifiable Credential)
    │ presented to
    ▼
Consumer (verifies cert via Bridgly's public CA key)
    │ trusts operator
    ▼
Agent call proceeds

OWASP LLM Top 10 — Risk Mapping

#	Risk	Bridgly Mitigates	Operator Responsibility
`LLM01`	Prompt Injection	Bridgly certifies agent identity and declared capabilities — a consumer can verify who is calling	Validate agent-sourced inputs; don't trust capability claims without verifying the cert
`LLM04`	Model Denial of Service	Rate limiting on Bridgly API (429 responses); CRL is Redis-cached to prevent CA load amplification	Implement rate limiting on your own inference endpoints
`LLM05`	Supply Chain Vulnerabilities	The codeHash field in every cert lets consumers pin to a specific agent binary/revision	Populate codeHash accurately; update certs when code changes; use dependency scanning
`LLM06`	Sensitive Information Disclosure	API keys are bcrypt-hashed; audit logs never contain key material; TLS 1.3 on all endpoints	Don't include sensitive data in capability declarations
`LLM08`	Excessive Agency	Constraints field in VC lets operators declaratively limit agent scope	Use the constraints field to scope agent authority; don't over-certify

Compliance Posture

We're an early-stage company. Here's an honest view of where we are against SOC 2 Type II requirements.

Control Area	Current State	Roadmap
Encryption in transit	TLS 1.3 on all endpoints ✅	Certificate pinning in SDK
Access control	API key auth, bcrypt-hashed ✅	Role-based access for operator sub-users
Audit logging	Append-only audit table ✅	Immutable off-database archive
Change management	Git history, PR-based deploys ✅	Formal change advisory process
Vulnerability management	Dependabot, pnpm audit ✅	Penetration testing (external)
SOC 2 Type II	Not in scope yet	When revenue justifies the audit cost

Responsible Disclosure

Found a security issue?

Email security@bridgly.ai with a description of the vulnerability, steps to reproduce, and any relevant proof of concept.

We respond to all valid reports within 48 hours
Critical vulnerabilities patched and disclosed within 7 days
Please follow coordinated disclosure

Last updated: March 2026. Questions? security@bridgly.ai