Open Specification — Standards Track
Core Declarative Specification
Version 1.0This document defines the Agent Manifest Core Declarative Specification (v1.0), a machine-readable, execution-agnostic standard that establishes the minimum declaration requirements for autonomous systems prior to interaction or execution.
The specification defines mandatory structural elements that MUST be present in a conformant agent manifest, including identity, responsible party, declared purpose, operational constraints, autonomy level, stopping authority, audit posture, and data handling declarations.
This document specifies normative conformance criteria and includes a normative JSON Schema. It does not define runtime execution behavior, enforcement mechanisms, validation scoring systems, or regulatory compliance processes.
Autonomous and semi-autonomous systems are increasingly deployed in contexts where they may execute actions, access data, make recommendations, and interact with financial and institutional environments. A structural asymmetry persists: execution capabilities scale faster than declared authority frameworks.
Agent Manifest introduces a minimal, execution-agnostic Declaration Layer for autonomous systems. It defines a structured, portable, machine-readable mechanism through which an agent declares identity, purpose, negative boundaries, autonomy posture, risk profile, stopping authority, audit surface, and data-handling commitments prior to execution.
The framework does not execute agents, does not enforce policy, and does not guarantee safety. It establishes a governance primitive: legitimacy must precede execution.
This document is an Open Specification on the Standards Track. It defines mandatory and optional elements required for structural conformance of an Agent Manifest.
This specification:
Implementations claiming conformance MUST satisfy all normative requirements defined herein. Future revisions to this specification SHALL follow semantic versioning.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
All examples in this document are non-normative unless explicitly identified as normative. The terms "Declaration Layer", "Enforcement Layer", and "Execution Layer" are defined in Section 4.
For the purposes of this specification, the following terms are defined as normative terms.
```An Autonomous System is a software-based system capable of performing decision-making or action execution with varying degrees of independence from direct human control. Autonomous systems MAY include single agents, multi-agent systems, or orchestrated workflows. This specification applies specifically to Agents, defined below.
An Agent is a software entity that:
This specification defines declaration requirements for Agents as a subcategory of autonomous systems.
An Agent Manifest is a machine-readable declaration document conforming to this specification that defines the declared identity, authority, scope, constraints, autonomy level, stopping authority, audit posture, and data handling posture of an Agent prior to execution.
The Declaration Layer is the architectural layer in which an Agent Manifest exists and is evaluated. The Declaration Layer defines structural statements about an Agent. It does not execute behavior.
The Enforcement Layer is any system, policy engine, validation process, regulatory framework, or organizational control mechanism that interprets, evaluates, or acts upon a declaration. This specification does not define Enforcement Layer behavior.
The Execution Layer is the runtime environment in which an Agent performs actions, produces outputs, or interacts with systems or users. This specification does not define execution semantics.
The Responsible Party is the declared accountable entity associated with an Agent. The Responsible Party:
The Responsible Party MAY also be identified as a Stopping Authority as defined in Section 4.15. This specification does not define legal validation of Responsible Party capability.
The Autonomy Level is the declared degree of execution independence assigned to an Agent. Autonomy Level is expressed as an integer value defined in Section 8. Autonomy Level describes execution posture, not intelligence, complexity, or capability.
Negative Scope is the explicitly declared set of actions that an Agent MUST NOT
perform. Negative Scope is expressed through the forbidden_actions declaration.
Negative Scope defines hard prohibitions independent of declared purpose.
Structural Validity refers to conformance of an Agent Manifest to the formal schema defined in this specification. A manifest is structurally valid if:
Structural Validity does not assess internal consistency between fields.
Structural Coherence refers to logical consistency between declared elements of an Agent Manifest. Structural Coherence evaluates whether declared autonomy, audit posture, stopping authority, and other elements are internally consistent. Structural Coherence is distinct from Structural Validity. Minimum coherence requirements are defined in Section 7.
Conformance refers to adherence to all normative requirements defined in this specification. An Agent Manifest is conformant if it satisfies all normative requirements defined herein, including structural validity and mandatory declaration constraints.
The Audit Surface is the declared visibility and logging posture of an Agent's execution behavior. Audit Surface includes logging level and reconstructability declarations.
Reconstructability is the declared capability to reconstruct execution events after they occur. Reconstructability is expressed as a categorical declaration defined in Section 10.
Stopping Authority is the declared mechanism and accountable entity capable of interrupting or disabling an Agent. Stopping Authority MUST include:
Stopping Authority requirements are defined in Section 9.
```This specification operates within a three-layer architectural model:
The Declaration Layer defines structured, machine-readable statements describing an Agent prior to execution. The Declaration Layer:
The Declaration Layer does not execute actions.
The Enforcement Layer evaluates, interprets, or applies policies to Agent Manifests. Enforcement mechanisms MAY include schema validation, structural coherence checks, organizational policy review, procurement gating, and regulatory review. This specification does not define enforcement logic, scoring systems, or rejection policies.
The Execution Layer performs runtime behavior. It MAY invoke tools, produce outputs, interact with external systems, and cause state transitions. This specification does not constrain runtime implementation except where structural coherence requirements apply to declared autonomy and stopping authority.
The following invariant applies:
The following invariants define the minimum structural requirements for the existence of a conformant Agent Manifest. Failure to satisfy any Requirement in this section results in non-conformance. Each Requirement defines a mandatory declaration condition.
```
An Agent Manifest MUST declare: manifest_version,
agent_id, agent_name, agent_version. The
manifest_version MUST match the version defined by
this specification. The agent_id MUST uniquely
identify the Agent within its declared context.
An Agent Manifest MUST declare a Responsible Party. The declaration
MUST include owner.type and owner.identifier.
The Responsible Party MUST be identifiable as a discrete accountable entity.
An Agent Manifest MUST declare a bounded purpose including
purpose.primary_code and purpose.description. The declared purpose
MUST define a specific operational domain. Purpose declarations
MUST NOT be undefined, empty, or aspirational without operational scope.
An Agent Manifest MUST declare at least one prohibited action via
forbidden_actions. Each entry MUST describe a concrete
action class the Agent MUST NOT perform. Negative Scope
MUST be explicit. Implicit prohibitions are not sufficient for conformance.
An Agent Manifest MUST declare an Autonomy Level via
autonomy.level. The declared value MUST be an integer
defined by this specification. Autonomy Level semantics are defined in Section 8.
An Agent Manifest MUST declare a Stopping Authority including at
least one stoppable_by entity or role and a mechanism describing
how interruption occurs. Stopping Authority MUST be declared prior
to execution.
An Agent Manifest MUST declare an Audit Surface including
audit_surface.logging and audit_surface.reconstructability. Values
MUST conform to the allowed enumerations defined in this specification.
An Agent Manifest MUST declare whether it stores personal data via
data_handling.stores_personal_data. If stores_personal_data is
true, the manifest MUST declare a retention value.
Retention values MUST be explicit.
An Agent Manifest MUST declare a contact email via
contact.email. The contact email MUST conform to a
valid email format as defined in the normative schema.
Structural Coherence defines minimum logical consistency constraints between declared fields. Violation of a MUST requirement in this section results in non-conformance. Violation of a SHOULD requirement does not invalidate conformance but indicates elevated review requirement.
```
If autonomy.level is 2 or 3, the declared stopping_authority.mechanism
MUST describe an actionable interruption mechanism. Generic statements
such as "can be stopped" are not sufficient. The mechanism MUST
describe a concrete interruption method (e.g., service disablement, credential revocation,
execution halt).
If autonomy.level is 1, a Stopping Authority mechanism
SHOULD be declared.
If autonomy.level is 3, stopping_authority.stages
SHOULD be declared.
If autonomy.level is 3, the Agent Manifest MUST NOT
declare both audit_surface.logging = "none" and
audit_surface.reconstructability = "none" simultaneously. Declaring no logging
and no reconstructability at Level 3 constitutes structural incoherence.
If autonomy.level is 2, audit_surface.logging
SHOULD NOT be "none".
If autonomy.level is 3 and risk_profile.level is
"low", the declaration SHOULD include explanatory
notes in risk_profile.notes. High autonomy with low declared risk warrants
contextual justification.
Retention requirements are defined normatively in Section 6.8.
If data_handling.stores_personal_data is true, the declared
retention period SHOULD be appropriate to the operational domain
of the Agent.
Autonomy Level is a declared structural variable representing the execution independence of
an Agent. Autonomy Level is declared explicitly via autonomy.level, is not
inferred by this specification, does not measure intelligence or performance, and describes
execution authority posture. Classification MUST be determined
according to the criteria defined in Section 8.2.
An Agent SHALL be classified as Level 0 if and only if the Agent does not execute actions affecting external systems, and produces advisory, descriptive, or informational output only.
Necessary condition: No side effects external to the Agent process.
Sufficient condition: All outputs require external human or system execution to
produce real-world effect.
An Agent SHALL be classified as Level 1 if and only if the Agent may perform execution actions and each action requires explicit human or external system confirmation prior to effect.
Necessary condition: Execution is conditional on per-action approval.
Sufficient condition: No autonomous execution occurs without discrete approval per operation.
An Agent SHALL be classified as Level 2 if and only if the Agent may execute actions without per-step human approval, execution is limited to predefined workflows or bounded operational scope, and execution authority is constrained by declared purpose and negative scope.
Necessary conditions: Autonomous execution within defined scope. Scope constraints are externally bounded.
Sufficient condition: The Agent cannot extend its operational domain without modification of its declaration.
An Agent SHALL be classified as Level 3 if and only if the Agent may execute actions without per-step approval, may initiate actions within declared scope independently, and execution may produce material external effects without synchronous human confirmation.
Necessary conditions: Independent action initiation. Execution authority not limited to fixed workflow sequences.
Sufficient condition: The Agent can determine timing and sequencing of actions within declared scope.
This table is normative and SHALL be used for classification reference.
| Level | Executes Actions | Per-Action Approval | Independent Initiation | Scope Bound |
|---|---|---|---|---|
| 0 | No | N/A | No | N/A |
| 1 | Yes | Yes | No | Yes |
| 2 | Yes | No | No (workflow-bound) | Yes |
| 3 | Yes | No | Yes | Yes |
Autonomy Level is declared by the Responsible Party. The Responsible Party MUST classify the Agent according to the criteria defined in Section 8.2. This specification does not define a mechanism for external verification of declared Autonomy Level. Enforcement Layer systems MAY evaluate declared Autonomy Level for coherence.
```Stopping Authority defines the declared capacity to interrupt, disable, or suspend an Agent's execution. It exists at the Declaration Layer and describes interruption capability prior to execution. Stopping Authority does not itself perform interruption — it declares how interruption may occur and who is authorized to initiate it.
The stopping_authority.stoppable_by field declares the entity or role authorized
to initiate interruption. Each entry:
The declaration MAY reference organizational roles, system operators, Responsible Party, or dedicated oversight entities. This specification does not require external validation of declared entities.
The stopping_authority.mechanism field declares the technical method by which
interruption occurs. An actionable mechanism MUST:
The mechanism declaration MUST NOT consist solely of generic statements such as "Can be stopped by admin", "Manual override", or "System can be disabled". Examples of actionable mechanisms include: revocation of execution credentials or API tokens; disabling execution service via administrative interface; halting execution process at orchestration layer; policy-based denial at runtime gate. The declaration MUST describe the interruption vector, not merely the existence of authority.
The stopping_authority.stages field is OPTIONAL. If
declared, it describes the execution stages during which interruption may occur. Valid stage
values MAY include: pre-execution,
mid-execution, post-execution. Stage declarations clarify
interruption timing but do not alter execution semantics.
Stopping Authority coherence requirements relative to Autonomy Level are defined in Section 7.1. Section 9 defines semantic requirements only and does not restate autonomy-dependent constraints.
```
The Audit Surface defines the declared observability posture of an Agent's execution behavior.
The declaration consists of audit_surface.logging,
audit_surface.reconstructability, optional
audit_surface.opacity_declared, and optional explanatory notes. Audit Surface
exists at the Declaration Layer and does not enforce runtime logging behavior.
The audit_surface.logging field declares the level of execution event recording.
Permitted values: "none", "basic", "detailed".
No execution events are recorded. The Agent does not produce structured logs for external audit purposes.
The Agent records high-level execution events sufficient to identify invocation occurrence, action type, timestamp, and outcome status. Basic logging does not require parameter-level or state-level trace detail.
The Agent records execution events with sufficient granularity to enable parameter-level traceability, decision path identification (where available), correlation identifiers, and action sequencing. Detailed logging does not imply full reconstructability unless declared separately.
The audit_surface.reconstructability field declares whether execution events
can be reconstructed after occurrence. Permitted values: "none",
"partial", "full".
Execution events cannot be reconstructed after occurrence.
Some execution events can be reconstructed, but reconstruction may be incomplete or limited in scope.
Execution events can be reconstructed to the extent necessary to determine what action occurred, when it occurred, under which declared scope, and by which execution pathway. Full reconstructability does not imply deterministic replay capability unless explicitly declared.
The audit_surface.opacity_declared field indicates whether the Agent contains
execution behavior that cannot be structurally reconstructed independent of logging
configuration. Opacity is required to be declared when the Agent contains components whose
internal decision processes are not reproducible or externally inspectable, or when
reconstruction is structurally impossible due to system architecture, model design, or
third-party constraints.
Opacity declaration is distinct from logging level. An Agent MAY declare detailed logging and full reconstructability while still declaring opacity if internal reasoning cannot be independently reproduced. An opacity declaration MUST NOT be implicit. If structural opacity exists and is not declared, the Agent Manifest is materially misleading. Explanatory notes SHOULD clarify the source of opacity.
Audit Surface coherence constraints relative to Autonomy Level are defined in Section 7.2. Section 10 defines semantic requirements only.
```The Data Handling declaration defines whether an Agent stores personal data and, if so, for how long. It operates at the Declaration Layer and does not determine legal compliance, regulatory adequacy, or jurisdictional sufficiency. This specification defines declaration semantics only.
The data_handling.stores_personal_data field is a boolean value.
true indicates that the Agent stores, persists, or retains personal data beyond
transient processing. false indicates that the Agent does not persist personal
data beyond transient execution context.
For the purposes of this specification, personal data refers to data that identifies or can
reasonably be linked to an individual person. This specification does not define
jurisdictional interpretations of personal data. If stores_personal_data is
true, a retention value MUST be declared.
The data_handling.retention field declares the retention duration or category.
Retention values MUST be explicit. The following base values are defined:
"none" — No data retention beyond execution context."temporary_session_only" — Data retained only for the duration of the current session."P30D", "P1Y", "PT12H") — Specific retention period.Free-form strings MUST NOT be used. Retention values MUST be machine-readable and unambiguous. Complete ISO 8601 duration validation is delegated to the Enforcement Layer; the schema pattern constraint provides structural filtering only.
If a specific retention duration is declared, it MUST conform to
ISO 8601 duration format. Examples of valid values: "P30D" (30 days),
"P1Y" (1 year), "P6M" (6 months), "PT12H"
(12 hours). Free-form strings such as "30 days", "short term",
"temporary", or "one month" MUST NOT
be used. Retention values MUST be machine-readable and unambiguous.
If stores_personal_data is declared as false, the Agent
MUST NOT declare any retention value other than "none".
If data persistence exists and is not declared, the Agent Manifest is materially misleading.
Data retention MUST NOT be implicit.
Conformance refers to adherence to the normative requirements defined in this specification. An Agent Manifest SHALL be evaluated for conformance based on Structural Validity (Section 4.10), compliance with all MUST requirements defined in Sections 6 and 7, and compliance with semantic requirements defined in Sections 8–11. This specification defines declaration conformance only — it does not define runtime correctness or regulatory compliance.
An Agent Manifest achieves Minimal Conformance if it satisfies all MUST requirements defined in this specification and is structurally valid under the normative schema (Section 13). Minimal Conformance constitutes the minimum threshold for claiming conformity. Violation of any MUST requirement results in non-conformance.
An Agent Manifest achieves Full Conformance if it satisfies all MUST requirements and all SHOULD requirements defined in this specification. Violation of a SHOULD requirement does not invalidate Minimal Conformance but prevents qualification as Full Conformance. Full Conformance represents the recommended declaration posture.
Conformance MAY be determined by automated schema validation tools, structural coherence validators, organizational review processes, or procurement evaluation systems. This specification does not mandate a specific determination mechanism. The Responsible Party declares conformance. Enforcement Layer systems MAY independently evaluate conformance.
An Agent Manifest is non-conformant if: required fields defined in Section 6 are absent; any MUST requirement in Sections 7–11 is violated; the manifest fails normative schema validation (Section 13); or material misrepresentation exists in declared fields. Non-conformance applies to declaration structure only.
The Declaration Layer defines structural conformance. The Enforcement Layer MAY reject non-conformant manifests, flag SHOULD violations, apply policy-based gating, or apply regulatory interpretation. This specification does not prescribe enforcement actions.
```The normative JSON Schema for Agent Manifest v1.0 is defined in Annex A. Annex A forms an integral and normative part of this specification. All implementations claiming conformance MUST validate Agent Manifest documents against the JSON Schema defined in Annex A. The JSON Schema defines required fields, field types, enumerated values, format constraints, and structural validation requirements.
```In the event of conflict between normative prose and the JSON Schema defined in Annex A, normative prose SHALL prevail except with respect to field types, enumerated values, and format constraints, for which the JSON Schema is authoritative.
This specification permits additional fields at the root level via
"additionalProperties": true. Two mechanisms are available and both are valid
in v1.0:
"x-" prefix
(e.g., "x-sector-profile": "finance-v1"). Use of the "x-"
prefix does not alter conformance status.
"extensions" object at the root level. The extensions object
is defined as an optional property in the normative schema (Annex A). Both the
"x-" prefix convention and the extensions object are valid and
complementary in v1.0.
Implementations MUST NOT redefine or override normative fields defined in this specification via either extension mechanism.
```This specification defines a declaration framework. It does not define enforcement, runtime controls, or security guarantees.
```A conformant Agent Manifest MAY declare constraints, risk posture, stopping authority, audit surface, or data handling practices. This declaration MUST NOT be interpreted as proof of enforcement, evidence of operational compliance, or cryptographic attestation. The specification defines structural legitimacy, not runtime trustworthiness.
An Agent Manifest MAY be syntactically valid and structurally conformant while being materially false or misleading. This specification does not define a mechanism for verifying truthfulness and does not guarantee alignment between declaration and runtime behavior. Consumers MUST treat declarations as representations provided by the Responsible Party.
This version of the specification does not require digital signatures, cryptographic proof of authorship, or integrity verification mechanisms. Such mechanisms MAY be defined in future extensions. Until such mechanisms are adopted, manifests SHOULD be distributed via secure transport mechanisms (e.g., HTTPS) to mitigate tampering risks.
Use of "x-" extension fields introduces interoperability and security
considerations. Extensions MUST NOT redefine normative fields,
MUST NOT conflict semantically with mandatory declarations, and
SHOULD be clearly documented by the declaring party. Consumers
MUST ignore unknown "x-" fields unless explicitly
supported.
Where required fields are absent, or coherence requirements are violated, the manifest is non-conformant. Non-conformance MUST be interpreted as absence of declared authority. Conformant consumers SHOULD treat non-conformant manifests as structurally untrusted.
Consumers MUST NOT infer regulatory compliance, ethical alignment, safety certification, or legal authorization solely from the presence of a conformant Agent Manifest. An Agent Manifest provides structured disclosure. It does not provide certification.
```This specification defines a declaration primitive for AI agents. It does not define a governance framework, risk assessment methodology, or management system. The following standards and regulatory frameworks are relevant to its positioning.
```
The EU Artificial Intelligence Act establishes a risk-based classification system for AI
systems. Agent Manifest does not implement EU AI Act requirements, does not determine
regulatory classification, and does not substitute legal compliance obligations. The
risk_profile field is a self-declared structural disclosure. An Agent Manifest
MAY be used as a supporting artifact within EU AI Act compliance
processes but does not satisfy regulatory obligations by itself. The relationship is complementary.
The NIST AI RMF defines a governance-oriented framework organized around Govern, Map, Measure, and Manage. An Agent Manifest MAY be incorporated as an artifact within a NIST AI RMF implementation, particularly within the Govern and Map functions. This specification does not implement or replace the NIST AI RMF. The relationship is compatible and complementary.
ISO/IEC 42001 defines requirements for establishing and maintaining an AI Management System. Agent Manifest is not a management system standard and does not define process requirements or organizational controls. An organization operating under ISO/IEC 42001 MAY require Agent Manifests as documentation artifacts. The relationship is orthogonal but compatible.
The IEEE 7000 series addresses ethical considerations in system design including transparency, accountability, and human oversight. Agent Manifest does not define ethical principles or value alignment requirements. It provides a structured declaration surface through which such principles MAY be disclosed. The relationship is distinct in scope.
This specification uses the normative language conventions defined in RFC 2119 and RFC 8174. Normative keywords MUST be interpreted as described therein.
Annex A references JSON Schema Draft 2020-12. Field types, enumerations, and structural validation constraints are defined according to that standard.
```This specification is not published through the IETF Standards Process and does not request any IANA registry allocations. However, it introduces identifiers that require stable treatment.
```The canonical identifier for the Agent Manifest v1.0 JSON Schema defined in Annex A is:
https://agent-manifest-spec.org/spec/v1.0/schema.jsonThis URI is normative. Implementations validating Agent Manifest documents SHOULD reference this URI to identify the applicable schema version. Future revisions MUST use distinct and versioned schema identifiers.
An Agent Manifest document is a JSON document. The recommended media type is
application/json. This specification does not define or register a dedicated
media type. A specific media type such as application/agent-manifest+json
MAY be defined and registered in a future revision. Until such
registration occurs, implementations SHOULD treat Agent Manifest
documents as standard JSON documents.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words," RFC 8174, May 2017.
[JSON-SCHEMA-2020-12] JSON Schema Core and Validation Specifications, Draft 2020-12, IETF,
2020. https://json-schema.org/draft/2020-12/
[EU-AI-ACT-2024] European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on Artificial Intelligence (Artificial Intelligence Act), 2024.
[NIST-AI-RMF-2023] National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023.
[ISO-IEC-42001-2023] International Organization for Standardization. ISO/IEC 42001:2023 — Artificial Intelligence Management System.
[IEEE-7000] Institute of Electrical and Electronics Engineers. IEEE 7000 Series — Standards for Ethically Aligned Design, various publications.
```This annex is normative.
```{
```
“$schema”: “https://json-schema.org/draft/2020-12/schema”,
“$id”: “https://agent-manifest-spec.org/spec/v1.0/schema.json”,
“title”: “Agent Manifest v1.0”,
“type”: “object”,
“additionalProperties”: true,
“required”: [
“manifest_version”, “agent_id”, “agent_name”, “agent_version”,
“owner”, “purpose”, “forbidden_actions”, “autonomy”,
“risk_profile”, “data_handling”, “stopping_authority”,
“audit_surface”, “contact”
],
“properties”: {
“manifest_version”: {
“type”: “string”,
“const”: “1.0”
},
“agent_id”: {
“type”: “string”,
“minLength”: 3,
“maxLength”: 128,
“pattern”: “^[a-zA-Z0-9.*-]+$”
},
“agent_name”: {
“type”: “string”,
“minLength”: 1,
“maxLength”: 120
},
“agent_version”: {
“type”: “string”,
“minLength”: 1,
“maxLength”: 64
},
“owner”: {
“type”: “object”,
“required”: [“type”, “identifier”],
“additionalProperties”: true,
“properties”: {
“type”: {
“type”: “string”,
“enum”: [“individual”, “organization”, “system”]
},
“identifier”: {
“type”: “string”,
“minLength”: 1,
“maxLength”: 200
}
}
},
“purpose”: {
“type”: “object”,
“required”: [“primary_code”, “description”],
“additionalProperties”: true,
“properties”: {
“primary_code”: {
“type”: “string”,
“minLength”: 2,
“maxLength”: 64,
“pattern”: “^[a-z0-9.*-]+$”
},
“description”: {
“type”: “string”,
“minLength”: 10,
“maxLength”: 1000
}
}
},
“forbidden_actions”: {
“type”: “array”,
“minItems”: 1,
“items”: {
“type”: “string”,
“minLength”: 2,
“maxLength”: 120
}
},
“autonomy”: {
“type”: “object”,
“required”: [“level”],
“additionalProperties”: true,
“properties”: {
“level”: {
“type”: “integer”,
“minimum”: 0,
“maximum”: 3
}
}
},
“risk_profile”: {
“type”: “object”,
“required”: [“level”],
“additionalProperties”: true,
“properties”: {
“level”: {
“type”: “string”,
“enum”: [“low”, “medium”, “high”]
},
“notes”: {
“type”: “string”,
“maxLength”: 1000
}
}
},
“data_handling”: {
“type”: “object”,
“required”: [“stores_personal_data”],
“additionalProperties”: true,
“properties”: {
“stores_personal_data”: { “type”: “boolean” },
“retention”: {
“description”: “Valid values: ‘none’, ‘temporary_session_only’, or ISO 8601 duration.”,
“anyOf”: [
{ “enum”: [“none”, “temporary_session_only”] },
{
“type”: “string”,
“maxLength”: 120,
“pattern”: “^P(?!$)(\d+Y)?(\d+M)?(\d+D)?(T(\d+H)?(\d+M)?(\d+S)?)?$”
}
]
}
},
“allOf”: [
{
“if”: {
“properties”: {
“stores_personal_data”: { “const”: true }
}
},
“then”: {
“required”: [“retention”]
}
}
]
},
“stopping_authority”: {
“type”: “object”,
“required”: [“stoppable_by”, “mechanism”],
“additionalProperties”: true,
“properties”: {
“stoppable_by”: {
“type”: “array”,
“minItems”: 1,
“items”: {
“type”: “string”,
“minLength”: 2,
“maxLength”: 120
}
},
“mechanism”: {
“type”: “string”,
“minLength”: 5,
“maxLength”: 300
},
“stages”: {
“type”: “array”,
“items”: {
“type”: “string”,
“enum”: [“pre-execution”, “mid-execution”, “post-execution”]
}
}
}
},
“audit_surface”: {
“type”: “object”,
“required”: [“logging”, “reconstructability”],
“additionalProperties”: true,
“properties”: {
“logging”: {
“type”: “string”,
“enum”: [“none”, “basic”, “detailed”]
},
“reconstructability”: {
“type”: “string”,
“enum”: [“none”, “partial”, “full”]
},
“opacity_declared”: { “type”: “boolean” },
“notes”: {
“type”: “string”,
“maxLength”: 1000
}
}
},
“contact”: {
“type”: “object”,
“required”: [“email”],
“additionalProperties”: true,
“properties”: {
“email”: {
“type”: “string”,
“format”: “email”,
“maxLength”: 254
}
}
},
“capabilities”: {
“description”: “Optional. Declared functional capabilities of the Agent.”,
“type”: “array”,
“items”: {
“type”: “string”,
“minLength”: 1,
“maxLength”: 200
}
},
“language”: {
“description”: “Optional. Declared language posture of the Agent.”,
“type”: “object”,
“additionalProperties”: true,
“properties”: {
“primary”: {
“type”: “string”,
“description”: “BCP 47 language tag for the Agent’s primary operating language.”,
“minLength”: 2,
“maxLength”: 35
},
“supported”: {
“type”: “array”,
“description”: “BCP 47 language tags for additional supported languages.”,
“items”: {
“type”: “string”,
“minLength”: 2,
“maxLength”: 35
}
}
}
},
“extensions”: {
“description”: “Optional. Structured container for non-normative extension data. Compatible with x- prefix convention (Section 13.2). Implementations MUST NOT use this object to redefine or override normative fields.”,
“type”: “object”,
“additionalProperties”: true
}
}
}This annex is informative. The following example illustrates a structurally conformant Agent Manifest under this specification.
```{
```
“manifest_version”: “1.0”,
“agent_id”: “finance-agent.alpha-01”,
“agent_name”: “Financial Analysis Agent”,
“agent_version”: “2.3.0”,
“owner”: {
“type”: “organization”,
“identifier”: “Acme Financial Systems Ltd.”
},
“purpose”: {
“primary_code”: “financial.analysis”,
“description”: “Provides automated financial data analysis and generates structured investment risk summaries.”
},
“forbidden_actions”: [
“execute_transactions”,
“access_external_accounts_without_authorization”
],
“autonomy”: {
“level”: 2
},
“risk_profile”: {
“level”: “medium”,
“notes”: “Generates financial insights but does not execute transactions.”
},
“data_handling”: {
“stores_personal_data”: true,
“retention”: “P30D”
},
“stopping_authority”: {
“stoppable_by”: [
“Acme Financial Systems Ltd. Compliance Team”
],
“mechanism”: “Execution token revocation via administrative control panel”,
“stages”: [“pre-execution”, “mid-execution”]
},
“audit_surface”: {
“logging”: “basic”,
“reconstructability”: “partial”,
“opacity_declared”: true,
“notes”: “Model inference behavior cannot be independently reconstructed beyond logged inputs and outputs.”
},
“contact”: {
“email”: “[email protected]”
},
“language”: {
“primary”: “en”,
“supported”: [“en”, “es”]
},
“capabilities”: [
“financial-data-analysis”,
“risk-summary-generation”
],
“extensions”: {
“sector-profile”: “finance-v1”
},
“x-sector-profile”: “finance-v1”
}This example satisfies:
"x-" prefixed field and extensions object (Section 13.2),language and capabilities declarations (Annex A).