Consuming a manifest

This page is for someone building software that could read an Agent Manifest. It goes from not knowing what this is to one decision in your program taking a different branch because a declaration said so — nothing further.

It asks you to publish nothing, adopt no tooling of ours beyond a reading library, and copy no schema.

What a manifest is

An Agent Manifest is a JSON document in which the operator of an autonomous system declares, before any interaction, what that system is for, what it will not do, how much autonomy it has, who can stop it and what it records. The normative definition is the specification and its JSON Schema.

It is a declaration, not a credential. It is not signed and proves nothing about who issued it. That single fact decides how it can be used, and the last section of this page says how.

Install the reading client

npm install @agent-manifest/client

Node.js 22.12 or later. The package reads, canonicalises, fingerprints, compares and structurally validates declarations. It ships no thresholds, no profiles and no recommended lists, and it emits no verdict about trust, safety or compliance.

Read one

Resolving by name takes two calls: a registry has to be discovered before a name can be looked up in it.

import { discoverRegistry, resolve } from '@agent-manifest/client/net';

const registry = await discoverRegistry('agent-manifest-spec.org');
const result = await resolve('the-diplomat', { registryUrl: registry.registryUrl });
const manifest = result.resolutions[0].document;

console.log(manifest.autonomy.level, manifest.forbidden_actions);

A URL resolves in one call. Passing a bare name with no registry returns a result whose absence.reason is no-registry-declared — the client reports what it could not conclude instead of guessing.

That reporting is why resolutions can be empty, and the line above takes resolutions[0] without checking. A name the registry does not list resolves to nothing, absence.reason is not-in-registry-index, and resolutions[0] is undefined. Check the length, or read absence, before reaching for a document: absence is an answer here, not an error.

Read one from disk

import { readFileSync } from 'node:fs';
import { parse } from '@agent-manifest/client';
import { validate } from '@agent-manifest/client/validate';

const { document } = parse(readFileSync('manifest.json', 'utf8'));
const { schemaValid, errors } = validate(document);

parse() returns { document, form }, not the document. form records whether it was read from text or from an already-parsed value. Passing the wrapper straight into validate() reports every required field as missing, which looks like a broken manifest and is not one — destructure it.

Change one decision

Four worked examples, one file each, in the client repository: examples/.

Each one runs two inputs through the same code and produces two observable behaviours. That pair is the whole point: reading a manifest and printing it is not consuming it.

The MCP example is an explicit derivation of the gateway one rather than a case of its own, and says so in the file. The case that would be native to an MCP server — using a manifest to establish who is calling — is precisely the one a manifest cannot support.

The policy is yours

In all four examples the threshold sits in the example, marked to be edited. Nothing in the package decides what an acceptable autonomy.level is, and nothing will. The declaration layer stops at the declaration; the policy seat is left deliberately empty because it belongs to whoever is running the software.

The mapping between an action your software knows about and a string a manifest declares is part of that policy too: v1.0 defines neither a vocabulary nor a matching rule. See Known limits of v1.0.

Keep the trust questions separate

A manifest answers one question: what was declared? It does not, by itself, answer who issued the declaration, whether its claims are true, what a consumer should allow, how a decision is enforced, or what happened at runtime.

Agent Manifest mandates none of the external mechanisms in that table. Keeping these questions separate prevents a structurally valid declaration from being mistaken for authenticated identity, proof of truthfulness, or runtime evidence.

Restrict, do not grant

Use what is declared to narrow authority that was established independently: refuse a run, block a call, narrow a tool list, or add confinement.

Conceptually, safe composition is:

effective authority = independently established authority ∩ manifest-derived restrictions

The intersection is a model, not syntax defined by v1.0. The important property is directional: a manifest-derived rule may remove something from the consumer’s existing baseline, but it must never add a privilege, establish who a caller is, or relax a control that came from an independent source.

A false or incomplete declaration can still evade a restriction that exists only because the consumer chose to derive that restriction from the declaration. An unsigned manifest is therefore not a security boundary. If a favourable decision depends on who made a claim or whether the claim is true, establish that provenance or evidence separately.

This is why nothing here authenticates an agent, treats a manifest as a credential, applies enforcement on anyone’s behalf, or issues badges, seals or certifications.

What is not being asked of you

Publishing your own manifest, adopting the CLI, the registration flow or any other tool of ours, copying the schema into your repository, or mentioning this project anywhere.