Signed Capability Manifest and Agent Card Authenticity Governance requires that every agent's capability declarations are cryptographically signed by an authorised issuer and that agent cards — the public-facing identity and capability advertisements used in agent discovery and interaction — are verified for authenticity before they are trusted. The capability manifest is the authoritative, tamper-evident record of what an agent is permitted to do; the agent card is the discoverable advertisement of that manifest to potential interaction partners. Without cryptographic signing and authenticity verification, capability claims are unverifiable assertions — an adversary can forge an agent card that claims compliance with governance standards it does not meet, or modify a legitimate manifest to add capabilities the agent was never authorised to exercise.
Scenario A — Forged Agent Card in Agent Marketplace: An enterprise operates an internal agent marketplace where agents register their capabilities and other agents discover them for task delegation. An adversary registers a rogue agent with a forged agent card claiming capabilities including financial.payment.initiate, data.pii.process, and governance compliance with AG-001, AG-004, and AG-010. No signature verification exists. An orchestration agent discovers the rogue agent, delegates a payment processing task based on the claimed capabilities, and sends £145,000 in payment instructions along with 3,200 customer records containing PII. The rogue agent exfiltrates the data and initiates fraudulent payments.
What went wrong: The agent card was an unsigned, unverified assertion. The marketplace accepted capability claims without cryptographic proof of authorisation. The orchestration agent trusted the claimed governance compliance without verification. Consequence: £145,000 in fraudulent payments, 3,200 customer PII records exfiltrated, ICO notification obligation triggered, marketplace trust model invalidated.
Scenario B — Manifest Tampering After Issuance: An organisation signs capability manifests for its agents using a proper signing process. However, the manifests are stored in a mutable data store, and the verification process checks the signature only at registration time — not at each use. An insider modifies Agent-47's manifest to add infrastructure.admin.execute capability six weeks after the original signing. Because the signature is not re-verified at action time, the modified manifest is accepted. Agent-47 uses the spurious admin capability to modify its own governance configuration, effectively disabling all controls.
What went wrong: Signature verification was a one-time check at registration, not a continuous assurance. The manifest was stored in a mutable format that could be modified after signing without invalidating the original signature (because the signature was cached, not re-evaluated). Consequence: Complete governance bypass for Agent-47, infrastructure compromise, inability to determine the extent of unauthorised actions taken during the 6-week window.
Scenario C — Expired Signing Key Used for Agent Card: An agent card is signed with a key that expired 4 months ago. The verification system checks that the signature is mathematically valid but does not check the key's expiry date or revocation status. The key was rotated because the previous key's private material was suspected compromised. An adversary who obtained the old private key signs a forged agent card and presents it as legitimate. The mathematical signature is valid. The key is expired and potentially compromised. The system accepts it.
What went wrong: Signature verification checked mathematical validity but not key lifecycle status. Key expiry and revocation are essential parts of signature verification — a valid signature from an expired or revoked key is not a valid signature. Consequence: Forged agent card accepted as legitimate, enabling all downstream attacks that a forged identity enables.
Scope: This dimension applies to all AI agent systems where agents advertise capabilities to other agents, orchestrators, marketplaces, or governance frameworks. It applies to agent cards used in discovery protocols, capability manifests used in governance applicability determination, and any capability declaration that other systems rely upon to make trust or delegation decisions. Single-agent deployments where the agent's capabilities are configured by the deploying organisation and never advertised externally are within scope for manifest signing (the organisation must still have a tamper-evident capability record) but may use simplified verification processes.
4.1. A conforming system MUST require every agent's capability manifest to be cryptographically signed by an authorised issuer before the agent is permitted to advertise capabilities or accept delegated tasks.
4.2. A conforming system MUST verify the capability manifest signature at every point of use — not only at registration time — including at handshake initiation, task delegation, and governance applicability evaluation.
4.3. A conforming system MUST verify the signing key's validity at signature verification time, including expiry date, revocation status (via CRL or OCSP equivalent), and issuer chain of trust.
4.4. A conforming system MUST reject agent cards and capability manifests with invalid, expired, or revoked signatures, and MUST NOT fall back to accepting unsigned capability claims.
4.5. A conforming system MUST bind the capability manifest to the agent's verified identity (per AG-012), preventing a valid manifest from being transferred to or replayed by a different agent.
4.6. A conforming system MUST include a manifest version number and issuance timestamp in the signed payload, preventing replay of superseded manifests.
4.7. A conforming system MUST store signing keys in hardware security modules (HSMs) or equivalent tamper-resistant key storage for production deployments handling financial, PII, or safety-critical operations.
4.8. A conforming system SHOULD support manifest counter-signatures from the deploying organisation's governance authority, providing a second assurance layer that the declared capabilities have been governance-reviewed.
4.9. A conforming system SHOULD publish agent cards to a verifiable registry (analogous to a certificate transparency log) where third parties can independently verify that a card was legitimately issued.
4.10. A conforming system MAY support delegated signing authority where an organisational root key delegates signing rights to departmental keys, with the delegation chain verifiable by any relying party.
Signed Capability Manifest and Agent Card Authenticity Governance addresses the trust gap between what an agent claims it can do and what it has been authorised to do. In traditional software systems, capability claims are implicit — a payment service can process payments because it was deployed with payment-processing code and configured with payment-system credentials. The claim and the reality are the same artefact.
In agent ecosystems, capability claims become explicit advertisements. An agent publishes an agent card saying "I can process payments, I comply with AG-001, and I support protocol version 3.0." Other agents and orchestrators rely on these claims to make delegation, routing, and trust decisions. If the claims are unverifiable assertions — plain text in a JSON document — the entire trust model rests on the assumption that no agent will lie about its capabilities. This assumption fails in adversarial environments.
Cryptographic signing transforms capability claims from unverifiable assertions into provable statements. A signed capability manifest says: "Issuer X, whose public key you can independently verify, asserts that Agent Y has capabilities A, B, and C as of timestamp T." The relying party can verify the issuer's identity, the signature's mathematical validity, the key's lifecycle status, and the binding between the manifest and the agent's identity. Forgery requires compromising the signing key, which is protected by HSM storage.
The continuous verification requirement (4.2) addresses the Scenario B failure mode where one-time verification creates a window for post-issuance tampering. The key lifecycle verification requirement (4.3) addresses the Scenario C failure mode where mathematically valid signatures from compromised keys are accepted. Together, these requirements ensure that the assurance provided by the signature is maintained throughout the manifest's lifecycle, not just at the moment of issuance.
Agent card authenticity is particularly critical in agent marketplaces and open discovery protocols where agents from different organisations interact. Without authenticity verification, a marketplace is an environment where any participant can claim any capability — the equivalent of an unregulated marketplace where any vendor can claim any certification. AG-176 provides the PKI-equivalent infrastructure that makes agent capability claims trustworthy.
The signed capability manifest should be a structured document (JSON, CBOR, or Protocol Buffer) containing the agent's capability declarations, metadata (version, timestamp, issuer identity, agent identity binding), and a detached or enveloped cryptographic signature. The signature should use an algorithm with at least 128 bits of security strength (e.g., ECDSA P-256, Ed25519, RSA-3072 or above).
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Manifest signing should align with eIDAS qualified electronic signature requirements for cross-border agent interactions within the EU. HSM requirements should meet FIPS 140-2 Level 3 or equivalent. The FCA expects firms to demonstrate that inter-system trust mechanisms are at least equivalent to those used for traditional financial messaging (e.g., SWIFT PKI, FIX session key management).
Healthcare. Agent cards for healthcare agents should include data handling capability declarations that map to HIPAA security categories. Manifest signing keys should be managed under the same controls as PHI encryption keys. The manifest should declare which PHI categories the agent is authorised to access.
Crypto/Web3. Manifest signing can leverage existing blockchain-based identity and attestation infrastructure. Decentralised identifiers (DIDs) can serve as the agent identity binding in the manifest. Verifiable credentials can serve as the manifest format. This alignment avoids creating a parallel trust infrastructure.
Basic Implementation — Capability manifests are signed by an organisational authority. Signature verification occurs at agent registration. Signing keys are stored in software-based key stores with access controls. Manifest format is standardised. Unsigned manifests are rejected at registration.
Intermediate Implementation — Signature verification at every point of use (not just registration). Key lifecycle verification including expiry and revocation. HSM-based key storage for production deployments. Identity-bound manifests preventing cross-agent replay. Manifest versioning with supersession detection. Counter-signatures from governance authority.
Advanced Implementation — All intermediate capabilities plus: manifest transparency log for third-party auditability. Short-lived manifests with automatic renewal (24-hour validity). Delegated signing authority with verifiable delegation chains. Independent adversarial testing of signature forgery, manifest tampering, replay attacks, and key lifecycle bypass. Cross-organisational manifest verification using federated trust anchors.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-176 compliance requires verifying the signing mechanism, the verification mechanism, key lifecycle enforcement, and identity binding.
Test 8.1: Unsigned Manifest Rejection
Test 8.2: Tampered Manifest Detection
infrastructure.admin.execute), and present the modified manifest with the original signature.Test 8.3: Expired Key Rejection
Test 8.4: Revoked Key Rejection
Test 8.5: Identity Binding Enforcement
Test 8.6: Continuous Verification
Test 8.7: Superseded Manifest Replay
financial.payment.initiate capability. Attempt to present the version 3 manifest (which includes the removed capability) instead of version 4.| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 15 (Accuracy, Robustness, Cybersecurity) | Direct requirement |
| EU AI Act | Article 13 (Transparency) | Supports compliance |
| eIDAS 2.0 | Article 3 (Electronic Identification), Article 25 (Electronic Signatures) | Supports compliance |
| NIST AI RMF | GOVERN 1.1, MANAGE 2.2, MANAGE 4.1 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
| DORA | Article 9 (ICT Risk Management), Article 11 (ICT Data Integrity) | Direct requirement |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
Article 15 requires resilience against attempts to alter the AI system's use by exploiting vulnerabilities. Unsigned or unverified capability manifests are a vulnerability — they can be forged or tampered with to alter how the agent is used in an ecosystem. Signed manifests with continuous verification implement the cybersecurity resilience requirement for agent capability declarations.
For cross-border agent interactions within the EU, manifest signatures may need to meet eIDAS requirements for electronic signatures. Qualified electronic signatures provide the highest level of legal recognition. AG-176's signing requirements align with eIDAS by requiring key management controls (HSM storage), issuer chain verification, and key lifecycle management that map to eIDAS qualified trust service provider requirements.
DORA Article 11 specifically addresses ICT data integrity. Signed capability manifests ensure the integrity of capability declarations, preventing tampering that could lead to incorrect trust decisions. This directly implements DORA's data integrity requirement for agent-related ICT artefacts.
The FCA expects firms to maintain systems and controls that ensure the integrity of inter-system communications and trust assertions. Signed manifests provide cryptographic assurance that capability claims have not been tampered with, satisfying the FCA's expectation for adequate controls over agent trust mechanisms.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Cross-organisation — forged or tampered capability manifests can compromise trust across entire agent ecosystems |
Consequence chain: Without signed manifests and authenticity verification, any entity can claim any capability. In an agent marketplace, this means a malicious agent can advertise governance compliance it does not have, receive delegated tasks it is not qualified to handle, and access data it is not authorised to process. The failure is foundational — it undermines the trust model that every other inter-agent governance dimension depends upon. If capability claims are untrustworthy, then AG-175 handshake governance cannot verify the remote agent's capabilities, AG-174 applicability governance cannot determine the correct governance controls, and AG-009 delegation governance cannot verify that the delegate is qualified. A single forged agent card in a financial services marketplace could result in fraudulent transactions, PII exfiltration, and regulatory enforcement against both the marketplace operator and the delegating organisation. The blast radius extends to every organisation that trusted the forged capability claims.
Cross-references: This dimension is closely related to AG-174 (Capability Profile and Dynamic Applicability Governance) which defines the capability profiles that AG-176 signs; AG-175 (Protocol Handshake, Capability Negotiation and Downgrade Protection Governance) which uses signed manifests during capability negotiation; AG-012 (Agent Identity Assurance) which provides the identity verification that manifests are bound to; AG-080 (Inter-Agent Trust and Attestation) which provides the trust framework within which signed manifests operate; and AG-015 (Organisational Namespace Isolation) which defines the namespace boundaries that signing authorities respect.