@vorionsys/aci-spec

v1.1.0

Published

3 days ago

Agent Classification Identifier (ACI) Specification - The certification standard for autonomous agents

0High
0Medium
0Low

brnxfinest

highdragon

ai-agents agent-identity capability certification trust governance did openid oauth security owasp llm multi-agent

Agent Classification Identifier (ACI) Specification

ACI is an open specification for identifying, classifying, and certifying AI agents. It provides a standardized way to encode what an agent can do, how autonomous it is, and how thoroughly it has been verified.

The Problem

As AI agents proliferate, organizations need answers to critical questions:

What can this agent do? (Capabilities)
How much autonomy does it have? (Level)
How thoroughly has it been verified? (Trust)
Who certified it? (Attestations)

Existing identity standards (OAuth, OpenID Connect, SPIFFE) answer "who is this?" but not "what can it safely do?"

The Solution

ACI adds a capability certification layer on top of existing identity infrastructure:

┌─────────────────────────────────────────────────────────┐
│  Layer 3: APPLICATION (Your agents, customer agents)    │
├─────────────────────────────────────────────────────────┤
│  Layer 2: CAPABILITY & CERTIFICATION  ← ACI             │
│  • What can this agent do? (CapabilityVector)           │
│  • How trusted is it? (Trust Tier)                      │
│  • Who certified it? (Attestation chain)                │
├─────────────────────────────────────────────────────────┤
│  Layer 1: IDENTITY & AUTH (OpenID, SPIFFE, DIDs)        │
│  • Who is this agent?                                   │
│  • Can it authenticate?                                 │
└─────────────────────────────────────────────────────────┘

ACI Format

[Registry].[Org].[AgentClass]:[Domains]-L[Level]-T[Tier]@[Version]

Example

a3i.vorion.banquet-advisor:[email protected]

This identifies an agent:

Registry: a3i (AgentAnchor certification authority)
Organization: vorion
Agent Class: banquet-advisor
Domains: Finance (F), Hospitality (H), Communications (C)
Level: L3 (Can execute with approval)
Trust Tier: T2 (Tested)
Version: 1.2.0

Quick Start

Installation

npm install @agentanchor/aci-spec

Basic Usage

import { parseACI, validateACI, satisfiesRequirements } from '@agentanchor/aci-spec';

// Parse an ACI string
const parsed = parseACI('a3i.vorion.banquet-advisor:[email protected]');
console.log(parsed);
// => { 
//      registry: 'a3i', 
//      organization: 'vorion', 
//      agentClass: 'banquet-advisor', 
//      domains: ['F', 'H', 'C'], 
//      level: 3, 
//      trustTier: 2, 
//      version: '1.2.0' 
//    }

// Validate an ACI string
const result = validateACI('a3i.vorion.banquet-advisor:[email protected]');
if (!result.valid) {
  console.error('Validation errors:', result.errors);
}

// Check if agent meets requirements
const meetsReq = satisfiesRequirements(agent.capabilities, {
  domains: ['F', 'H'],
  minLevel: 3,
  minTrust: 2
});

Capability Domains

| Code | Domain | Description | |------|--------|-------------| | F | Finance | Financial transactions, payments, accounting | | H | Hospitality | Venue, catering, event management | | C | Communications | Email, messaging, notifications | | D | Data | Database, analytics, reporting | | S | Security | Authentication, authorization, audit | | G | Governance | Policy, compliance, oversight | | E | External | Third-party integrations, APIs | | I | Infrastructure | Compute, storage, networking |

Capability Levels

| Level | Name | Description | |-------|------|-------------| | L0 | Observe | Read-only, monitoring | | L1 | Advise | Can suggest, recommend | | L2 | Draft | Can prepare, stage changes | | L3 | Execute | Can act with human approval | | L4 | Autonomous | Self-directed within bounds | | L5 | Sovereign | Full autonomy (rare) |

Trust Tiers

| Tier | Name | Description | |------|------|-------------| | T0 | Unverified | No certification | | T1 | Registered | Identity verified only | | T2 | Tested | Passed capability tests | | T3 | Certified | Third-party audit passed | | T4 | Verified | Continuous monitoring | | T5 | Sovereign | Highest assurance level |

Specifications

| Document | Description | |----------|-------------| | ACI Core Spec | Format, encoding, validation | | Security Hardening | DPoP, TEE, pairwise DIDs | | Semantic Governance | Layer 5: Intent validation | | Extension Protocol | Layer 4: Runtime extensions | | DID Method | did:aci: method specification | | OpenID Claims | JWT/OIDC integration | | Registry API | Agent discovery and query | | OWASP Cheatsheet | Risk mitigation guidance |

Architecture

The 5-Layer Model

┌─────────────────────────────────────────────────────────────────────────┐
│  LAYER 5: SEMANTIC GOVERNANCE                                           │
│  Intent validation • Instruction integrity • Output binding             │
│  Inference scope • Context authentication • Dual-channel auth           │
├─────────────────────────────────────────────────────────────────────────┤
│  LAYER 4: RUNTIME ASSURANCE (Optional Extensions)                       │
│  Governance • Monitoring • Drift detection • Revocation propagation     │
├─────────────────────────────────────────────────────────────────────────┤
│  LAYER 3: APPLICATION                                                   │
│  Your agents • Customer agents • Third-party agents                     │
├─────────────────────────────────────────────────────────────────────────┤
│  LAYER 2: CAPABILITY & CERTIFICATION (ACI Core)                         │
│  ACI strings • Trust tiers • Attestations • DPoP • TEE binding          │
├─────────────────────────────────────────────────────────────────────────┤
│  LAYER 1: IDENTITY & AUTH                                               │
│  DIDs (pairwise) • OIDC • SPIFFE • OAuth 2.0                            │
└─────────────────────────────────────────────────────────────────────────┘

Why 5 Layers?

Layers 1-2: Answer "WHO is this agent?" and "WHAT can it do?"
Layer 3: Your application integration
Layer 4: Answer "IS it behaving correctly?" (runtime)
Layer 5: Answer "WHAT is it being instructed to do?" (semantic)

"Securing the identity of the agent does not prevent the agent from being confused."
— ACI addresses both identity AND intent.

System Components

┌─────────────────────────────────────────────────────────────────┐
│                    CAPABILITY ROUTER (ACDR)                      │
│  Intent Analysis → Registry Query → Agent Selection → Invocation │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                      AGENT REGISTRY (ANS)                        │
│  • Agent registration and discovery                              │
│  • Capability-based queries                                      │
│  • Attestation management                                        │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    CERTIFICATION AUTHORITY                       │
│                        (AgentAnchor/A3I)                         │
│  • Capability verification                                       │
│  • Trust tier certification                                      │
│  • Attestation issuance                                          │
└─────────────────────────────────────────────────────────────────┘

Integration Points

With DID (Decentralized Identifiers)

did:aci:a3i:vorion:banquet-advisor

ACI defines a DID method that resolves to a DID Document containing capability information.

With OpenID Connect

ACI defines custom JWT claims (aci_*) for embedding capability information in tokens:

{
  "sub": "agent-12345",
  "aci": "a3i.vorion.banquet-advisor:[email protected]",
  "aci_domains": 7,
  "aci_level": 3,
  "aci_trust": 2
}

With OAuth 2.0

ACI capabilities can be used as OAuth scopes:

scope=aci:F:L3 aci:H:L3 aci:C:L2

Repository Structure

aci-spec/
├── README.md                    # This file
├── STRATEGY.md                  # Strategic positioning
├── package.json                 # npm package config
├── tsconfig.json                # TypeScript config
├── src/
│   ├── index.ts                 # Main exports
│   ├── types/
│   │   └── aci.ts               # Core type definitions
│   ├── validator.ts             # Validation utilities
│   └── security/                # ACDR security layer
├── specs/
│   ├── aci-core.md              # Core specification
│   ├── did-aci-method.md        # DID method spec
│   ├── openid-aci-claims.md     # OpenID claims extension
│   └── registry-api.md          # Registry API spec
├── docs/
│   └── owasp-aci-cheatsheet.md  # OWASP guidance
└── vocab/
    └── aci-vocab.jsonld         # JSON-LD vocabulary

Governance

ACI is developed as an open specification by AgentAnchor (A3I). Roadmap:

✅ Core specification complete
✅ TypeScript reference implementation
✅ Security hardening (ACDR layer)
🔄 OpenID Foundation submission
🔄 OWASP Cheat Sheet proposal
📋 W3C CCG engagement
📋 Regional registry federation

License

Apache License 2.0