# Why does an instance of a signed skill manifest pass verification yet still execute with capabilities it never attested?

**Date of Record:** 2026 November 13
**Scope:** Applies to agent runtimes that load skills as signed manifests with capability attestations and verify provenance at invocation time. Does not apply to monolithic agents where skill code and capability grants are statically linked at build time and never re-evaluated.

## Core Distinction

The failure is not a broken signature. The failure is a *split between the attested capability set and the effective capability set at execution time*. A signed manifest attests to the capabilities the skill *declared* it needs at signing time. Provenance verification confirms the bytes of the manifest and the skill bundle are authentic and unmodified. Neither of these operations constrains the *ambient authority* the runtime actually hands to the skill when it runs.

Three distinct objects must be kept separate:

1. **Declared capabilities** — the set enumerated in the signed manifest.
2. **Attested capabilities** — the subset the issuer/signer vouches for, typically the intersection of declared capabilities with a policy the signer is trusted to assert.
3. **Effective capabilities** — the set of operations the process can actually perform once the runtime has resolved the manifest into a sandbox, token, or tool-binding.

The invariant that operators *assume* holds is `effective ⊆ attested`. The invariant that actually holds after a naive verifier is only `bundle_bytes == signed_bytes`. The gap between these two is where the boundary failure lives.

## What Was Observed

A skill manifest was signed with `capabilities: ["fs.read:/data", "http.get:api.internal"]`. The signature verified. The bundle hash matched. Provenance chain resolved to a trusted issuer. The runtime then instantiated the skill in a worker whose tool bindings were inherited from the *parent agent's* session context rather than narrowed to the attested set. Because the parent agent held `fs.write`, `shell.exec`, and `net.egress:*`, the skill could reach all of them. The manifest was honest; the sandbox was not derived from it.

In a second observed case, capability strings were matched by *prefix*. An attested capability `http.get:api.internal` was resolved by a dispatcher that treated the capability namespace as a substring match, so `http.get:api.internal.attacker.example` also matched. The signature covered the declared string; the resolver's matching semantics silently widened the effective grant.

In a third case, the manifest attested a capability that the runtime resolved *lazily*. Verification passed at load, but the capability token was minted on first use against the *current* policy, which by then had been widened by an unrelated config reload. Provenance was verified at `t0`; authority was granted at `t1` under different policy.

## Condition of Validity

Provenance verification is only a meaningful defense when all of the following hold:

- The runtime *derives* the sandbox, token, or tool-binding set **only** from the attested set, never from ambient session context, parent inheritance, or defaults.
- Capability matching is **exact** on a fully qualified capability identifier, not substring, prefix, or glob, unless the glob is itself part of the signed, attested string.
- Capability resolution is **eager** at load time, or any lazy resolution re-checks the attested set against the policy snapshot pinned at verification time.
- The attested set is the **intersection** of declared and policy-allowed, and the intersection is computed *before* the manifest is handed to the executor, not inside it.

When any of these is violated, the signature is still valid, the hash still matches, and the audit log still says "verified" — which is precisely what makes the failure non-obvious.

## Decision Boundary

Do not treat "signature valid + provenance resolved" as a sufficient gate for execution. The decision to execute must be gated on `effective == attested` *after* the sandbox is materialized and *before* the skill's first instruction runs. Concretely:

- If the runtime cannot enumerate the effective capability set of the instantiated worker, refuse to run the skill. Unenumerable authority cannot be proven to be a subset of attested authority.
- If the effective set is a strict superset of attested, refuse — do not "warn and continue." A superset is the exact condition the defense exists to catch.
- If the effective set is a strict subset, that is safe but should be logged; a subset usually means an attested capability failed to resolve, which is a latent availability bug, not a security one.

The boundary is: verification proves *what was signed*; only an explicit post-instantiation capability diff proves *what will run*.

## Operational Effect

Once the diff gate is enforced, the failure mode converts from a silent privilege escalation into a hard load-time error. Skills that relied on ambient inheritance stop loading — which is the correct outcome, because they were never actually constrained by their manifests. The cost is a burst of load failures during rollout as previously-latent ambient dependencies surface. The benefit is that the audit record's "verified" claim becomes load-bearing: it now means the skill ran with exactly the attested authority, not merely that its bytes were authentic.

## Reference Implementation

```python
class CapabilityAttestationError(RuntimeError):
    """Raised when effective runtime authority exceeds the attested capability set."""
    pass


def verify_and_instantiate(manifest, runtime, policy_snapshot):
    # 1. Byte-level provenance: signature and hash over the signed bundle.
    if not manifest.verify_signature():
        raise CapabilityAttestationError("manifest signature invalid")
    if not manifest.verify_bundle_hash():
        raise CapabilityAttestationError("bundle hash mismatch")

    # 2. Attested set = declared ∩ policy-allowed, computed by the verifier,
    #    never by the executor. Exact matching only.
    declared = frozenset(manifest.capabilities)
    allowed = frozenset(policy_snapshot.allowed_capabilities)
    attested = declared & allowed

    # 3. Materialize the sandbox pinned to the policy snapshot, then enumerate
    #    the authority the worker actually holds. Refuse on unenumerable.
    worker = runtime.instantiate(manifest.bundle, policy_snapshot=policy_snapshot)
    effective = worker.enumerate_effective_capabilities()
    if effective is None:
        raise CapabilityAttestationError(
            "effective capability set is unenumerable; cannot prove subset of attested"
        )
    effective = frozenset(effective)

    # 4. The invariant that the signature alone never guaranteed.
    overreach = effective - attested
    if overreach:
        raise CapabilityAttestationError(
            f"effective authority exceeds attested set: {sorted(overreach)}"
        )

    # 5. Eager re-check: no lazy widening between verify and first instruction.
    if worker.policy_generation() != policy_snapshot.generation:
        raise CapabilityAttestationError(
            "policy changed between verification and instantiation"
        )

    return worker
```