Protocol Systems
ProtocolIdentity
Identity protection, authentication, monitoring, permissions, and digital exposure management.
Product vision
What it is being built to do.
Identity is where digital and physical risk meet. An exposed home address, a reused credential, a data broker listing, and an over-permissioned account are different symptoms of the same problem: the surface a person or organization presents to the outside world is larger than they realize and changes without their involvement.
Protocol Identity is being built to make that surface visible and reduce it deliberately, rather than reactively after an incident.
Problems addressed
The conditions it is designed for.
01
Personal and organizational information is distributed across services no one is tracking.
02
Authentication practices vary across household members, staff, and business accounts.
03
Permissions accumulate and are rarely revoked.
04
Exposure is discovered after it is exploited rather than before.
Individually competent systems, procured at different times, produce a program whose weakest link is the space between them.
Core functions
Functions in development.
These describe design intent. Nothing listed here is available to purchase today, and the list will change as the product is built.
- 01Digital exposure assessment across public and commercial sources
- 02Authentication posture review for principals, family members, and staff
- 03Permission and access inventory
- 04Continuous monitoring for new exposure
- 05Removal and reduction workflows
- 06Coordination with Vault for credential handling
Ecosystem connection
How it connects.
Identity feeds the exposure picture into Platform and hands credential storage to Vault. Findings inform residential and travel planning under Residence and Command.
No product in the Protocol ecosystem is designed to be bought alone. Each one owns a domain and reads from a shared record of what is protected and who is accountable for it.
Bought as products
- Each system holds its own model of the environment
- Alerts arrive in separate consoles with no shared priority
- Integration is attempted after procurement
- Nobody owns the boundaries between systems
Designed as a system
- One record of what exists and who is accountable
- Signals resolved against a shared priority
- Interfaces specified before anything is bought
- Every boundary has a named owner
Intended audiences
Who it is designed around.
The environments below shaped the design. A family office coordinating several households and a distributed enterprise are different problems, and a product that pretends otherwise serves neither.
Design discipline
Protocol builds against a described environment rather than a feature list. The constraint is the same one that governs a well-made instrument: every part has a reason, and nothing is added because it demonstrates well.
Protocol Identity is in development. Protocol is talking to the people it is being built for.
Adjacent systems
What it works alongside.
Conceptual interface
An interface study, not a screenshot.
The panel below is an abstract study of the product's structure, drawn from its own function names. No interface has been built and no data is represented.
Identity
- Digital exposure assessment across public and commercial sources
- Authentication posture review for principals, family members, and staff
- Permission and access inventory
Related capabilities
The work this product supports.
Discuss this product.
Speak with Protocol about Protocol Identity — its development direction, the requirements it should meet, or the security program it would sit inside.