Secure Connections
Secure Connections let you share an individual resource (a model or an artifact) with a partner organization through a Sending Connection that an administrator has already configured. Once a resource is shared through a connection, the platform keeps the partner's copy in sync as you upload new revisions and produce new artifacts from it.
Each share carries an access level (either View access or Edit access) that controls what the partner can do with their copy. View access is read-only; Edit access lets the receiving organization run jobs on the resource and add their own revisions to their copy. The access levels you can pick are bounded by the connection's ceiling, which the sending administrator sets (see Per-File Access Level).
Secure Connections apply to models and artifacts only. Systems cannot be shared through a Secure Connection as a whole.
File size limit: Secure Connections cannot transfer individual files larger than ~2 GB. Files above this cap are rejected on the sending side and never reach the partner organization. Support for larger files is planned for a future version.
Files persist permanently: Once a file is received by a partner organization through a Secure Connection, the partner's copy has no expiration, TTL, or revocation. Removing the partner from the file's access list, archiving the file locally, or deleting it locally only stops future updates from being sent — the partner keeps every copy of the file (and its earlier revisions) that they have already received indefinitely.
Prerequisite: An organization administrator must configure at least one Sending Connection in the Secure Connections admin panel. Contact your admin if you do not see the controls described below.
Something not working? If a file is not appearing on the partner side or has stopped syncing, ask your administrator to consult Debugging Secure Connections.
See Which Partners a Resource Is Shared With
Open the resource's details pane on the Files page (or from a system snapshot). The Connections with Access row lists the partner organizations currently receiving this resource. If the resource is not shared with any partner, the row shows None.
Share a Resource with a Partner Organization
- Open the resource and click the Share button (share icon) in the resource's action bar.
- The Share <filename> dialog opens in user-sharing mode by default. Click Share with external connection (globe icon, top-right of the dialog) to switch to Secure Connections sharing.
- In the Add organization field, search for and click the partner organization you want to add. Only sending connections that you have not already added are shown.
- The selected connections appear under Connections with access (N). To remove one, click the remove button next to its name.
- For each connection that permits editing, set the access level (View or Edit) — see Per-File Access Level below.
- Review the certification box and check the required boxes (see Confirmation Prompts below).
- Click Share to save. A toast confirms External connection sharing updated.
To switch back to sharing with internal users, click Share with users (people icon, bottom-left).
Required role: Editor or above on the resource.
Confirmation Prompts
Because Secure Connections send data to an external organization, every change that adds or removes a partner — or that pushes new content to one — must be explicitly confirmed before it can be saved.
The confirmation always appears as an amber-bordered certification box inside the dialog, with a checkbox you must tick before the action button enables.
When Adding a Partner
The box lists each partner that will gain access:
This resource will be shared with:
- Partner Org A
- Partner Org B
Confirm External Organization(s) will gain access to this model.
The subject ("this model", "this artifact", "this revision", or "any artifacts produced by this tool run") changes depending on the action.
When Removing a Partner
The box presents a checkbox describing what the partner retains:
Confirm External Organization(s) will retain their copy of this model and will stop receiving new updates.
Removing a partner from a resource's access list does not delete any data the partner has already received — it only stops future synchronization.
If your change adds and removes partners in a single save, both checkboxes are shown and both must be checked.
Per-File Access Level (View vs. Edit)
When you add a connection in the share dialog, that share gets an access level that determines what the partner can do with their copy:
- View access (eye icon) — the partner's copy is read-only. They can view it but cannot run jobs against it or add revisions.
- Edit access (pencil icon) — the partner can run jobs on their copy and add their own revisions to it. Their edits stay on their copy; they are not sent back to you.
The selector that appears for each connection depends on the connection's Permitted Share Level, which your administrator sets on the connection:
- If the connection permits editing, a View access / Edit access dropdown appears for that row, defaulting to View access.
- If the connection only permits viewing, the row shows a locked View access badge (with the tooltip "This connection only permits view access.") and no selector.
When you grant Edit access, the certification box heading reads "These External Organization(s) will gain edit access:" and you must confirm that those organizations will be able to run jobs and edit their copy of this resource. Changing a share's level re-requires confirmation.
Re-opening the share dialog shows each connection under Connections with access at its saved access level.
Actions That Automatically Push Data to Partners
Once a resource is shared through a Sending Connection, these actions automatically propagate the result to every partner the resource is shared with. Each one shows the same certification box before it can complete:
| Action | Certification subject | Where it appears |
|---|---|---|
| Upload a new revision of the resource | this revision | Upload Version dialog |
| Run a function that produces artifacts | any artifacts produced by this tool run | Function panel on the resource page |
| Extract artifacts from a system snapshot | any artifacts produced by this tool run | Extract <filename>? dialog from a system snapshot |
In every case, the action button (Upload, Execute Function, Extract) stays disabled until the certification checkbox is ticked. If the resource is not shared with any partner, the certification box is not shown and the action proceeds normally.
Finding Artifacts Shared to You Individually
On the receiving end, an artifact that is shared on its own — without its parent model — does not appear in the default Files view, which lists models grouped with their child artifacts. You can still find them via the global Search by file name.
Working with Resources Received from a Partner
When a partner shares a resource with you, what you can do with your copy depends on the access level they granted:
- View access — the resource is read-only. Create Job, Extract, and Add Version are disabled, with a tooltip explaining the resource is view-only.
- Edit access — you can run jobs on your copy and add your own revisions. The revision list shows a plus (+) button to add a revision, and any artifacts or jobs you create stay local to your instance.
Local vs. Remote Revisions
On an editable received resource, each revision in the versions list carries a source icon so you can tell where it came from:
- A router icon marks a remote revision synced from the partner (tooltip "Source: <connection name>").
- A home icon marks a local revision you added on your own instance (tooltip "Revision local to this istari instance").
As the partner uploads new revisions on their side, they continue to sync in and appear with the router icon alongside your local revisions.
Lineage
Open the Lineage tab in the resource details panel to see provenance. A remote-sourced revision connects to a synthetic Receiving Remote source node (dashed border, router icon) through an edge labeled "synced from", and the revision you are viewing is marked as the anchor. Jobs you run on your copy and the artifacts they produce appear in the same graph as the usual resource → job → artifact chain.
Cases Where a Resource Is Automatically Unshared
Sending Connections are governed by two limits an administrator sets when configuring the connection:
- A Permitted Infosec Level — the maximum classification the connection allows.
- A set of Permitted Control Tags — only resources carrying all the required tags are eligible.
Whenever the platform detects that a resource no longer fits within these limits, the resource is removed from that connection automatically. This can happen either by changing the resource or by changing the connection.
1. The Resource Outgrows the Connection
A resource is removed from a connection when one of these changes makes the resource ineligible:
- The resource's infosec level is raised above the connection's Permitted Infosec Level.
- A control tag the connection does not permit is added to the resource.
When this happens:
- The partner organization keeps the copy of the resource (and any earlier revisions) it has already received, but stops receiving any further updates from this connection.
- Other Sending Connections whose limits still cover the resource's new classification continue to sync as normal.
- The Connections with Access row on the resource's details pane updates to reflect the new set of partners.
2. The Connection Tries to Tighten Past Its Shared Resources
When an administrator edits a Sending Connection in the admin panel and saves, the change is blocked if it would leave any currently shared resource outside the connection's new limits. Specifically:
- Lowering Permitted Infosec Level below the level of the highest-classified resource currently shared through the connection is blocked.
- Removing a Permitted Control Tag that any currently shared resource requires is blocked.
The save fails with an error toast describing the conflict; no resources are unshared as a side effect of an admin tightening a connection.
To complete the change, the resource owner must first unshare the affected resources from the connection, then re-attempt the edit.