Agent Capability and Profile Model (ACPM)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

As of mid-2026, the AI agent ecosystem has converged on two adjacent but distinct interoperability problems. The first is how to express a portable, runnable agent definition so that an agent built on one runtime can be executed on another; this is the problem the Autonomous Agent Interchange Format (AAIF) [SC-006] addresses. The second is how to discover an agent within a registry or marketplace; this is the problem the Agent Registry (AREG) addresses. Neither problem encompasses a third, equally common need: describing, comparing, and reasoning about what an agent, the platform running it, the tools it calls, or the underlying model actually offers.¶

Today this information is scattered across marketing pages, ad hoc vendor-specific JSON, ASCII tables in README files, and human-readable documentation that changes shape from vendor to vendor. There is no canonical way to ask, in a machine-checkable way, whether a given subject supports a particular capability and at what fidelity, what evidence backs a trust claim about that subject, what it costs to use, what service level applies, or under what conditions it may delegate work to, or accept delegated work from, another subject. Registries and orchestrators that need this information today either write bespoke parsers per vendor or forgo capability, trust, and cost comparison entirely.¶

This document specifies the Agent Capability and Profile Model (ACPM), a portable, vendor-neutral format for a capability profile: a standalone description of what a subject offers. ACPM is deliberately scoped to be orthogonal to, and composable with, both the runnable agent definition problem and the registry discovery problem; it does not replace either.¶

2. Terminology

ACPM document / profile

A JSON instance conforming to the ACPM profile schema.¶

Subject

The agent, platform, tool, or model that a profile describes.¶

Capability

A dot-namespaced runtime feature string a subject may offer, paired with a declared support level.¶

Producer

Software or a person that publishes an ACPM profile.¶

Consumer

Software that reads an ACPM profile to make a capability-matching, trust-gating, cost, or service-level decision.¶

Conformance level

One of the five cumulative conformance levels defined in Section 6 that a profile satisfies.¶

Condition

The structured-or-string gating type used in delegation rules, reused without modification from the Autonomous Agent Interchange Format. See Section 5.¶

3. Design Principles

ACPM is built on six design principles:¶

1. Claims, not contracts. A profile states what the subject claims to offer. ACPM does not itself verify any claim; a Consumer that requires assurance MUST perform its own verification.¶
2. Vocabulary-compatible with AAIF. Capability identifiers SHOULD use the same dot-namespaced strings as the Autonomous Agent Interchange Format's required-capability vocabulary, so an agent's declared needs and a profile's declared offerings can be compared directly.¶
3. Composable, not coupled. ACPM cross-references agent definitions and registry entries by identifier reference; it does not import or extend their schemas, so each specification can evolve independently.¶
4. Comparable by construction. Every offer-side concept — capability support, trust level, cost, service level — uses a closed, ordered, or structured vocabulary rather than free text, so two profiles can be diffed or ranked mechanically.¶
5. Strict by default, extensible at the edges. Every object disallows additional properties, with a reserved extension-key namespace at the document root for forward compatibility and vendor metadata.¶
6. Honest about enforceability. Fields describing trust, attestation, and signature are explicitly documented as advisory unless a Consumer independently verifies them. This specification does not imply a cryptographic guarantee it does not provide.¶

4. ACPM Document Structure

An ACPM profile is a JSON object validated against the ACPM profile schema (JSON Schema draft 2020-12 [JSON-SCHEMA]). The minimum conformant document requires only two top-level fields:¶

{
  "sc_standard": "SC-014",
  "subject": { "subject_type": "agent", "name": "Example Agent" }
}

The full object model is organised as follows:¶

CapabilityProfile (root)
  sc_standard       "SC-014"  (required)
  sc_version        string (semver, default "1.0.0")
  profile_id        string (UUID)
  subject           (required)
    subject_type    agent | platform | tool | model
    name / vendor / version / homepage
    sc_refs[]       cross-references to other Schema Commons documents
  capabilities[]    id / support / version_constraint / notes
  tools[]           protocol / max_concurrent_calls / auth_methods[]
  models[]          provider / model_id / context_window / modalities[]
  memory[]          backend / scopes[]
  trust
    level       untrusted | sandboxed | verified | attested | enterprise
    attestation  issuer / method / evidence_url / issued_at / expires_at
    sandbox          isolation / network_egress
  cost_profile
    pricing_model    free | usage_based | subscription | tiered | custom
    currency / unit_cost / free_tier
  sla
    uptime_pct / p50_latency_ms / p99_latency_ms
    support_tier / incident_response
  delegation_rules[]
    direction / target / condition / action
  compliance
    data_residency[] / certifications[] / pii_handling
  provenance
    authored_by / created_at / updated_at / license / signature

5. Condition Expressions

The delegation_rules[].condition field accepts a Condition value, reused without modification from the Autonomous Agent Interchange Format. The structured form (RECOMMENDED) is an object naming an expression language and an expression:¶

{ "lang": "cel", "expr": "request.network_egress != 'full'" }

Supported languages are jsonpath, jmespath, cel (Common Expression Language), jsonlogic, always (constant true), and never (constant false). A bare string is also accepted as a non-deterministic, natural-language hint and MUST NOT be relied upon for portable, reproducible gating.¶

A Consumer that supports a declared lang MUST evaluate the structured form deterministically. A Consumer that does not support a declared lang MUST treat the rule as unsatisfiable-unknown and apply a conservative default — deny for an outbound rule, reject for an inbound rule — rather than silently treating it as satisfied.¶

6. Conformance Levels

ACPM defines five cumulative conformance levels. As with the Autonomous Agent Interchange Format, conformance is self-certified; there is no central certifying authority.¶

A profile claiming a given level satisfies every predicate of all lower levels as well. At the time of writing, ACPM does not yet have a machine-readable conformance report schema or public test corpus comparable to those defined for the Autonomous Agent Interchange Format; level claims are presently verified by inspection against this table rather than by an automated suite.¶

7. Related Work and Mapping to Prior Art

ACPM's overall design intent parallels the Open Cybersecurity Schema Framework: one canonical schema so that disparate parties describe the same kind of thing — there, security events; here, agent capabilities, trust, cost, and service level — in a comparable way.¶

Three further efforts overlap with ACPM closely enough to warrant explicit discussion rather than a one-line table entry. The first is [HACP] ("HACP: A Capability-Contract Protocol for AI Agents and Edge Hardware"), an active IETF individual submission defining a JSON-RPC 2.0 protocol through which an LLM agent discovers, plans, executes, observes, and audits operations against physical edge hardware (GPIO, I2C, UART, sensors) via a security-checked daemon. Its servers register an immutable tool set at startup, each tool carrying a risk level from zero to three, and a session is capped at a configured maximum risk level that it MUST NOT exceed when executing a tool. This is the same underlying idea ACPM generalizes — declare what a subject can do, and at what risk or trust tier, before a consumer relies on it — but HACP is narrowly scoped to hardware control, statically declared with no dynamic capability negotiation, and organized around risk tiers rather than ACPM's combination of trust, cost, service level, and delegation. HACP is cited here as a narrow, complementary precedent for capability-contract thinking, not as a competing general-purpose effort.¶

The second is a still-forming discovery-metadata effort within the Model Context Protocol itself. The MCP development roadmap [MCP-ROADMAP], as published 2026-03-05, lists under "Transport Evolution and Scalability" a planned "MCP Server Cards" standard: structured server metadata exposed via a well-known URL so that browsers, crawlers, and registries can discover a server's capabilities without connecting to it, attributed to a "Server Card WG" coordinating with what the roadmap calls "the broader industry AI-catalog effort." This is directly adjacent to an ACPM profile with subject_type "platform" or "tool": both are machine-readable, well-known-style capability and metadata documents intended for discovery without a live connection. The relevant framing is superset and instance, not competition: MCP Server Cards are scoped specifically to MCP servers, while ACPM is protocol-agnostic, spans agent, platform, tool, and model subjects, and additionally expresses cost, service level, trust, and delegation that a server card is not designed to carry. An ACPM profile of subject_type "tool" describing an MCP server SHOULD be designed so that its capability- and protocol-relevant fields are exportable as, or trivially mappable to, a future MCP Server Card. Because the Server Card WG appears to have only just been chartered as of the cited roadmap snapshot, this mapping is necessarily provisional; see PUBLISHING.md Section 0 for the re-check required before any concrete compatibility claim is finalized.¶

The third is the Agent Bill of Materials (AgBOM) concept referenced by the OWASP Agent Observability Standard (AOS) project [OWASP-AOS], which proposes inventorying what an agent or system is built from — models, tools, dependencies — using existing software-supply-chain formats such as CycloneDX, SPDX, and SWID. AgBOM overlaps with ACPM's subject, tools, and models inventory fields, but its center of gravity differs: AgBOM concerns supply-chain provenance and inventory (what is inside a subject, for vulnerability and license tracking), while ACPM concerns runtime capability, trust, cost, and service-level declaration (what a subject can do, and on what trust and cost terms it can be relied upon). The two are complementary; a profile's subject.sc_refs array MAY point at a companion AgBOM document for supply-chain detail ACPM itself does not capture.¶

No effort found during this review combines capability support level, trust and attestation, cost, service level, and delegation rules into a single vendor-neutral document spanning agent, platform, tool, and model subjects the way ACPM does. The closest individual pieces — HACP's risk tiers, MCP Server Cards' discovery metadata, and AgBOM's inventory model — each cover one facet of this narrowly and within a single domain. What is new in ACPM is the combination and its cross-domain generality, not any single constituent idea in isolation.¶

Open Container Initiative image manifests

An OCI image manifest declares what is actually present in an image, not merely what was intended. ACPM's capability support levels (native, emulated, partial, none) apply the same "declare what is actually there" discipline to agent capabilities.¶

NIST capability maturity models

ACPM's four-level support axis is a simplified maturity assessment in the spirit of staged capability maturity frameworks, scoped to a single binary-leaning feature rather than an organisational process.¶

Cloud provider service catalogs

Service catalog listings (for example, marketplace entries for managed cloud services) enumerate what a service exposes and its operational limits. ACPM's tools, models, and memory inventories serve an analogous purpose for AI agent capabilities.¶

Agent2Agent (A2A) Agent Cards

An Agent Card [A2A] is a deliberately minimal discovery document advertising identity, capability tags, and an endpoint URL. ACPM extends this with an explicit trust, attestation, sandbox, cost, and service-level model that an Agent Card does not specify, while remaining compatible in spirit with the discovery use case.¶

Model Context Protocol (MCP) capability negotiation

MCP [MCP] servers and clients negotiate supported capabilities at connection time via an initialize handshake. ACPM's tools array is a static, publishable analogue of that runtime negotiation, suitable for offline comparison before a connection is ever established.¶

8. Security Considerations

ACPM is a claims format, not a verification protocol. Every field in a profile MUST be treated by a Consumer as a self-reported claim by the subject, or by whoever published the profile on the subject's behalf, unless the Consumer independently verifies it. This specification does not provide, and does not imply, a cryptographic guarantee of any claim's accuracy.¶

A profile MAY declare trust.level "enterprise" with no supporting evidence. A Consumer making a consequential trust decision SHOULD require a verifiable attestation (method "third_party" or "formal_audit") with a reachable evidence_url and an unexpired attestation.expires_at before relying on an "attested" or "enterprise" claim.¶

Capability support claims are asserted, not tested, by this specification. A Consumer performing capability matching for a safety-relevant feature SHOULD independently probe the subject before trusting a "native" support claim for that purpose.¶

Cost and service-level claims are point-in-time and unverified. ACPM does not currently distinguish a contractually committed figure from an observed historical one. A Consumer making a procurement or routing decision of consequence SHOULD corroborate such claims against independent monitoring.¶

The provenance.signature field is advisory. ACPM does not mandate a signature scheme, key-distribution mechanism, or verification behaviour. A Consumer that requires provenance assurance SHOULD treat a profile lacking a signature it can independently verify as equivalent to trust.level "untrusted", regardless of what trust.level the profile itself declares.¶

A delegation rule naming a Condition language a Consumer does not implement MUST be treated as unsatisfiable-unknown, with a conservative default applied (deny for outbound, reject for inbound). Silently treating an unsupported Condition as satisfied is a conformance violation and could permit unintended delegation.¶

Nothing in ACPM cryptographically binds a profile document to the real-world subject it claims to describe, beyond the advisory subject.sc_refs cross-reference. A Consumer SHOULD only trust profiles obtained from a channel it already trusts (the subject's own domain, or a registry it already trusts) rather than an arbitrary, unauthenticated URL.¶

9. IANA Considerations

This document requests no IANA actions. ACPM's capability identifiers (the dot-namespaced strings used in the capabilities array) currently form an open, convention-based vocabulary shared informally with the Autonomous Agent Interchange Format's required-capability vocabulary, with no registry operator. A future revision of this document or an accompanying document may propose a community-operated or IANA-operated registry for capability identifiers, analogous to the extension registries described for the Autonomous Agent Interchange Format, should the vocabulary's growth warrant centralised coordination.¶

Author's Address