Trusted Artifact Isolation

Every cache key addresses two entries: a trusted one and an untrusted one. Which entry a build writes, and which it may read, depends on the isolation levels set on the workload identity rule that its credentials match.

Isolation applies to OIDC workload identity credentials only. Levels come from claim matching, so there is no way to assign one to an access key.

Each workload identity rule carries two levels, set under Universal Cache isolation on the rule as Read isolation level and Write isolation level.

Three of the four pairs are valid. Write Trusted with read Prefer trusted is refused. A producer configured this way accepts untrusted content as input but publishes it as trusted, so it can carry untrusted content into the trusted pool. That is the path isolation exists to close, so Develocity refuses the pair rather than letting you configure it.

Upgrade Develocity before any Edge node. An older Controller reports no isolation levels, and an Edge node takes that literally, so builds miss every key until the upgrade completes.

Every Edge node must run version 2.3.0 or later before you set Require trusted on any workload identity rule. An older node has no isolation behavior at all: it accepts entries peered from a newer one, and it serves an untrusted entry to a Require trusted build instead of refusing it.

That refusal is the guarantee isolation exists to provide, so an Edge node left behind keeps the cache-poisoning path open for every build routed through it. The build is not told. The response carries no X-Trust-Class-Applied header and no error, the Artifact Cache CLI prints no classification summary, and no configuration page reports the mismatch. A cache hit from an older node is indistinguishable from a legitimate trusted hit. See Confirming the Applied Classification.

Check the version of every Edge node before you enable isolation, and again after adding a node. The Version column on the Administration  Edges page reports the version of every connected node, including the co-located node that Develocity manages.

A few workload shapes cover most deployments.

Turning isolation on is the disruptive step. A workload identity rule with no levels set resolves to write Untrusted and read Require trusted. At that moment every entry in the cache is untrusted, so every read misses until trusted producers repopulate the trusted side.

The Read isolation level and Write isolation level controls are hidden while isolation is off. You can choose either order:

Levels set after enabling take effect from that point. Nothing is lost by setting them late. The trusted side takes longer to fill.

Image names do not create a trust boundary. A different image name resolves a different manifest, but the entries that manifest references sit in the same pool. Entry keys are chosen by the client. Two trusted branches can therefore write the same entry whatever image names they use. For what an image name does control, see Images.

No cache path isolates by branch. If you need a branch boundary, isolation is not the mechanism that provides one.

Access key builds, anonymous builds, and any credential that matches no workload identity rule all behave the same way: they write untrusted entries and read a trusted entry when one exists.

This behavior is not configurable, and it does not change when isolation is off or on. Two consequences follow:

Anonymous cache access resolves a trusted entry wherever one exists, and that cannot be turned off. Take it into account when deciding whether to grant anonymous cache access at all.

Develocity reports the classification it applied on each cache response, in the X-Trust-Class-Applied header. It carries TRUSTED or UNTRUSTED.

An absent header means Develocity applied no classification, which is not the same as UNTRUSTED. A node that predates isolation reports nothing.

The Develocity Artifact Cache CLI reads this header and logs the classification for each operation, then reports an end-of-run summary per cache:

After setting a producer’s write level to Trusted, confirm from that job’s summary that trusted writes are happening. A summary showing zero trusted entries means no credential on that job is classified as trusted. Adjust the workload identity rule’s claim matchers so the job matches it.

A request can match more than one workload identity rule. When the matched rules disagree on a level, or combine into the refused pair, Develocity refuses the cache operation with 409 Conflict rather than resolving it at the weaker level.

The response carries X-Cache-Isolation-Conflict naming the cause, because the remedies differ:

The header is diagnostic. No build tool reads it, so a conflicted operation surfaces in the build the way any unexpected cache error does. Read the header, or the Edge node log, to find which of the four causes applies.

Turning isolation off returns every workload identity to the default behavior: untrusted writes, and reads that resolve a trusted entry when one exists. Develocity preserves the levels on each rule, but they stop taking effect.

Clear Enable Universal Cache isolation under Administration  Access control  Workload identity, select Save, then select Apply in the banner. Isolation stays on until you do.

Nothing is deleted. Trust class values on existing entries stay on disk, and reads keep preferring a trusted entry, so clearing a workload’s levels costs no cache hits.