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: avatar > Settings > Admin > Secure Connections (or go to /admin/secure-connections)
Visibility: The Secure Connections admin section is visible to 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.
Setting up your first connection? Configure partner sharing (Secure Connections) walks through both sides in order — creating the connection, handing the credentials to the partner administrator, and verifying that a shared model syncs.
Sharing Across Security Boundaries
Secure Connections support sharing between Istari instances operating at different platform maximum infosec levels, in either direction — from a higher environment to a lower one (high to low) or from a lower environment to a higher one (low to high).
A common example is a high-side environment releasing unclassified information to a low-side environment:
- Set up a Sending Connection from the high system to the lower system.
- Tag the resources to be shared at the appropriate infosec level (e.g.
UNCLASSIFIED). - Share the resources through the connection.
Your organization owns the process. Istari facilitates cross-boundary sharing but does not define or replace your organization's release process.
Customers sharing across security boundaries must define their own process and data security controls governing what data may cross, and are responsible for enforcing them.
Use the connection's:
- Permitted Infosec Level
- Tag Rules
as guardrails that back your process — for example, cap a high-to-low connection's Permitted Infosec Level so only resources tagged at or below that level can sync.
Infosec Compatibility Between Platforms
The two platforms on a connection do not need matching infosec configurations: the receiving platform judges only the sending connection's Permitted Infosec Level against the rules below.
| Sending side | Receiving platform: infosec disabled | Receiving platform: same schema | Receiving platform: different schema |
|---|---|---|---|
| Infosec disabled | Allowed | Allowed; resources arrive at your default level | Allowed; resources arrive at your default level |
Permitted level is US DoD UNCLASSIFIED | Allowed | Allowed | Allowed once the incoming level is mapped |
Permitted level is the lowest level of any other schema (e.g. AUS OFFICIAL) | Blocked | Allowed | Allowed once the incoming level is mapped |
| Permitted level is above the lowest level, at or below your max | Blocked | Allowed | Allowed once every incoming level at or below the permitted level is mapped |
| Permitted level is above your maximum level | Blocked | Blocked | Allowed once mapped; each incoming level must map onto a local level at or below your maximum |
A blocked same-schema sync fails on the receiving side with a message naming the cause and nothing is received; the fix is to lower the sending connection's permitted level or raise the receiving platform's maximum. A cross-schema sync that needs mapping pauses until the mapping is complete, then delivers on the next cycle. Within the same schema, a resource's level is preserved on arrival; across schemas it becomes whatever local level the mapping assigns.
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. Administrators can star connections they work with often and filter either list to their own starred connections; stars are personal to each administrator. The sync status shown for each connection refreshes about every 60 seconds.
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 or View access for shared resources. See Allow Edit Access. |
| Onward Sharing | Whether the receiving organization may share received files onward. See Onward Sharing. |
| 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 | Highest infosec level a resource may carry to be shared over the connection (only visible when infosec is enabled). Click to change it inline; see Permitted Infosec Level. |
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: Shared ID, the object store, Access Type, Onward Sharing, and the shared secret controls. When infosec is enabled, a sending connection also shows Permitted Infosec Level here, and a receiving connection shows Infosec Schema Mapping.
- 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.
Each tab saves independently — there is no single save for the whole page:
- Details and Rules stage your edits locally and contribute their own Save changes and Discard buttons to the page header. Whichever of the two you are on is the tab those header buttons act upon; Discard drops that tab's staged edits.
- Permitted Senders and Permitted Recipients have their own Save button within the tab itself, not in the page header. This is also what saves the Allow all users to share with this sending connection toggle.
- Name and Description are not on any tab. Edit them inline from the page title using the pencil beside the connection name; they save on their own as soon as you confirm, independently of either mechanism above.
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,
.,-,_and/only; no spaces). Append unique suffix to Shared ID is checked by default and appends a random suffix on submit to guarantee uniqueness; clear it to use the identifier exactly as you typed it. See Nested Shared IDs for how/is used. - Enter and confirm a Shared Secret — treat this like a password. It is never retrievable after this dialog closes.
- Assign Permitted Infosec Level (visible and required when infosec is enabled) — the highest infosec level a resource may carry to be shared over this connection. Create stays disabled until a level is chosen. See Permitted Infosec Level.
- 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.
- Optionally turn on Allow Onward Sharing — see Onward Sharing. Off by default; when on, the receiving organization may share files it receives over this connection onward over its own sending connections.
- 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.
Nested Shared IDs
A Shared ID may contain / to place the share under a subfolder of the outbox bucket — for example partner-a/models and partner-a/artifacts are two connections that share one bucket while keeping their manifests and content apart. Each segment between slashes must be a real name (. and .. segments are rejected). Give the partner the full slash-separated value; their receiving connection uses it exactly as typed.
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 Edit connection (pencil icon) on a connection row to open the connection's settings page on its Details tab (?tab=details). A link to the settings page with no ?tab= opens the Rules tab instead. Changes are staged as you edit and applied with Save changes in the page header; Discard drops them.
Name and Description are edited inline from the page title: click the pencil beside the connection name, edit the fields, and save with the check button or Enter. These save immediately rather than being staged behind Save changes.
Fields on the Details tab, staged until you save:
- Inbox / Outbox — changing the store takes effect going forward; previously synced data stays in place. A sending connection's outbox cannot be changed while the connection has active shares; the change is refused until those resources are unshared. Create a second connection on the new object store instead. A connection with no active shares can be re-pointed freely and publishes a fresh manifest into the new outbox on its next cycle.
- 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) — see Permitted Infosec Level below. Lowering it unshares resources already shared above the new level.
- Access Type — see Allow Edit Access below. Changing it from Edit to View downgrades active Editor shares.
- Onward Sharing — see Onward Sharing below. Turning it off revokes every onward share the receiving organization has made from this connection.
Allow all users to share with this sending connection lives on the connection's Permitted Senders tab and saves with that tab's own Save button; see Permitted Senders.
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.
Changes That Affect Shared Resources
Some edits cascade to resources already flowing through a connection: lowering Allow Edit Access, lowering the Permitted Infosec Level, saving Tag Rules that block an active share, turning off Onward Sharing, and archiving a connection. The platform previews the impact and asks you to confirm it before anything is written:
- The confirmation dialog states what the change does, how many resources it affects (for example, 3 active shares are blocked by the new rules and will be unshared), and what the receiving organization loses.
- When the preview reports no affected resources, an access, infosec-level, or tag-rule change saves immediately with no dialog. Archiving and turning off onward sharing always ask for confirmation.
- Cancel closes the dialog and leaves your staged edits in place, unsaved.
Unshares are delivered to the receiving instance as a revocation request; see Revocation and Tombstoning.
Allow Edit Access
Every connection carries a ceiling for the maximum access the receiving organization may be granted over resources shared through it. Set it with the Allow Edit Access switch when you add a sending connection, and change it afterwards with the Access Type control on the connection's Details tab:
- View: every resource shared through the connection is view-only. Updates to resources are still shared, but receivers cannot run jobs on or edit them.
- Edit: Owners and Editors of resources on the sending Istari Digital instance may share a resource at either view or edit. Resources 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
Open the connection's Details tab, set Access Type to Edit or View, 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).
Lowering Access Type to View downgrades active Editor shares. Changing the ceiling from Edit to View downgrades every resource currently shared through the connection at Edit access to View access. See Changes That Affect Shared Resources.
Receiving Side
On a Receiving Connection, the Access Type section is read-only. It reflects what the sending organization granted and cannot be changed locally:
- Edit (granted): "The sending organization has granted edit access. You can run jobs on resources synced through this connection."
- View (not granted): "The sending organization has not granted edit access. Resources synced through this connection are view-only."
Onward Sharing (Sending Connections)
By default a file that arrived over a receiving connection stays inside the receiving organization: its users may share it with each other, but not over their own sending connections. Allow Onward Sharing on a sending connection lifts that restriction for the files it sends. It is off by default; set it when you add the connection or change it later on the connection's Details tab.
When onward sharing is permitted:
- The receiving organization may share a received file over any of its own sending connections, subject to that connection's own guardrails (permitted senders, permitted infosec level, tag rules).
- An onward share is capped at the access level the file was received at — a file received at View can only be shared onward at View.
- Onward shares are revoked automatically when the original file is revoked, when the receiving connection is archived, or when you turn onward sharing off. Lowering a file's received access from Edit to View revokes its Edit-level onward shares; View-level onward shares stay in place. Each revocation reaches the next organization the same way any other revocation does; see Revocation and Tombstoning.
The receiving connection shows the sender's decision read-only; it is learned on the first sync after the connection is created or the setting changes.
Permitted Infosec Level (Sending Connections)
When infosec is enabled, a sending connection carries a Permitted Infosec Level: the highest infosec level a resource may carry to be shared over the connection. It cannot exceed the organization's platform maximum (see Infosec Levels). Set it in the add dialog, on the connection's Details tab, or inline from the Permitted Infosec Level column of the Sending Connections table.
Lowering the level unshares every resource currently shared above the new level. Before the change is saved, the platform reports how many shared resources will be unshared and asks you to confirm (see Changes That Affect Shared Resources). Each unshared resource is delivered to the receiving instance as a revocation request; see Revocation and Tombstoning.
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. Those tags are the need-to-know controls assigned to the Resource and to users; here they also decide whether the Resource may pass. See Control Tag. 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.
Saving unshares blocked shares. Saving a ruleset that blocks a resource currently shared through the connection unshares that resource automatically. Before the ruleset is saved, the platform reports how many active shares the new rules block and asks you to confirm; each unshared resource is then delivered to the receiving instance as a revocation request. A ruleset that blocks nothing currently shared saves without a prompt. See Changes That Affect Shared Resources.
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. The tags left on the received Resource are the same need-to-know controls used inside your organization: a user sees that Resource when they have a role on it and hold every tag it carries. A rule that adds or replaces a tag therefore changes who can see the Resource, so assign the resulting local tags to those users, including permitted recipients. See Control Tag.
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, under the column headers If a resource has and Apply transformations. (The sending-side table uses If a resource has, Then require, and With transformations.) Edits are staged locally until you click Save changes in the page header; Discard drops them.
Rule Types
| Rule | What it does |
|---|---|
| Add | Always adds the selected control tag to synced resources. |
| Remove | Always removes the incoming tag from synced resources. |
| Replace | Replaces the incoming tag with a local control tag on synced resources. |
Each rule requires a Description explaining why it exists.
- Predicate (Replace, Remove): choose from the incoming tags sent by the partner platform.
- Value (Add, Replace): choose from your organization's active local control tags.
- A warning is shown if any incoming tags are not covered by a Remove or Replace rule: "N incoming control tags need a check" and "The following incoming tags are not removed or replaced. Provide a mapping or syncing will fail." 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 Schema 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 Infosec Schema Mapping section on 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 connection's Permitted Infosec Level 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. Sharing a received file onward over one of your own sending connections is permitted only when the sending organization enabled Onward Sharing on their side. 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 Archive (trash icon) on the connection row.
- Confirm in the dialog.
To view archived connections, switch the Active / All toggle to All. Archived rows are dimmed and their row actions are disabled.