materialized capsule manifest exceeds durable authority appr

Error message

materialized capsule manifest exceeds durable authority approval

What it means

As the final verification step, the materialized manifest's capabilities are compared via capabilities::expansions_from against the approved_capabilities recorded in the durable authority document. This bail fires when the Capsule.toml being bound requests capabilities beyond what the signing authority actually approved — i.e. the manifest is an expansion (privilege escalation) relative to the durable grant, so the kernel refuses to bind or activate it.

Source

Thrown at crates/astrid-kernel/src/capsule_materialization.rs:108

        if actual.directories != expected_directories {
            anyhow::bail!("materialized capsule directory inventory differs from durable package");
        }
        for (relative, expected) in &expected_files {
            let materialized =
                Self::read_projection_file_nofollow(&dir.join(relative)).map_err(|error| {
                    anyhow::anyhow!("read materialized capsule member {relative}: {error}")
                })?;
            if materialized != *expected {
                anyhow::bail!(
                    "materialized capsule member {relative} differs from durable archive"
                );
            }
        }
        let expansions = manifest
            .capabilities
            .expansions_from(&verified.authority().approved_capabilities);
        if !expansions.is_empty() {
            anyhow::bail!("materialized capsule manifest exceeds durable authority approval");
        }
        Ok(())
    }

    /// Bind durable activation or authorize the explicit workspace portal.
    #[cfg(not(all(target_arch = "wasm32", target_os = "unknown")))]
    pub(crate) fn capture_bound_materialization(
        &self,
        dir: &Path,
        principal: &astrid_core::principal::PrincipalId,
        manifest: &astrid_capsule_types::manifest::CapsuleManifest,
        operation: &str,
    ) -> anyhow::Result<Option<BoundMaterialization>> {
        let snapshot = self.published_capsule_snapshot(principal, manifest)?;
        if let Some(snapshot) = snapshot {
            let runtime_dir = self.published_cache_target(principal, manifest, &snapshot)?;
            let bound_manifest = self.repair_published_materialization(
                &runtime_dir,

View on GitHub (pinned to affd8760f4)

Solutions

Re-obtain or regenerate the durable authority: have the authority re-approve the expanded capability set and republish the capsule so approved_capabilities covers the manifest.
Remove the unapproved capability entries from the manifest so it fits within approved_capabilities, then re-publish/re-materialize.
Check which expansions were rejected: compute manifest.capabilities.expansions_from(&approved) yourself to see the offending grants before changing anything.
If the capsule is intended to be less privileged, align the manifest version with the one the authority document was issued for (the version/name are checked earlier in the same function).

Example fix

// before: manifest requests more than the authority approved
# Capsule.toml
[capabilities]
network = ["api.example.com"]
storage = ["secrets/*"]   # not in approved_capabilities

// after: only declare what the authority signed for, or re-approve
[capabilities]
network = ["api.example.com"]

Defensive patterns

Strategy: validation

Validate before calling

// Check for capability expansion before binding the capsule
let expansions = manifest.capabilities
    .expansions_from(&verified_authority.approved_capabilities);
if !expansions.is_empty() {
    anyhow::bail!("manifest expands beyond authority: {expansions:?}");
}

Try / catch

match kernel.load_capsule(&dir, &principal) {
    Err(e) if e.to_string().contains("exceeds durable authority approval") => {
        // request re-approval or trim capabilities in Capsule.toml
        request_authority_reapproval(&manifest)?;
    }
    other => other.map(|_| ()),
}

Prevention

Regenerate the authority document whenever you add capabilities to Capsule.toml.
Run capabilities.expansions_from locally in CI to catch unapproved grants before publish.
Keep manifest versions aligned with the authority document version that approved them.
Review capability diffs as part of the release checklist.

When it happens

Trigger: verify_published_materialization is invoked with a manifest whose `capabilities` struct contains grants not present/covered in verified.authority().approved_capabilities — typically after a Capsule.toml was modified post-signing, an authority document was replaced with a narrower one, or the caller passed a manifest from a newer version against an authority approved for an older, less-privileged version.

Common situations: A developer adds a new capability (e.g. network or filesystem access) to Capsule.toml locally without re-approval; a package is republished with expanded capabilities but the durable authority document was not regenerated; a downgrade or version pin causes the registry's authority to authorize fewer capabilities than the manifest declares.

Understand the failure class

Background: "You do not have permission" / 403 Forbidden errors: authenticated but not allowed — causes and fixes across open-source libraries — this error's family across 31 libraries.

Related errors

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/abb9d3cb5fcff8c5. Report an issue: GitHub.