Technical Guide
Spheres ofinfluence.
Configure spatial zero-trust policies with Spheres of Influence. Define entry/exit policies, device restrictions, clearance requirements, and parameter overrides for operational contexts.
Overview
What is a Sphere of Influence?
A Sphere of Influence (SoI) is a spatial zero-trust policy boundary that defines who and what can operate within a given context. SoIs combine spatial geometry with access control, device policies, and operational parameters.
Unlike traditional network perimeters, SoIs are volumetric - they exist in three-dimensional space and can represent buildings, airspace, operational zones, or virtual regions. Entities and devices must satisfy SoI policies to operate within boundaries.
SoIs support hierarchical nesting, allowing sub-zones with more restrictive policies. A building SoI might contain floor-level SoIs, which contain room-level SoIs, each with progressively tighter controls.
Key Capabilities
Quick Start
Create a SoI in 5 Steps
Set up a Sphere of Influence to establish a spatial zero-trust boundary for your operations.
Navigate to SoI Management
Go to Spatial Ops → Spheres of Influence from the sidebar menu.
You'll see existing SoIs and their hierarchy on the overview page.
Create New SoI
Click "Create SoI" and enter a name and description for your zone.
Choose a parent SoI if creating a nested zone with inherited policies.
Define Spatial Boundaries
Draw the SoI boundary on the map or enter coordinates. Set altitude range if needed.
Use the polygon tool to draw complex shapes or import GeoJSON.
Configure Policies
Set entry policy, exit policy, device restrictions, and clearance requirements.
Start with less restrictive policies and tighten as needed.
Add Parameter Overrides
Configure operational parameters that apply within this SoI (velocity limits, altitude, etc.).
Overrides take precedence over asset defaults when operating in this zone.
Pro Tip
Use SoI templates for common configurations like "Training Zone", "Restricted Airspace", or "Secure Facility". Templates pre-configure policies and overrides based on best practices.
Access Control
Entry Policies
Entry policies determine how entities gain access to a Sphere of Influence. Choose the appropriate level of restriction based on operational security requirements.
Open
Any authenticated entity may enter without approval
Approval Required
Membership must be approved by SoI administrator before entry
Invite Only
Membership requires explicit invitation from existing member or admin
Closed
No new memberships allowed; existing members retain access
Access Control
Exit Policies
Exit policies control how and when members can leave a Sphere of Influence. Some operational contexts require controlled exit procedures.
Free Exit
Members may leave at any time without restriction
Cooldown Period
Exit allowed after configurable waiting period
Admin Approval
Exit requires administrator approval before processing
No Exit
Members cannot voluntarily leave; admin removal only
Device Management
Device Policies
Device policies control which types of devices can operate within SoI boundaries. Enforce equipment standards, capability requirements, and security certifications.
Any Device
All registered device types permitted within SoI boundaries
Profile Restricted
Only devices matching approved device profiles may operate
Clearance Required
Devices must have appropriate security clearance level
No Devices
No external devices permitted; personnel access only
Device Profile Binding
When using "Profile Restricted" policy, you must bind approved Device Profiles to the SoI. Device Profiles define equipment specifications, capability requirements, and certification standards. Only devices matching bound profiles may enter.
// Example: Bind device profiles to SoI
{
"soi_id": "soi_airspace_alpha",
"device_policy": "profile_restricted",
"allowed_profiles": [
"profile_uav_commercial",
"profile_uav_military_certified",
"profile_sensor_array_v2"
]
}Security
Clearance Requirements
SoIs can require minimum security clearance levels for access. Clearance is verified against entity credentials before entry is permitted.
| Level | Classification | Requirements |
|---|---|---|
| 0 | Public | No clearance required |
| 1 | Internal | Organizational membership required |
| 2 | Confidential | Background check required |
| 3 | Secret | Security investigation required |
| 4 | Top Secret | Full security clearance required |
Security Note: Clearance levels are inherited through SoI hierarchy. A child SoI cannot have a lower clearance requirement than its parent.
Configuration
Parameter Overrides
SoIs can override operational parameters for assets operating within boundaries. These overrides take precedence over default asset configurations.
Operational Parameters
max_velocityMaximum allowed velocity for vehicles/drones
max_altitudeAltitude ceiling for aerial operations
operating_hoursPermitted operational time window
noise_limitMaximum noise level permitted
Communication Parameters
rf_frequenciesAllowed radio frequency bands
encryption_requiredMinimum encryption standard
data_rate_limitMaximum data transmission rate
mesh_protocolRequired mesh networking protocol
Safety Parameters
min_separationMinimum distance between assets
geofence_bufferAdditional boundary buffer zone
emergency_rtbEmergency return-to-base threshold
weather_limitsWeather operating limits
Override Configuration
// Example: SoI parameter overrides
{
"soi_id": "soi_urban_ops_zone",
"overrides": {
"operational": {
"max_velocity": 15,
"max_altitude": 120,
"operating_hours": "06:00-22:00",
"noise_limit": 65
},
"communication": {
"encryption_required": "AES-256-GCM",
"data_rate_limit": 50
},
"safety": {
"min_separation": 30,
"geofence_buffer": 10,
"emergency_rtb": 20
}
}
}Membership
Membership Management
Track and manage entity membership within Spheres of Influence. Members can be users, devices, rigs, or other identifiable entities.
Membership Statuses
Full access to SoI resources
Awaiting approval or verification
Temporarily revoked access
Invitation sent, awaiting acceptance
Membership period has ended
Member Types
Human operators and personnel
Registered hardware and equipment
Unitized asset collections
Software services and APIs
Structure
SoI Hierarchy
Spheres of Influence can be nested to create hierarchical policy zones. Child SoIs inherit parent policies and can add additional restrictions.
Inheritance Rules
Child SoIs inherit all parent policies by default
Children can only add restrictions, not relax them
Minimum clearance propagates to all descendants
Parameter overrides merge with child values taking precedence
Example Hierarchy
API Reference
SoI Operations
Core API operations for managing Spheres of Influence programmatically.
/api/soiCreate a new Sphere of Influence with policies
{
"name": "Operations Zone Alpha",
"geometry": {
"type": "Polygon",
"coordinates": [...]
},
"altitude_range": { "min": 0, "max": 150 },
"entry_policy": "approval_required",
"exit_policy": "free_exit",
"device_policy": "profile_restricted",
"clearance_level": 2,
"parent_soi_id": "soi_base_campus"
}/api/soi/:id/membersList all members of a Sphere of Influence
// Response
{
"members": [
{
"entity_id": "user_123",
"entity_type": "user",
"status": "active",
"joined_at": "2024-01-15T08:00:00Z",
"clearance_level": 2,
"roles": ["operator", "viewer"]
}
],
"total": 42,
"active": 38
}/api/soi/:id/overridesUpdate parameter overrides for the SoI
{
"overrides": {
"max_velocity": 20,
"max_altitude": 100,
"operating_hours": "08:00-18:00"
}
}/api/soi/:id/check-accessCheck if an entity satisfies SoI access requirements
// Request
{
"entity_id": "device_456",
"entity_type": "device"
}
// Response
{
"allowed": true,
"checks": {
"clearance": { "required": 2, "actual": 3, "pass": true },
"device_profile": { "required": ["uav_certified"], "actual": "uav_certified", "pass": true },
"membership": { "status": "active", "pass": true }
}
}Best Practices
SoI Design Recommendations
Start Broad
Begin with a high-level SoI covering your entire operational area, then add nested zones for specific restrictions.
Use Profiles
Create reusable device profiles rather than configuring device restrictions per-SoI. This simplifies management.
Document Overrides
Parameter overrides can be complex. Document the reasoning behind each override for future reference.
Regular Audits
Review membership lists periodically. Remove inactive members and verify clearance levels remain current.
Test Boundaries
Use simulation mode to verify SoI boundaries before deploying to production. Check edge cases at boundaries.
Plan Hierarchy
Design your SoI hierarchy before implementation. Consider how policies will cascade through the tree.