Agent Manifest 1.0 and the A0–A5 autonomy scale

1. The manifest — the declared document and its canonical hash.
2. The A0–A5 scale — graded, so that two operators mean the same thing by A3.
3. The credential — how the manifest travels inside a W3C Verifiable Credential 2.0, with the boundResources and killSwitch claims.
4. Verification — the eight checks, in order, and what each one proves.

It deliberately does not define how credentials are issued operationally, how a revocation cascade is executed, or what a particular implementation charges. Those belong to an implementation, and CORTEX Seal’s own answers are published separately in its trust framework.

{
  "schema": "https://digitalcortex.tech/schemas/agent-manifest/1.0",
  "name": "Soporte",
  "role": "First-line customer support",
  "operator": { "legalName": "ACME Robotics S.L.", "registryCode": "B12345678", "jurisdiction": "ES" },
  "autonomyMax": "A2",
  "skills": ["ticket.read", "ticket.reply"],
  "prohibited": ["payment.execute", "data.delete"]
}

Three checks a JSON Schema validator cannot express on its own: a skill present in both skills and prohibited is a contradiction and must be rejected; autonomyMax must be consistent with the declared skills, because an agent declaring A0 cannot list a skill that writes; and operator.jurisdiction must be an ISO 3166-1 alpha-2 code.

canonicalJson is a recursive serialisation with each object’s keys sorted by code point, no insignificant whitespace, and keys whose value is undefined removed. It is not a plain JSON.stringify: two semantically identical manifests must produce the same bytes, or the hash stops being a useful binding.

function canonical(value) {
  if (Array.isArray(value)) return '[' + value.map(canonical).join(',') + ']';
  if (value && typeof value === 'object') {
    const keys = Object.keys(value).filter((k) => value[k] !== undefined).sort();
    return '{' + keys.map((k) => JSON.stringify(k) + ':' + canonical(value[k])).join(',') + '}';
  }
  return JSON.stringify(value === undefined ? null : value);
}

autonomyMax declares the ceiling, not the usual operating level: an agent declared A4 may spend most of its life doing A1 work. What the declaration says is that it will not go above A4 without a new manifest. A5 is never a valid value for `autonomyMax` in an implementation following this specification: it names the class of actions no agent may take, and it belongs in prohibited.

Both the VC 2.0 data model and the Bitstring Status List v1.0 have been W3C Recommendations since 15 May 2025. The JWS header carries a kid pointing at a verification method in the issuer’s DID document; a verifier that does not recognise that kid’s DID must fail at step 2 and go no further.

"boundResources": [
  { "ref": "sha256:1a7b…", "provider": "openai", "type": "API_KEY",
    "revocationMethod": "WEBHOOK", "irreversible": false, "failOpen": false }
],
"killSwitch": {
  "coverage": { "total": 4, "revocable": 3, "irreversible": 1 },
  "methods": ["STOP_ISSUANCE", "WEBHOOK", "PROVIDER_API"],
  "graceSecondsMax": 900,
  "dualApprovalRequired": true,
  "bestEffort": true
}

1. Only hashed references travel. ref = sha256(salt ‖ provider ‖ externalId), with the salt per workspace. Never the secret, never the hash of the secret alone — with a small key space that would be an oracle — and never the provider’s identifier.
2. `bindingsHash` enters the manifest. Adding or removing a linked resource therefore changes manifestHash and invalidates the live credential. That is correct: if the agent’s hands change, its identity document changes.
3. `failOpen` is declared, not hidden. Its state lives inside the signed credential precisely so a third party can check it without asking anyone.
4. `bestEffort: true` is mandatory whenever any method beyond STOP_ISSUANCE appears. An implementation may stop issuing its own tokens and publish a revoked status; what it cannot do is promise that a third party’s system executes anything.

Revocation is published with a W3C Bitstring Status List v1.0, itself served as a JWS signed with the same issuer key. A verifier must fetch the list referenced by credentialStatus.statusListCredential, verify its signature, confirm its id matches what the credential references, and read the bit at statusListIndex.

An implementation may add checks; a DID-document resolution check on the subject is common. A subject DID document served live is a discovery resource, not a trust one: cryptographic verification resolves the issuer’s document.

1. It accepts and produces manifests valid against agent-manifest-1.0.json.
2. It computes manifestHash as defined in section 03, byte for byte.
3. It uses the A0–A5 scale with the definitions of section 04, and never issues autonomyMax: "A5".
4. It issues credentials in the format of section 05, with bestEffort: true whenever a kill switch claim names any method beyond STOP_ISSUANCE.
5. It performs the checks of section 06 in order, reports the third outcome of step 8 distinctly, and states plainly what it does not attest, per section 01.

• This text and the JSON Schema: Creative Commons Attribution 4.0 International. Attribution: “Agent Manifest 1.0, Cosmolabs OÜ, CC BY 4.0”.
• The reference code, including the official SDKs: Apache License 2.0.
• Trade marks: CORTEX Seal, the logo and the seal artwork are trade marks of Cosmolabs OÜ, trade mark application pending, and are expressly excluded from both licences.

• A change that would invalidate an existing manifest is a major version.
• Adding an optional field is a minor version.
• Clarifying prose is a patch.

Because the schema identifier enters the hash, a new major version means new hashes. Implementations should keep validating old versions rather than migrating credentials that were correct when they were issued.