Connections and grants
Understand connection ownership, directional permissions, and the boundary between shared context and product execution.
A connection is an organization-owned relationship between named Solarius products or services. A grant defines the resources, information categories, and direction that the relationship permits.
A custom integration is a registered customer-owned endpoint, such as a catalog or deployment system. It participates in approved connections using its integration ID and scoped service-account credentials.
Organization and installation identity
An Infra–Guard product connection links product organizations within the same Solarius organization. Each side records its product organization and installation identity. Matching organization names do not establish ownership.
Hosted-capacity delegation in Infra has its own local and hosted organization boundary. Guard edge enrollment has its own installation and edge entitlement. Those service connections retain their product-specific setup and grants.
Directional grants
Each direction has an explicit scope. Infra can share inventory for one project with a Guard asset group, while Guard shares security summaries for mapped assets back to Infra. Approval in one direction does not authorize the reverse direction.
A grant begins without selected resources or information categories. Scope expansion requires approval from the affected product administrator. A saved grant revision identifies the exact selection that the administrator approved.
Resource mappings
A mapping associates existing records, such as an Infra droplet and a Guard device asset. Each reference includes product, installation, organization, and resource ID. Names and addresses help you review a match; they do not establish it.
Removing a mapping removes the relationship without deleting either resource. Replacing a droplet requires a reviewed mapping for the replacement ID. For the procedure, see Map resources across products.
Product execution
Connector shares context; each product authorizes and performs its own changes. Guard approves response actions and records executor acknowledgements. Infra admits infrastructure changes and records operation outcomes.
For example, a Guard incident can identify an affected Infra droplet through its mapping. Restarting that droplet still requires Infra lifecycle permission. Closing the incident does not restart the droplet or release Guard containment.
Hosted and self-hosted connections
Product adapters run within their control planes. Activating a connection configures a service identity scoped to the approved grant. An operator's browser session is not the ongoing credential. Self-hosted adapters use outbound HTTPS and retain their installation identity across restarts.
Connector enrollment does not establish network routing between workloads. An Infra private network needs an explicit network path to another region. Guard edge protection requires traffic to traverse the admitted edge route.
Separate service components use their product deployment settings: Infra agent and Connector settings and Guard worker and Connector settings.