chore(deps): update agent-manifest requirement from >=0.10.0 to >=0.11.0

[dependabot]

Updates the requirements on agent-manifest to permit the latest version.

Release notes

Sourced from agent-manifest's releases.

python-v0.11.0

What's Changed

• chore(deps): bump pypa/gh-action-pypi-publish from 1.14.1 to 1.14.2 by @​dependabot[bot] in agentrust-io/agent-manifest#264
• Move the @​context URI to a domain we control; republish spec as v0.2 by @​imran-siddique in agentrust-io/agent-manifest#263
• docs(governance): state who may author normative text by @​imran-siddique in agentrust-io/agent-manifest#271
• Give the homepage a searchable title by @​imran-siddique in agentrust-io/agent-manifest#276
• fix(deps): allow cryptography 50 so pip-audit passes by @​imran-siddique in agentrust-io/agent-manifest#278
• docs(spec): stamp the EU AI Act applicability dates and map Article 50 as a gap by @​imran-siddique in agentrust-io/agent-manifest#277
• docs: make the conformance-level tables match section 8.1 by @​imran-siddique in agentrust-io/agent-manifest#279
• Conformance test: what VALID does and does not establish by @​Mayur021 in agentrust-io/agent-manifest#280
• spec: informative crosswalk to OCSF runtime evidence (#269) by @​imran-siddique in agentrust-io/agent-manifest#285
• spec: state the boundary with Agent Plugins (#281) by @​imran-siddique in agentrust-io/agent-manifest#286
• feat(sdk): read Agent Plugins bundles, and refuse to invent tool hashes (#282) by @​imran-siddique in agentrust-io/agent-manifest#287
• feat(cose): implement the v0.2 COSE envelope behind the version gate (#243 phase 2) by @​zohebk8s in agentrust-io/agent-manifest#274
• spec+sdk: declared intent, and the issuer is the one who declares it by @​imran-siddique in agentrust-io/agent-manifest#288
• fix(cose): bound payload nesting explicitly, not via RecursionError by @​imran-siddique in agentrust-io/agent-manifest#290
• release: python-v0.11.0 by @​imran-siddique in agentrust-io/agent-manifest#289

New Contributors

• @​Mayur021 made their first contribution in agentrust-io/agent-manifest#280
• @​zohebk8s made their first contribution in agentrust-io/agent-manifest#274

Full Changelog: agentrust-io/agent-manifest@python-v0.10.0...python-v0.11.0

Changelog

Sourced from agent-manifest's changelog.

[0.11.0] — 2026-08-11

Added

[SPEC][SDK] Section 3.9 adds an OPTIONAL intent field, declared by the issuer. Runtime governance frameworks (AARM R2/R3 among them) ask that an action be evaluated against the agent's stated intent, and this specification had no such input. The field is one string, intent.statement.

The issuer declares it, and that is the whole design. An intent the governed agent asserts about itself cannot support the check it exists for: an agent that intends to do X declares X, and the comparison becomes a formality. intent is therefore inside the signing pre-image, fixed before the agent runs, and the spec says an intent supplied outside the signed manifest — on a per-call request field, say — MUST NOT be accepted as satisfying the section.

Adding a field to SIGNED_FIELDS would normally be a compatibility break and is not one here: signing_pre_image omits fields absent from the manifest rather than serializing them as null, so a manifest without intent produces byte-identical pre-image to before and its signature still verifies. A test asserts that against the exact bytes, and it fails if absent fields are ever materialized.

No digest is stored beside the statement. intent_hash() derives sha256:<hex> over the canonical intent object on demand, so a runtime can bind the intent into a per-call receipt without a second representation that can be made to disagree with the first. It returns None when no intent is declared, which is a distinct answer from a digest over an empty statement.

Section 3.9.1 states what the field does not give: it is an input, not an analysis. Nothing here measures whether an action is semantically consistent with the declared intent, that would need a model whose own execution would have to be attested, and an implementation MUST NOT present the presence of intent as evidence such a measurement happened. A structural proxy is not a semantic measure and MUST NOT be labelled as one.

[SPEC] Section 6.5 states the boundary with Agent Plugins (#281). Agent Plugins 1.0.0 shipped as a packaging format for Agent Skills and MCP server configuration, backed by a multi-vendor steering committee, and the obvious reading from outside is that this project is a second format for the same job. It is not, and the specification had nowhere that said so.

The boundary in one sentence: Agent Plugins describes what a client should install, a manifest describes what actually ran. A plugin bundle is an input to a manifest.

The section argues that from the format's own documents rather than by assertion. plugin.json requires two fields, $schema and name, version is an unconstrained string, and there is no integrity, signature or provenance field in the 1.0.0 schema. FUTURE_CONSIDERATIONS.md states that v1.0.0 "does not define a trust model, permission system, or sandboxing requirements for plugins" and "does not specify how clients or users can verify the origin or integrity of a plugin", and lists attestation chains linking a published plugin to its source repository and build as possible future work.

Of the ten artifacts, Agent Plugins carries two, and carries both as declarations rather than as resolutions: skills/*/SKILL.md holds instruction material, and mcp.json declares which servers to start without enumerating the tools those servers exposed. That declared-versus-resolved gap is the boundary in miniature.

It stays informative for the same reason 6.4 does. Binding to plugin.json now would fix a field layout in a 1.0.0 format whose own roadmap anticipates adding provenance, so it would have to be revised rather than refined once that lands. The extensions object, keyed by reverse-domain namespace, is noted as sufficient to carry a manifest reference without any change to the format.

[SDK] manifest from-plugin reads an Agent Plugins 1.0.0 bundle (#282), along with load_plugin_bundle, bundle_digest and system_prompt_binding_from_bundle. This is the runnable half of the boundary in spec section 6.5: a plugin bundle is an input to a manifest, and now there is code that treats it as one.

It does not build a tool manifest, and that is the point. ToolEntry requires a schema_hash and a description_hash for every tool. mcp.json declares which servers to start and never enumerates the tools those servers expose, so a bundle carries neither hash and cannot be made to. Building a ToolManifestBinding from a bundle alone would mean inventing the two values the artifact exists to bind. Declared servers are therefore recorded as declarations, each with a hash of its declaration so a later resolution can be compared against what the bundle said, and the CLI says on stderr how many still need resolving. A test asserts that no tool-manifest builder appears in the module, so this stays true by accident-proofing rather than by memory.

The digest covers every file in the bundle, including ones the adapter does not parse, such as the reverse-domain client extension directories the format permits. A digest that skipped what it did not understand would report the same value for two bundles differing in an unread file, which is the case where unmeasured and empty become indistinguishable. Paths are bound alongside content, so a rename with identical bytes is a different digest.

$schema is checked against the 1.0.0 constant and an unrecognised value is refused rather than guessed at. Both mcp.json shapes seen in the wild are accepted, the mcpServers wrapper and a bare mapping, because rejecting the second would fail bundles every client accepts.

[SPEC] Section 6.4 is an informative crosswalk to OCSF runtime evidence (#269). There was no defined join key between a manifest and the OCSF events emitted under it, so a consumer holding both could not tell they described the same agent without an out-of-band convention, and implementers were left to invent a second identity mechanism for a job this specification already does. The new section records the intended correspondence and deliberately requires nothing.

Three things it gets right that a normative version could not yet: it is written against the ai_operation profile, which is what actually contributes ai_agent, rather than against an event class (the Agent Inventory Info [5050] class proposed for this does not exist in OCSF as of this writing; a Discovery-category class for agent trust-base inventory is now proposed upstream at ocsf/ocsf-schema#1724); it maps ai_agent.uid to the durable identity and instance_uid to the session-scoped one, which is what OCSF's own definitions ask for, instead of collapsing both onto agent_id; and it notes that session_uid is not an ai_agent attribute at all.

It stays informative because agent_id is one field serving both roles, and section 3.1 says the /agent/<name>/<instance> path is "a convention, not a requirement" — so a conformant agent_id may be stable and carry no instance scope. Requiring it to populate instance_uid, which OCSF defines as explicitly distinct from the stable uid, would force a stable identifier into the non-stable field and cost a consumer the ability to separate "every run of this agent" from "this run". Resolving that means deciding whether agent_id splits, which belongs in CoSAI WS4 alongside the canonical @context URL that section 3.1 already defers there.

The section also records a correspondence worth more than the identity one: OCSF's delegation object (uid, parent_uid, forming a re-delegation DAG) is structurally the delegation chain of section 3.4. It does not map today, because a section 3.4 hop has no per-hop durable identifier to populate delegation.uid, and OCSF wants that identifier issued by a trusted authority rather than self-asserted by the delegator. Closing that is a data-model change, not a crosswalk, and is not proposed here.

[SPEC] Section 9.1.2 maps EU AI Act Article 50, and maps it as a gap. Article 50 transparency duties have applied since 2 August 2026: chatbot disclosure, machine-readable marking of synthetic output, emotion-recognition notice. It is the only AI Act obligation in force against an agent deployment today, and no document in this repository mentioned it. The manifest satisfies none of the four paragraphs, so the new subsection says that in those words, notes that Article 50 applies regardless of Annex III classification, and states that a manifest MUST NOT be read as Article 50 evidence. docs/compliance/eu-ai-act.md carries the same mapping for auditors. Marking that binds to the attested agent that produced the output, rather than to a strippable metadata field, is the design being pursued; it is not built.

[SDK] COSE_Sign1 signing and verification for manifest version 0.2 (_cose.py, ADR-0011, ADR-0013). Phase 2 of the envelope migration (issue #243). verify_manifest() now takes either a dict or bytes: a dict is a v0.1 manifest and verifies exactly as it does today, bytes are a v0.2 COSE envelope. The envelope follows the manifest version, never a flag, so no existing record is reinterpreted.

Fixed

[SPEC] The README pointed at a specification file that does not exist. Three links and the spec badge referenced spec/agent-manifest-spec-v0.1.md, superseded by v0.2. All four now resolve.

Changed

... (truncated)

Commits

• 98cead8 release: python-v0.11.0 (#289)
• 930d807 fix(cose): bound payload nesting explicitly, not via RecursionError (#290)
• 34e276e spec+sdk: declared intent, and the issuer is the one who declares it (#288)
• d3ff209 feat(cose): implement the v0.2 COSE envelope behind the version gate (#243 ph...
• 6f8167c feat(sdk): read Agent Plugins bundles, and refuse to invent tool hashes (#282...
• 3d7753a spec: state the boundary with Agent Plugins (#281) (#286)
• cfe358b spec: informative crosswalk to OCSF runtime evidence (#269) (#285)
• 62e4ec2 Conformance test: what VALID does and does not establish (#280)
• 03c9c44 docs: make the conformance-level tables match section 8.1 (#279)
• dbf52cb docs(spec): stamp the EU AI Act applicability dates and map Article 50 as a g...
• Additional commits viewable in compare view

[imran-siddique]

@dependabot rebase