Secure Connections
The Secure Connection Service (SCS) must be installed and configured at the infrastructure level before any of the in-product features described here are available. IT administrators should complete the steps in Secure Connection Service Setup (Helm chart, S3 buckets, Master Key) first.
Secure Connections lets your organization exchange resources with partner registries over authenticated, encrypted channels. An outbound Sending Connection pushes data you own to a partner; an inbound Receiving Connection pulls data a partner pushes to you.
Navigation: Admin hub > Secure Connections (or go to /admin/secure-connections)
Visibility: The Secure Connections admin section is visible to organization administrators only.
For end users: Once a Sending Connection is configured here, users with Editor access on a file can share it with the partner organization through the file's Share dialog. The end-user-facing flow, including all certification prompts and the rules under which files are automatically removed from a connection, is documented in Secure Connections (User Guide).
Troubleshooting: For sync failures, authentication errors, and other operational issues, see Debugging Secure Connections.
Page Layout
The page is split into two tabs: Sending Connections and Receiving Connections. Each tab shows a sortable table of configured connections. Use the Active / All toggle (top-right of the tab bar) to include archived connections in the list.
Columns common to both tabs:
| Column | Description |
|---|---|
| (status icon) | Live sync health. Click to open the Sync status detail page. |
| About | Display name and description of the connection. Archived connections are visually dimmed. |
| Permitted Access | Whether the connection permits Edit access or View access for shared resources. See Allow Edit Access. |
| Shared ID | Opaque identifier exchanged with the partner platform. |
| Inbox / Outbox | The object store this connection reads from or writes to. |
| (actions) | Edit connection (opens the connection settings page) and Archive. |
Sending-only columns:
| Column | Description |
|---|---|
| Permitted Senders | Who may share over the connection. Click to edit. |
| Permitted Infosec Level | Maximum infosec classification allowed (only visible when infosec is enabled). |
Receiving-only columns:
| Column | Description |
|---|---|
| Permitted Recipients | Users granted access to files received through the connection. Click to edit. |
Connection Settings Page
Clicking Edit connection on a row (or a Permitted Senders / Permitted Recipients cell) opens the connection's settings page, which is split into three tabs:
- Details: name, description, object store, shared secret, and the connection's toggles. On a receiving connection, Infosec Level Mapping also lives here when infosec is enabled.
- Rules: Tag Rules on a sending connection, Transformations on a receiving connection.
- Permitted Senders (sending) or Permitted Recipients (receiving): who may share over, or access files received through, the connection.
Edits on any tab are staged locally and applied with Save changes in the page header; Discard drops them.
Add a Connection
Click Add Secure Connection (top-right), then choose Add Sending Connection or Add Receiving Connection.
Add a Sending Connection
A sending connection pushes resources from this platform to a partner.
- Fill in Name and optionally Description.
- Select an Outbox — the object store whose contents are sent to the partner. A warning appears if the chosen outbox is already used by another sending connection.
- Enter a Shared ID — a short identifier for the channel (letters, digits,
.,-,_only; no spaces). A random suffix is appended automatically on submit to guarantee uniqueness. - Enter and confirm a Shared Secret — treat this like a password. It is never retrievable after this dialog closes.
- Optionally assign Permitted Infosec Level (visible when infosec is enabled) — the maximum classification level allowed through this connection.
- Optionally turn off Allow all users to share with this sending connection. When off, only Permitted Senders may share files over the connection, and you are added automatically as an edit-level permitted sender.
- Optionally turn on Allow Edit Access — see Allow Edit Access. When on, users at the receiving organization can run jobs and edit their copy of resources specifically granted "Edit Access" through this connection.
- Check the certification box confirming this connection will share data with an external organization.
- Click Create.
After creation, a credentials screen shows the final Shared ID (with its appended suffix) and a masked Shared Secret — both copyable. Share these with the partner so they can configure the matching receiving connection. The secret cannot be retrieved again once you close this screen.
Which resources may flow through the connection is governed by Tag Rules, configured from the connection's Rules tab after creation.
Add a Receiving Connection
A receiving connection accepts resources pushed to this platform by a partner.
- Fill in Name and optionally Description.
- Select an Inbox — the object store where incoming data lands. A warning appears if the chosen inbox is already used by another receiving connection.
- Enter the Shared ID provided by the sending-side partner.
- Enter the Shared Secret provided by the sending-side partner.
- Click Create.
The creating user is automatically set as the initial permitted recipient of the new receiving connection.
Edit a Connection
Click the actions menu on a connection row > Edit connection to open the connection's settings page on its Details tab. Changes are staged as you edit and applied with Save changes in the page header; Discard drops them.
Editable fields for both kinds:
- Name, Description
- Inbox / Outbox — changing the store takes effect going forward; previously synced data stays in place. A confirmation checkbox is required before saving.
- Shared Secret — click Reset Secret (sending) or Update Secret (receiving) to stage a new value. The new secret is only applied when you click Save changes. For sending connections, confirm by entering it twice; for receiving connections, enter the new value provided by the sending side.
Sending-only editable fields:
- Permitted Infosec Level (when infosec is enabled)
- Allow all users to share with this sending connection: see Permitted Senders below.
- Allow Edit Access — see Allow Edit Access below.
Tag rules are edited separately on the connection's Rules tab; see Tag Rules.
The Shared ID is read-only after creation but can be copied from the Details tab.
Allow Edit Access
Using the Allow Edit Access toggle in the add/edit connection dialog, specify a ceiling for the maximum access the receiving organization may be granted over resources shared through this connection:
- Off: View access. Every file shared through the connection is view-only
- On: Edit access. Owners and Editors of files on the sending Istari instance may share a file at either view or edit. Files shared at edit can be run as jobs and revised on the receiving copy; those edits stay on the partner's copy and are not sent back.
Sending Side
Edit the connection and toggle Allow Edit Access on or off, then Save changes. The connection's Permitted Access updates accordingly. The change syncs to the paired receiving connection on the next sync cycle (typically 1–2 minutes).
Downgrade is blocked while editable files are shared. Turning Allow Edit Access off (Edit → View) is rejected while any file is still shared through the connection at Edit access. Lower the affected files to View access (or unshare them) first, then re-attempt the downgrade.
Receiving Side
On a Receiving Connection, the Allow Edit Access section is read-only. It reflects what the sending organization granted and cannot be changed locally:
- Edit access (granted): an Edit access badge with "The sending organization has granted edit access. You can run jobs on resources synced through this connection."
- View only (not granted): a View only badge with "The sending organization has not granted edit access. Resources synced through this connection are view-only."
Tag Rules (Sending Connections)
Tag rules decide, resource by resource, what may flow through a sending connection based on the control tags the resource carries. They replace the permitted control tag list and fixed transformation rules that sending connections used in earlier releases.
A ruleset is a list of checks plus a mandatory ELSE rule:
- Each check has an If a resource has condition over the resource's control tags (no tags, any of a set, all of a set, or any tag not in a set), an optional Then require clause, and a verdict of Allow or Block.
- An Allow check may also apply tag transformations (add, remove, or map control tags) to the copy that is sent. A Block check cannot apply transformations.
- Every check that matches a resource applies to it. A resource is allowed only when all of its matching checks allow; one matching Block check blocks the resource no matter what the other matches say. The order in which checks are listed does not affect the outcome.
- The transformations from all matching Allow checks are combined and applied together in a single pass (removes, then maps, then adds), so transformations from different checks interact: a map of tag X to tag Y from one check and a remove of tag X from another yield neither tag.
- The ELSE rule decides every resource that no check matched, so nothing passes through undecided.
Edit the Ruleset
- Open a sending connection and go to its Rules tab.
- Add a check with Add a Check, or open an existing row to edit it. Multiple rows can be open at once.
- Stage changes commits a row into your local draft. Deleting a row is also local until save.
- Save changes persists the whole ruleset. Discard drops every local edit.
Live shares guard the save. Saving a ruleset that would block a resource currently shared through the connection is rejected. Unshare the affected resources or adjust the rules first.
Test the Ruleset
Use Test ruleset on the Rules tab to evaluate a hypothetical set of control tags against the ruleset exactly as it appears on screen, including staged edits and edits still open in an editor. Nothing is persisted by a test. The result shows the verdict, the transformations that would apply, and every rule that matched. While an open edit is incomplete, Run test is disabled until the edit is finished or cancelled.
Transformations (Receiving Connections)
Transformation rules rewrite control tags on resources as they arrive through a receiving connection. All transformations matching a file are grouped and applied together in a single pass, in this fixed order regardless of the order they are listed: removes, then maps, then adds.
Open a receiving connection's settings page and go to its Rules tab. Transformations are presented in the same check-table layout as sending-side tag rules (an If a resource has condition and the transformations to apply), and edits are staged locally until you click Save changes in the page header; Discard drops them.
Rule Types
| Rule | What it does |
|---|---|
| Add Control Tag | Always stamps the chosen tag onto every synced resource. No predicate required. |
| Remove Control Tag | Always strips the chosen tag from every synced resource. No value required. |
| Map Control Tag | Replaces one tag with another on synced resources. |
Each rule requires a Description explaining why it exists.
- Predicate (Map, Remove): choose from the incoming tags sent by the partner platform.
- Value (Add, Map): choose from your organization's active local control tags.
- A warning is shown if any incoming tags are not covered by a Remove or Map rule. Files carrying an uncovered tag are skipped and recorded as per-resource failures (the sync completes as degraded) until a covering rule is added; other files continue to sync.
As part of the Shared Cybersecurity Responsibility Model, administrators are expected to make good-faith mappings from the sending platform's control tags to valid equivalent local tags.
Infosec Level Mapping (Receiving Connections)
When the sending platform uses a different infosec schema than yours, incoming resources carry classification levels your platform does not know. A receiving connection learns the sending platform's level catalog during sync, and administrators translate it from the Details tab of the connection's settings page (shown when infosec is enabled).
- Map each incoming level onto a local level of your own schema. Every incoming level at or below the sending platform's maximum must be mapped before resources are imported; the sync pauses until the mapping is complete.
- A mapping must target an active local level at or below your platform's maximum level. If a mapping later becomes illegal (for example the local maximum is lowered), the sync pauses until it is corrected.
- Incoming levels that disappear from the sender's catalog are pruned from the mapping automatically.
- Mapping is unavailable when both platforms use the same infosec schema, since no translation is needed.
Permitted Senders (Sending Connections)
A sending connection can restrict who may share files through it. Each sending connection has an Allow all users to share with this sending connection toggle:
- On: any user with Editor access on a file may share it over the connection.
- Off: only listed permitted senders may share. Everyone else is denied, with no administrator bypass.
Permitted senders are assigned one of two levels:
- Edit: may share files at either View or Edit access.
- View: may share files at View access only.
To manage the list, open the sending connection's settings page and go to its Permitted Senders tab (or click the Permitted Senders cell in the connections table). Search for users to add them, set each user's level with the View / Edit selector, and click Save.
When you create a connection with allow-all turned off, you are added automatically as an edit-level permitted sender so the connection is usable immediately. Connections created before this feature existed keep allow-all on, so pre-existing sharing is unaffected until an administrator turns it off.
Permitted Recipients (Receiving Connections)
Permitted recipients of a receiving connection (called owners in earlier releases) are granted access to every file that arrives through it, and may reshare those files with other users (resharing to another secure connection is not permitted). When a file has been shared with Edit Access, edit-level permitted recipients will be able to edit the file and grant edit access to other users.
Classification gating: Permitted recipients are not automatically assigned the infosec level or control tags carried by an incoming file. A permitted recipient whose own classification does not satisfy the file's infosec level, or who does not hold every control tag the file carries, will not see the file even though the connection grants the underlying view role. To make a file visible to a permitted recipient, an administrator must assign that user the matching infosec level and control tags through the Administrator Guide.
- Open the receiving connection's settings page and go to its Permitted Recipients tab (or click the Permitted Recipients cell in the connections table).
- Search for users by name and click to add them.
- Set each recipient's permission with the View / Edit selector; edit-level recipients can edit received files when the connection grants Edit Access.
- Remove a permitted recipient by clicking the remove button next to their name.
- Click Save.
Sync status
Each active connection displays a sync status icon indicating the health of its most recent synchronization:
| Icon | Meaning |
|---|---|
| Success | Last sync completed without errors. |
| Degraded | Sync completed with partial errors. |
| Failure | Sync failed. |
Click the icon to open the Sync status detail page (/admin/secure-connections/:kind/:connectionId/sync-status). For help interpreting sync events and resolving failures, see Debugging Secure Connections.
Sync status detail page
The page shows a paginated list of sync events for the connection, newest first.
- Each row shows how many resources were updated, a preview of the sync message, the timestamp, and the overall status badge.
- Click a row (or the chevron) to expand it and see per-resource status, resource IDs, and individual messages. Click any resource ID to copy it.
- Click a truncated message to open it in full in a dialog.
Use the With updates / All toggle to filter sync events. With updates (the default) shows only events where at least one resource was modified; All includes every sync event.
Revocation and Tombstoning
When a user unshares a resource from a Sending Connection, the connection:
- Stops sending updates for that resource.
- Emits a revocation signal to the partner.
On the paired Receiving Connection, the receiving platform honors that signal by tombstoning its downstream copy — deleting the copy's content and clearing its metadata, leaving an inert placeholder. The end-user-facing behavior is documented in Secure Connections (User Guide).
Feature timeline:
- Sending-side revocation — supported since the Secure Connection Service shipped in the 2026.05.01 release.
- Receiving-side tombstoning — the platform acting on that revocation, added in the 2026.07.01 release.
What Revocation Does and Does Not Do
Revocation tombstones the registered resource on the receiving platform, per revision. Every revision — including any the receiver added locally — is emptied of content, and the file's metadata is cleared. Content-bearing operations against a tombstoned resource or revision are refused with 410 Gone.
Revocation cannot remove data from the storage inbox. A Receiving Connection only parses data that has already been placed in an object-store Inbox.
- It does not reach back into the Inbox bucket the connection delivered through.
- It cannot delete data the partner exported, downloaded, or forwarded outside the platform.
- Propagating deletion into the Inbox bucket and outside of the platform is the responsibility of the transfer mechanism and the partner's own data-handling processes, respectively, not of the revocation signal.
Audit Logs
Revocation is auditable and observable through the same surfaces as every other sync activity:
- Audit logs — Each revocation the receiving side processes is written to the Secure Connection audit log:
- An informational entry when a downstream resource is successfully tombstoned, naming the upstream and downstream resource IDs.
- An error entry when a tombstone attempt fails.
- A no-op entry for a revocation of a resource that was never received.
- Sync status — Because revocation is re-emitted each sync cycle and retried idempotently until the tombstone succeeds, a pending or failed tombstone can surface across several consecutive sync events on the Sync status detail page. Expand a row to see the per-resource status and message; once the tombstone lands, subsequent syncs stop retrying it.
Archive a Connection
Archiving stops synchronization and hides the connection from the default (Active) view. It cannot be undone.
- Click the actions menu on a connection > Archive.
- Confirm in the dialog.
To view archived connections, switch the Active / All toggle to All. Archived rows are dimmed and their action menus are disabled.