Entrelid Framework
Request Demo
The Distributed Entity Framework: Entrelid
Beyond Identity-Based Access
A revolutionary approach to access management that mathematically eliminates identity as an access control mechanism, fundamentally transforming network security.
Why Entities Are Not Identities
Our distributed entity system represents a fundamental departure from identity-based architectures. Many system architects incorrectly assume entities are enhanced identities - they are not. Entities are existence markers that possess zero inherent data access rights.
Entity Simplicity
Entities are existence points with only: roles, groups, an EDID (Entity Distributed IDentifier), passcode, and encryption keys. Unlike identities, they grant no data access whatsoever.
Relationship Purity
RDIDs (Relationship Distributed IDentifier) establish mathematical relationships between entities. Without relationships, entities cannot access anything—not even discover what might exist to access.
Group Flexibility
Groups contain member documents with arbitrary operational parameters. This is not identity management—it's operational configuration within established relationships.
The Critical Distinction: Entities vs. Identities
Traditional Identity Systems
  • Identity = WHO you are
  • Identity alone grants baseline access
  • Permissions modify what identity can do
  • Compromised identity = compromised access
Entity-Relationship System
  • Entity = THAT you exist
  • Entity alone grants nothing
  • Relationships define all capabilities
  • Compromised entity = no access without relationships

The Key Insight: In traditional systems, identity IS the access mechanism. In our system, entities are merely labels—all access comes from relationships.
Entity Creation Flow: Existence Without Identity
The entity creation process intentionally avoids identity management concepts. Entities are existence markers, not access principals.
1
Give Entity a Label
e.g. User, Agent, Device, Service, or Group
2
Assign Role
Set hierarchical position (organizational structure only)
3
Set Group Memberships
Add to groups where operational parameters reside
4
Generate EDID
System creates unique internal existence marker
5
Generate Passcode & Keys
Establish authentication Passcode (proves entity, not access) and private data encryption keys
Critical: No permissions, no data access rights, no capabilities. The entity now exists but can do nothing without relationships.
The Mathematics of Relationships
Unlike identity systems where permissions are granted through policy, the distributed entity system establishes access through mathematical relationships defined by Relationship Distributed Identifiers (RDIDs).
Relationship Properties
  • Binary: Either exists or doesn't exist
  • Mode: Can be data read-only or read-write
  • Directional: Established from source to target
  • Cryptographic: Mathematically verifiable
  • Existence: Can have expiration attribute
  • Distributed: Not centrally stored or managed
Security Implications
When access is determined solely by the existence of a mathematical relationship, traditional security vulnerabilities disappear:
  • No permissions to escalate
  • No lateral movement paths
  • No identity to compromise
  • No centralized management to attack
Relationships transform security from a policy enforcement problem to a mathematical certainty. Without the correct relationship, access is not denied - it's mathematically undefined.
How Entity Relationships Create Security
In traditional systems, compromising an identity provides an attacker with a foothold to explore and move laterally. In the distributed entity system, compromising an entity yields nothing without also compromising its relationships which are undiscoverable.
Relationship-Based Access
Every access attempt requires a valid RDID that mathematically proves the relationship exists. Without the proper relationship, resources are not just inaccessible - they're invisible.
Zero Knowledge Proof
Entities can prove they possess valid relationships without revealing the relationship details, enhancing privacy while maintaining security.
Cryptographic Verification
All relationship validations use cryptographic operations that can be mathematically proven, eliminating trust dependencies.
Groups: Not Identity Management, But Operational Configuration
Groups are not managing "user attributes" or "identity properties." They define operational parameters within established relationships.
Key Group Characteristics
  • Groups are entities that form relationships with resources
  • Member documents contain operational parameters, not identity attributes
  • Parameters can be anything the application needs (no schema restrictions)
  • All changes versioned automatically
  • Groups can contain other groups (hierarchical operations)
Example: A "Trading_Desk_Alpha" group doesn't manage trader identities—it configures how entities operate within trading relationships.
Entity-Relationship Topology
Understanding this topology is crucial: We're not distributing identities, we're establishing mathematical relationships between existence points.
Core Entities
Users, AI agents, devices exist
Have EDID for reference
Zero inherent data capabilities
Groups
Contain operational parameters
Define how entities function
Not identity attributes
Resources
Protected data and services
Accessible only via relationships
Invisible without proper RDID
The Flow: Entities → Groups (via RDID) → Resources (via Group's RDID)
Practical Example: Trading Desk Implementation
To illustrate how the distributed entity system works in practice, consider a financial trading desk application:
Traditional Identity Approach
  • User identities with roles (trader, analyst, manager)
  • Permission sets defining allowed actions
  • Trading limits as user attributes
  • System manages identity + permissions + attributes
Entity-Relationship Approach
  • Trader entities exist (EDID only)
  • Relationship to Trading_Desk_Alpha Group
  • Group document contains operational parameters (limits, authorities, markets, etc.)
  • Trading platform has relationship with group, not individual traders
Example: When a trader needs increased limits, nothing about their entity changes—only the operational parameters within that group. The trader's existence remains separate from their trading capabilities.
Why Moving Beyond Identity Matters
Identity Elimination
Not enhanced identity management—complete removal of identity as access mechanism. Entities exist without implying access.
Mathematical Security
Access isn't "controlled" or "managed"—it's mathematically defined by relationship existence. No relationship = undefined access (not denied, undefined).
Operational Flexibility
Groups provide unlimited operational configurations without touching entity structure or compromising security boundaries.
Automatic Versioning
All operational changes tracked without affecting entity existence or relationship structure.
This architectural approach fundamentally transforms security from a management problem to a mathematical certainty, drastically reducing attack surface while improving operational flexibility.
Common Misunderstandings About Our Approach
What We're NOT Doing
  • NOT: Enhanced identity management
  • NOT: Distributed identity with better security
  • NOT: Identity federation or SSO improvement
  • NOT: Attribute-based access control (ABAC) on identities
What We ARE Doing
  • YES: Eliminating identity from access control
  • YES: Mathematical relationships as sole access mechanism
  • YES: Operational configuration separate from existence
  • YES: Binary security (exists/doesn't) not probabilistic
Zero Trust Without Identity Dependence
Traditional Zero Trust approaches still rely on identity as the starting point for access decisions. The distributed entity system achieves true Zero Trust by eliminating identity altogether.
1
Traditional Zero Trust
Verify entity, then apply least privilege based on entity attributes
2
Entity-Based Zero Trust
Verify entity existence, then check for mathematical relationship to resource
3
Operational Result
No permissions to manage, no identity attribute-based decisions, just relationship verification
This approach creates a fundamentally different security architecture where breaches become geometrically more difficult - an attacker must compromise both entities and their relationships, not just credentials.
Breaking the Symmetry of Traditional Security Models
Traditional security models suffer from symmetrical vulnerabilities: what administrators can configure, attackers can exploit. The distributed entity system breaks this symmetry by making security a mathematical property, not a configured state.
Traditional Vulnerability
If an administrator can grant access through the management plane, an attacker who compromises that plane gains the same capability.
Entity System Advantage
Even with full management access, an attacker cannot create valid mathematical relationships without the cryptographic keys of both endpoints.
This fundamental asymmetry creates defense-in-depth by default, not as an additional control layer.
Scalability Without Complexity
Traditional identity systems face exponential complexity as they scale. The distributed entity system scales linearly because relationships are independent of each other.
Traditional Scaling Challenges
  • Permission combinations grow exponentially
  • Role management becomes unwieldy
  • Group nesting creates inheritance complexity
  • Cross-domain access requires federation or trust
Entity-Relationship Scaling
  • Each relationship is independent
  • No permission combinations to manage
  • Group operational parameters don't affect security
  • Cross-domain access requires only relationship creation
This linear scalability means that large-scale implementations remain as simple to understand and secure as small ones - complexity doesn't grow with size.
Technical Implementation Considerations
Implementing the distributed entity system requires rethinking several aspects of your architecture:
Storage Strategy
Entities, relationships, and group documents are stored in a distributed database that supports versioning and cryptographic storage key derivation.
Resource Data Requests
Resource requests must validate relationship existence and RDID resource mode (read-only/read-write) before routing requests, not just authenticate identity.
Cryptographic Services
Robust key management for RDIDs and Entity data encryption keys is essential.
Relationship Verification
High-performance verification of relationships becomes a core service, often implemented with distributed caching mechanisms.
Moving Beyond Identity Management
Organizations must fundamentally reconceptualize access control, not just migrate identities to entities.
Entity Reconceptualization
Stop thinking "simplified identities." Entities are existence markers. All access logic moves to relationships and groups.
Relationship Restructuring
Replace identity-based permissions with mathematical relationships. Access becomes binary: relationship exists or doesn't.
Group-Based Operations
Move all "user attributes" and "identity properties" into group member documents as operational parameters.
Mental Model Shift
From: "Who is this and what can they do?"
To: "What relationships exist for this entity?"
Hypothetical Case Study:
Financial Services Implementation
A global financial institution implemented our distributed entity system to secure their trading platform across 12 countries and 4,500 traders.
Before Implementation
  • 26 security incidents annually from compromised identities
  • 3-5 day average for trader permission changes
  • Weekly emergency access approvals for missing permissions
  • 42% of traders had excess permissions due to role sprawl
After Implementation
  • Zero incidents from compromised entities
  • Same-day operational parameter updates
  • No emergency access needed - relationships clearly defined
  • 100% appropriate access - no concept of excess permissions
The key insight: By separating entity existence from operational capabilities, security improved while reducing administrative overhead by 78%.
Entrelid Framework: Our Technical Implementation
The Entrelid Framework is our reference implementation of the distributed entity system architecture, providing a complete set of services for entity management, relationship creation, and group operations.
1
Core Services
Entity creation and management, relationship establishment, cryptographic operations, and verification services.
2
Integration Layer
API gateways, SDKs, and connector libraries for common platforms, enabling easy integration with existing systems.
3
Operational Tools
Group management, operational parameter configuration, and analytical tools for relationship visualization and security analysis.
The framework is available as an on-premises deployment.
Security Proofs and Formal Verification
The distributed entity system isn't just theoretically more secure - it's mathematically provable.
Mathematical Proofs
Our architecture will be undergoing formal third-party verification, proving that:
  • Relationships cannot be forged without cryptographic keys
  • Entity compromise cannot lead to unauthorized access
  • Group parameter changes don't affect security boundaries
  • System-wide consistency is maintained even during network partitions
These formal proofs provide a level of security assurance that traditional identity systems cannot match, as they rely on proper configuration rather than mathematical certainty.
The Power of Eliminating Identity
Our distributed entity system derives its power from completely removing identity as an access control concept.
Entities mark existence, not identity
RDIDs create mathematical relationships, not permissions
Groups configure operations, not identity attributes
Documents enable flexibility without compromising security
The Paradigm Shift: We don't have a better identity system. We've eliminated identity from access control entirely. Entities exist. Relationships determine capabilities. Groups configure operations. Security becomes mathematical certainty, not probabilistic hope.