Protocol Systems
One security environment.
Security software is usually bought one problem at a time, which is why the resulting programs do not hold together. Protocol's products are being designed to share a model of what is protected and who is accountable for it.
The ecosystem
Eight products, one model.
Each product owns a domain. Platform holds the shared record the others read from and write to. Every product below carries its current development status.
The shared model
What each one owns.
Every product owns a domain and nothing else. Platform holds the record of what exists and who is accountable for it, and the others read from and write to that record rather than keeping their own copy.
- Platform
- The record itself — the people, properties, devices, identities, and systems in scope, and the named owner of each. Everything else is defined against it.
- Identity
- Who someone is and what that entitles them to, including the exposure that exists about them outside any system Protocol runs.
- Vault
- The documents and credentials themselves, and the record of who retrieved what and when.
- Communications
- The channels a principal and their staff use, and the boundary around what is said on them.
- Residence
- A property as a system: access, monitoring, devices, and the vendors who touch them.
- Command
- What is happening now — alerts, incidents, and the people assigned to them — read against everything above.
- AI Security
- Machine support for assessment and monitoring, applied to the same record rather than to a separate data set.
- Mobile
- The same environment reached from a phone, for people who are not at a desk when it matters.
Why an ecosystem
The seam is the product.
Eight capable tools from eight vendors is the normal arrangement, and it is where programs fail — not inside any one system, but at the boundaries between them, where each vendor reasonably assumes another party is handling it.
Assembled from products
- Each system holds its own list of people and properties, under its own names.
- Revoking access in one place leaves it standing in the others.
- An integration that stops passing events looks identical to one with nothing to report.
- Nobody owns the boundary between two systems, so nobody checks it.
Designed as one
- One list, one name per thing, read by every product that touches it.
- A change is made once and is true everywhere it applies.
- The connections between products are specified rather than discovered after purchase.
- Every boundary has a named owner, decided before it is under pressure.
Protocol is talking to the family offices, security leaders, and operators these systems are being built for.
Design discipline
The products are being built to share one model of what is protected and who is accountable for it. That shared model is the part the industry usually leaves out, and it is the part that determines whether a program holds together.
Development status
Nothing here is available to purchase today.
Protocol's products are in development. Each page describes design intent and the functions being built rather than delivered capability, and says so in the sentence rather than in a badge alone.
Advisory work — assessment, architecture, integration, and managed oversight — is engaged today on a per-client basis. The products are the long-term system that work will eventually run on.
Discuss the Protocol ecosystem.
Speak with Protocol about product direction, early access, integration requirements, or a security program the ecosystem is being designed to support.