> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Azure Blob Storage
description: >-
  Bind exact blob identity, choose a scoped identity or an admitted shared access signature, and
  test an immutable delivery and its credential expiry before you rely on it.
route: /docs/compute/integrations/azure-blob
page_id: docs-compute-integrations-azure-blob
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Administrators connecting Compute to containers their team already owns
voice: D
reader_question: How do I connect a Blob Storage container without granting more than one job needs?
primary_action: Check delivery states and acknowledgements
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-azure-blob-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## What this adapter states

Read these eleven facts off the adapter's descriptor and its published conformance matrix before you register anything.

| Fact | Where you read it |
| --- | --- |
| Provider product | Azure Blob Storage |
| Tested upstream version | The matrix names the exact API version tested |
| Supported direction | Input, output, or both, as declared on the descriptor |
| Credential mode | A scoped identity, or an admitted shared access signature |
| Input snapshot binding | A `version_id` and a `content_sha256` pinned before admission |
| Formats | The formats the workflow declares, listed on its descriptor |
| Output commit mode | Written once to a new partition, verified, then committed |
| Unsupported fields | Named explicitly in the matrix, not left out |
| Limits | Measured size, count and rate bounds in the matrix |
| Expiry | The identity's or signature's lifetime and who renews it |
| Compatibility level | One of the four named levels, with a matrix version |

If a row is unnamed on the matrix, treat that behavior as untested. See [what each compatibility level commits to](/docs/compute/integrations/compatibility-levels) before you plan around it.

## Bind exact blob identity

A container path is not an identity. Pin the exact blob and its version, so a later write under the same name cannot change what your run read.

The snapshot carries a `version_id` and a `content_sha256`. That pair is the contract, and it appears on your quote and again on the result's provenance record.

For a set of blobs, pin a manifest that names each blob and its version, then snapshot the manifest.

## Choose a scoped identity or an admitted signature

You have two credential modes, and they carry different risk.

- **A scoped identity.** Access is granted to an identity your account admits, with the narrowest role on the narrowest container path. Prefer this.
- **An admitted shared access signature.** Temporary bearer authority for one exact operation on one exact resource. Use it when a scoped identity is not available.

A signature is bearer authority: whoever holds it, holds that permission. Keep its lifetime as short as the transfer allows, and never let it appear in a log, a support request or a receipt.

Either mode is registered as a `credential_ref`. The secret itself never travels in a request, a configuration file or a command line.

## Set the access profile deliberately

Confirm the container's public access setting before you register it. A container that anonymous callers can read is not a container you should be pinning private input from.

Grant read on the input path and write on a separate output path. Do not reuse one grant for both directions.

Check the container's region against your account policy. Region is a constraint, and an inadmissible location refuses at admission rather than at delivery.

## Test an immutable delivery

Results are written once, to a new partition, and never over an existing blob. Your grant has to support that pattern, not just a general write.

Run the destination family's `test` operation and confirm it reaches a committed state. Creating a blob and finalizing one are different permissions, and the gap only appears under real delivery.

Repeat the test after any change to the role, the signature or the container policy.

## Plan for expiry before it happens

Delivery authority is deliberately time-bounded. `AUTHORITY_EXPIRED` means the permission lapsed, not that your result was lost.

Write the expiry date and the person who renews it next to the destination record. Renew before the date, not during an incident.

A re-delivery after renewal never needs a re-run. The bundle already exists; only the write is repeated.

## Confirm success

Both resources read back as `VERIFIED`, both tests pass, and the destination test reaches a committed write.

A real job's delivery then reaches `COMMITTED` and finally `CUSTOMER_ACKNOWLEDGED`. `WRITTEN_UNVERIFIED` is not done; it means bytes exist and nothing has confirmed them.

Keep the receipt reference the apply returned, and quote it to support if delivery behaves differently later.

[Check delivery states and acknowledgements](/docs/compute/delivery/states-and-acknowledgements)