Skip to main content
Version: 2026.08

2026.08.01 Release Notes

Download installers, container images, Helm charts, and other release assets from the Istari Customer Portal.

Breaking Changes

Jobs now run only the module they name

Breaking Change

A job's function is now resolved against the module the job names. If that module is not installed on the agent — or is installed without a variant matching the job's tool, tool version, and host operating system — the job is rejected with FunctionNotFoundError rather than run against a same-named function from a different module.

Previously the agent matched a job's function on function name, tool, tool version, and operating system only, ignoring the module the job named. When two installed modules published the same function name, which one ran was decided by the order the modules happened to load — so a job could be served by the wrong module with nothing to indicate it had been. Jobs that were resolving that way now fail instead of returning results produced by the wrong module.

What to check before you upgrade

  • Look for a function name published by more than one installed module. On each agent, any function name that appears in more than one installed module is a candidate for having resolved to the wrong module. Jobs submitting that function keep working only if the module they name is the one installed and matching.
  • Confirm the module each job names is installed on the agents that will run it, with a variant matching the job's tool, tool version, and host operating system. A job naming a module that is not loaded is now rejected instead of re-routed to another module.
  • Upgrade the registry service before the agent in each namespace. This release also stops the platform from creating a job that no agent can run, refusing the submission instead (see Jobs that no agent can run are refused instead of stalling under Istari Platform). That screening arrives with the registry service, and it is what keeps an unrunnable job from reaching an agent in the first place. A namespace running an upgraded agent against an earlier registry service gets the agent's fail-closed behavior downstream without the screening upstream, and will see new FunctionNotFoundError failures on jobs that were created and should not have been. Because agents are expected to update with every release, plan this ordering into every namespace rather than treating it as an edge case.

Assets

Docker Images

  • Registry Service: istaridigital.jfrog.io/customer-docker/registry-service:11.2.0
  • Secure Connection Service: istaridigital.jfrog.io/customer-docker/secure-connection-service:11.2.0
  • Frontend Service: istaridigital.jfrog.io/customer-docker/frontend-service:8.38.1
  • MCP Service: istaridigital.jfrog.io/customer-docker/mcp-service:0.8.0
  • Identity Service: istaridigital.jfrog.io/customer-docker/identity-service:1.2.3
  • Dgraph SEC: istaridigital.jfrog.io/customer-docker/dgraph-sec:v25.3.7-sec.0.2.2
  • SpiceDB: istaridigital.jfrog.io/customer-docker/istaridigital.com/spicedb-fips:v1.51.1
  • SpiceDB Operator: istaridigital.jfrog.io/customer-docker/istaridigital.com/spicedb-operator-fips:v1.24.0
  • Zitadel (main image): istaridigital.jfrog.io/customer-docker/istaridigital.com/zitadel:v3.4.7
  • Zitadel (setup job): istaridigital.jfrog.io/customer-docker/istaridigital.com/kubectl-iamguarded-fips:1.33.9

Note: The SpiceDB, SpiceDB Operator, and Zitadel images listed above use Chainguard hardened images. Chainguard images are minimal, security-hardened container images with significantly reduced CVE exposure.

  • NATS images (bundled with the NATS subchart in the Istari-Platform Chart; tags pinned by the chart):

    • NATS Server: istaridigital.jfrog.io/customer-docker/istaridigital.com/nats-fips:2.14.1
    • NATS Config Reloader: istaridigital.jfrog.io/customer-docker/istaridigital.com/nats-server-config-reloader-fips:0.23.0
    • NATS Prometheus Exporter: istaridigital.jfrog.io/customer-docker/istaridigital.com/prometheus-nats-exporter-fips:0.19.2
    • NATS Box: istaridigital.jfrog.io/customer-docker/istaridigital.com/nats-box-fips:0.19.5
  • Other bundled images (pinned by the Istari-Platform Chart):

    • Jaeger: istaridigital.jfrog.io/customer-docker/istaridigital.com/jaeger-fips:2.20.0
    • Caddy (API Gateway): istaridigital.jfrog.io/customer-docker/istaridigital.com/caddy-fips:2.11.4

Helm Charts

  • SpiceDB Operator: helm pull --repo https://bushelpowered.github.io/spicedb-operator-chart spicedb-operator --version 2.6.0
  • Zitadel: helm pull --repo https://charts.zitadel.com zitadel --version 8.13.4
  • Istari-Platform Chart: helm pull oci://istaridigital.jfrog.io/customer-charts/istari-platform --version 5.5.0 --username ${ISTARI_ARTIFACTORY_USERNAME} --password ${ISTARI_ARTIFACTORY_PASSWORD}
  • Zitadel Configurator: helm pull oci://istaridigital.jfrog.io/customer-charts/istari-zitadel-configurator --version 1.10.0 --username ${ISTARI_ARTIFACTORY_USERNAME} --password ${ISTARI_ARTIFACTORY_PASSWORD}

SDK Clients

Agent

CLI

Integrations

Updates for the August 2026 Release

Module NameVersion
C-Infinity AutoAssembler Module1.0.2
Dassault Systèmes 3DExperience ENOVIA1.6.0
Dassault Systèmes Cameo Enterprise Architect4.4.3
Google Workspace1.3.3
IBM Rational DOORS Module1.3.1
Jira & Confluence Data Extraction Module1.2.2
Luminary Cloud CFD1.1.2
Microsoft Office 3651.6.1
Microsoft Office Word2.3.11
Open PDF1.7.10
Open Spreadsheet2.3.13
SOLIDWORKS (@istari)1.0.0
SysGit SysML v2 Tools1.0.2
Zoo.dev1.0.4

All Compatible Modules

Click to expand full module compatibility list for the August 2026 release of the Istari Platform
ModuleVersion
ANSYS HFSS1.1.2
Atlassian Jira1.0.9
C-Infinity AutoAssembler Module1.0.2
Dassault Systèmes 3DExperience CATIA (v6)1.4.2
Dassault Systèmes 3DExperience ENOVIA1.6.0
Dassault Systèmes Cameo Enterprise Architect4.4.3
Dassault Systèmes CATIA V52.5.6
Google Slides0.2.3
Google Workspace1.3.3
Hexagon MSC Nastran2.4.7
Hexagon Nastran Extract2.4.10
IBM Rational DOORS Module1.3.1
Jira & Confluence Data Extraction Module1.2.2
Luminary Cloud CFD1.1.2
MathWorks MATLAB (Base)2.3.7
MathWorks MATLAB Simulink1.3.10
Microsoft Office 3651.6.1
Microsoft Office Excel2.4.3
Microsoft Office PowerPoint1.1.2
Microsoft Office Word2.3.11
nTop0.4.11
Open CAD1.1.8
Open PDF1.7.10
Open Spreadsheet2.3.13
Open SysML1.0.10
Open Text1.0.10
PTC Creo Parametric3.3.4
Siemens NX1.5.3
SOLIDWORKS (@istari)1.0.0
SysGit SysML v2 Tools1.0.2
Zoo.dev1.0.4

Change Log

Istari Platform

New Features

  • Teamwork Cloud single sign-on. Users can sign in to Dassault Systèmes Teamwork Cloud with their own account through the browser, so Teamwork Cloud jobs (such as Cameo model extraction) run with each user's own permissions instead of a shared login. Supports TWC 2022x and 2024x. See App Integrations.
  • Easier setup for connected applications. Administrators connect an external application (Teamwork Cloud, Google Drive, Microsoft 365, PTC Windchill) in one guided step and can test the connection before saving. Users run jobs against these applications with either a shared organization account or their own personal sign-in, chosen when the job is launched. See App Integrations.
  • IBM DOORS Next connections. The platform can now connect to IBM DOORS Next and other Jazz-based tools. Users link their own account through a browser sign-in, or administrators set up a shared connection for the organization. See App Integrations.
  • Limit who can use an integration. Administrators can restrict a connected application or shared account to users holding specific control tags. See Control Tags.
  • Secure Connection revocation. Unsharing a resource from a Secure Connection now revokes it on the receiving side: the partner's platform tombstones its copy, deleting the content and clearing the metadata. Revocation cannot remove data already exported or downloaded outside the platform. See Secure Connections (User Guide) and Secure Connections (Admin Guide).
  • System and Resource UI Improvements
  • Secure Connections: translate partner classification levels. When a partner organization shares files under a different infosec schema, administrators now map each incoming level onto a local level from the receiving connection's settings, and the platform translates resources as they arrive. Files are not imported until every incoming level is mapped. See Infosec Level Mapping.
  • Secure Connections: rule builder for sending connections. Permitted control tags and fixed transformations are replaced by a set of allow or block checks over a resource's control tags. Every matching check applies to a resource, allow checks can also rewrite tags on the copy that is sent, and a final catch-all rule decides anything the checks miss. See Tag Rules.
  • Secure Connections: test a ruleset before saving it. The rule tester evaluates a hypothetical set of control tags against the ruleset exactly as it appears on screen, including unsaved edits, and shows the verdict, the transformations that would apply, and every rule that matched, all without persisting anything. See Test the Ruleset.
  • Secure Connections: choose who may share over a connection. A sending connection can now restrict sharing to a list of permitted senders, denied by default with no administrator bypass, or stay open to every user with a single toggle. The connection's creator is seeded as the first permitted sender. See Permitted Senders.
  • Secure Connections: owners are now permitted recipients. The receiving side's owner role is renamed throughout the product to make its purpose clearer: permitted recipients are the users granted access to the files received through a connection. See Permitted Recipients.
  • Secure Connections: steadier syncs. A sync now skips only the files it cannot yet cover instead of failing outright, reports a degraded status when it overruns its interval, and revoked resources no longer briefly report as synced. Caching and other performance improvements reduce sync overhead.
  • AI chat improvements
  • Expiration dates for access keys. Generating an access key — for a user or an agent — now sets an expiration date: 30, 90, or 180 days, one year (the default), or a custom date. See Settings — Keys.
  • No new Personal Access Tokens. With the Identity Service enabled, the platform no longer issues new PATs — generate an access key instead: an ES384 keypair with an expiration date, where the private key is held by you and never stored by Istari. Existing PATs are unaffected and continue to work until revoked; see the PAT → Key Exchange guide to migrate.
  • Name the module when two modules publish the same function — Model job submission accepts an optional module_name parameter identifying the module that publishes the requested function. Supply it when more than one installed module publishes the same function name: without it, a submission pinned to a function version fails as ambiguous, and an unpinned one resolves to whichever module sorts first. Existing submissions are unaffected — the parameter is optional and omitting it preserves the previous behavior.

Bug Fixes

  • Multi-tenancy: the module registry is now isolated per tenant. This release closes a set of gaps where module registry data and actions were visible or available across tenant boundaries. No configuration change is needed; sharing a module with another tenant continues to work by explicit grant on its functions.

    • Customer admins see only their own tenant's modules and functions — A customer admin browsing the catalog saw modules and functions belonging to other tenants. Listings and reads now return only your own tenant's records and modules explicitly shared with you.
    • Module versions can be listed and read only within your tenant — Module versions could be listed and read across tenant boundaries. Version listings and reads now carry the same tenant scoping as module listings.
    • Search returns only your own tenant's modules and functions — Search results included other tenants' modules and functions. Results are now limited to records your tenant can see.
    • Tool and author listings return only your own tenant's records — Listings of tools, tool versions, and module authors returned every tenant's entries, including author names and email addresses. They now return only the records visible to your tenant.
    • A shared tool includes only your own tenant's functions — Requesting a tool with its functions included returned functions from every tenant using that tool. It now includes only the functions your tenant can see.
    • Only customer admins can publish or update a module — Any user could publish a new version of any module, including Istari's platform modules, and agents would run it. Publishing and updating modules now requires the customer admin role.
    • Module names are now unique per tenant instead of globally — A failed publish could reveal that another company already owned a module name. Names are now scoped to the publishing tenant, so two tenants can each own a module with the same name.
    • Only customer admins can create or update shared catalog records — Tools, operating systems, and author records accepted creates and updates from any user, with no authorization check. These writes now require the customer admin role.
    • An agent with no tenant matches no tenant's jobs — An agent registered without a tenant was treated as belonging to all of them and could claim any tenant's jobs. It now matches none.
    • Agents list pending jobs only within their own tenant — Agents could list every tenant's PENDING jobs through the general jobs listing. The listing is now scoped to the agent's own tenant.
  • Jobs that no agent can run are refused instead of stalling — When the platform could not find the requested function installed on an eligible agent, it retried the search with no tenant, agent pool, or assigned-agent scoping at all and queued the job against whatever function version that search returned — creating a job that no agent would ever claim and that sat at PENDING indefinitely. The retry now keeps every scope and relaxes only whether the agent is currently responsive.

    • Submission fails with 404 when no agent in your tenant has the function version installed for the operating system the job targets. Callers that submit jobs programmatically see that response at submission time instead of receiving a job id that never progresses.
    • A job whose capable agent is briefly quiet, or freshly registered, still queues normally.
    • A job pinned to a specific agent or agent pool now reports a bad assignment as such — an agent in another tenant, an archived pool, or a pool you are not a member of — rather than reporting the function as unresolvable.
  • Job-produced files and artifacts now show who submitted the job — Files, artifacts, and models produced by a job are uploaded under the agent's own machine identity, so their Created by field read "Unknown user". The file and artifact details pane and the Versions panel now resolve the creator to the person who submitted the producing job, alongside a via job link to that job. Where a resource cannot be traced back to a job, the agent's display name is shown instead of "Unknown user".

Istari Digital Agent

New Features

  • IBM / Jazz integrations. The IBM Rational DOORS Module (1.3.1) can now extract Rhapsody Model Manager models, and signs in to the Jazz server with the account chosen when the job is launched.

  • Crypto self-test at startup, and a --crypto-check diagnostic — The agent now verifies its bundled cryptography at startup — a SHA-256 known-answer test, an AES-256-GCM round trip, and the RSA-OAEP round trip used for secrets — and logs one line with the result. If a primitive fails, the agent logs the failing primitive, the current OPENSSL_CONF / OPENSSL_MODULES / OPENSSL_ENGINES / OPENSSL_CONF_INCLUDE values, and remediation steps, then keeps running so it stays visible in the platform.

    The same self-test is available on demand as istari_agent_<version> --crypto-check. It prints the OpenSSL version and environment the agent actually loaded and exits 0 when every primitive passes, or nonzero identifying which one failed. Run it and send the full output when reporting a failure that looks like a bad key or a corrupted secret (for example, a function auth secret that cannot be decrypted) — it names the broken primitive directly. It loads no configuration, starts no GUI, and unlike --fips-check makes no FIPS assertions, so it passes on standard builds and non-FIPS hosts.

Fixes

  • Module failures now say what actually went wrong — When a module process exits nonzero, the failed job's status message now carries the process exit code and the last non-empty line of the module's standard error, for example Process exited with code 1: ZeroDivisionError: division by zero, instead of a generic "Process exited with an error." For the common case there is no longer any need to download the job's stdout and stderr artifacts to find the cause. These messages appear wherever job failure messages already do — the Job Details status history, the Activity panel, and the SDK.
  • Host OpenSSL environment variables no longer break the agent's bundled cryptography — Other software installed on the same machine can set OPENSSL_CONF, OPENSSL_MODULES, OPENSSL_ENGINES, or OPENSSL_CONF_INCLUDE machine-wide, pointing at its own OpenSSL directory (IBM Rational tools are a known case). The agent's bundled OpenSSL honored those values, loaded no usable algorithm providers, and every crypto operation failed — surfacing only as an inability to decrypt a secret. Packaged agent builds now clear those four variables at startup, before the bundled crypto stack initializes, and print one line naming what was removed. Processes the agent launches inherit the cleared environment, so a tool that genuinely needs one of these variables should have its module wrapper set it explicitly. Setting ISTARI_AGENT_OPENSSL_USE_HOST_ENV=1 keeps the host values instead; that passthrough is best-effort and unsupported.
  • Jobs run the module they name — The agent now resolves a job's function against the module the job names, and rejects the job when that module is not installed or has no matching variant, instead of running a same-named function published by a different module. This changes the outcome of jobs that previously resolved to the wrong module — see Jobs now run only the module they name under Breaking Changes for what to check before upgrading.
  • Agents give up a lost claim cleanly — When a job reached a terminal state between being dispatched and being claimed, the platform rejects the claim. The agent recognized only the rejection for a job that had already failed, so a job that had already completed or been canceled produced an unhandled error instead of the agent releasing the job and returning to idle. All three terminal states are now handled the same way.

Istari Digital CLI

Fixes

  • A clearer failure when creating an agent token with the Identity Service enabledstari agent create token creates a Personal Access Token, which the platform no longer accepts once the Identity Service is enabled. The command previously sent the request anyway and surfaced the platform's rejection. It now stops before contacting the platform and points to stari key exchange --agent, which issues an Access Key instead. Behavior is unchanged when the Identity Service is disabled.

Integrations

  • Dassault Systèmes 3DExperience ENOVIA 1.6.0 — Logical Item mutate/delete (update_log_item, update_log_instance, delete_log_item, delete_log_instance, replace_log_instance) and batch Logical APIs (batch_create / batch_read / batch_update / batch_delete for log items and instances). Tenant custom attributes on create_log_item are now sent as item-level customerAttributes.
  • Dassault Systèmes Cameo Enterprise Architect 4.4.3 — Headless @istari:run_simulation via Cameo Simulation Toolkit (optional runtime_overrides; results under simulation_results/). Universal extract now includes Property default_value. Simulation no longer publishes a redundant model revision when the run wrote nothing back.
  • IBM Rational DOORS Module 1.3.1@istari:extract_rhapsody from Rhapsody Model Manager (OSLC AM), using the same universal schema as Cameo extract. ETM, EWM, and Rhapsody extract can use a DOORS Next stored credential (one Jazz account for /rm, /qm, /ccm). Rhapsody extract also accepts delivered OAuth 1.0a linked credentials.
  • Microsoft Office 365 1.6.1 — Fixes AUTH_001 / CERTIFICATE_VERIFY_FAILED on token auth by using the OS certificate store (certifi fallback). Adds Microsoft national / sovereign / custom cloud support (auto-detect from SharePoint URL; optional cloud / ca_bundle). SSL failures now return an actionable error instead of a misleading password hint.
  • SOLIDWORKS (@istari) 1.0.0 — First release for SOLIDWORKS 2026: @istari:extract (parameters, mass properties, BOM, OBJ + views), @istari:extract_geometry (STEP/STL), and @istari:update_parameters.
  • Luminary Cloud CFD 1.1.2 — Security patch: runtime cryptography ≥50.0.0.
  • Microsoft Office Word 2.3.11 — Security patch: Magick.NET-Q16-x64 14.16.0.
  • Integration module dependency security updates — Additional modules ship patched third-party / test dependencies this release (Open PDF 1.7.10, Open Spreadsheet 2.3.13, Google Workspace 1.3.3, Jira & Confluence 1.2.2, Zoo.dev 1.0.4, AutoAssembler 1.0.2, SysGit 1.0.2). See the Updates for the August 2026 Release table and the All Compatible Modules list for pinned versions.

Release Timeline

2026-08-26:

  • Initial August 2026 release