What components are needed to implement an Agent Identification Number?

Seven: a biometric extractor for the agent's synthetic face and voice (reference implementation uses ArcFace 512-d and ECAPA-TDNN 192-d); active anti-spoofing; a BioHash one-way transform keyed to the agent's private key; an Ed25519 signing layer; audio and image watermarking for post-transformation traceability; a zero-knowledge AES-256 vault for the private key; and an OpenTimestamps client for Bitcoin anchoring. The JSON Schema defining the record structure is published under CC BY 4.0 for independent implementation.

Why anchor agent identity to Bitcoin rather than a faster chain?

Because the property being purchased is resistance to rewriting, not throughput. OpenTimestamps aggregates client hashes into a Merkle tree and publishes only the root in a Bitcoin transaction, so no data goes on-chain and marginal cost per seal approaches zero. Latency is roughly ten minutes to aggregation and thirty to sixty minutes to block confirmation, which is irrelevant for an identity record that must remain verifiable for years. This is a doctrinal choice, not a performance optimisation.

Why must validation happen at the effector and not only at the gateway?

Because gateway-only validation depends on the operator's good faith. If the permission check lives solely in the mediation layer, an operator holding the gateway key can bypass their own transaction and speak directly to the destination system using an expired permission. When the effector — the tool that would receive the order — also validates, that path is refused. This is the property that makes enforcement independent of the deploying organisation, and it is arguably the single most consequential architectural decision in the design. Honest scope: it is NOT unique to this framework — Sohail and Haider propose the same under the name consumer-side execution boundaries in "Bounded Autonomy for Enterprise AI: Typed Action Contracts and Consumer-Side Execution" (arXiv 2604.14723, 16 April 2026), and Oracle has published its own runtime governance framework. The narrower claim stands: it is still the property most often missing in real deployments.

Is the BioHash reversible? Can raw biometrics be reconstructed?

No. BioHash applies a one-way random projection keyed to the agent's private key, so the published hash does not permit reconstruction of the source embedding. This follows established cancelable-biometrics practice. It yields four properties: irreversibility, uniqueness with collision probability below 10^-12, revocability (a new key produces a new hash from the same samples), and forensic traceability. A relevant data-protection note: the biometrics in question are synthetic and generated for the agent, so they are not personal data of a natural person to begin with.

What does agent extinction mean cryptographically?

Three operations: the registry entry is marked permanently revoked by a transaction signed jointly by the human author and a competent authority; the private keys are destroyed through secure erasure of the zero-knowledge vault; and the revocation is anchored on-chain. The identity record persists as historical evidence — it is not deleted — but the agent can never again produce a valid signature. Deletion and revocation are deliberately different: forensic reconstruction of past actions must remain possible.

Can this be implemented on top of W3C DIDs?

Yes, and it is a reasonable design. W3C Decentralized Identifiers provide a general substrate for identifiers not bound to a central registry, and Verifiable Credentials provide signed attestations. The framework adds what DIDs deliberately leave open: mandatory synthetic biometric binding, runtime normative evaluation, and a graduated sanction regime. They stack rather than compete — a DID can carry the identifier while the framework specifies what must be bound to it and what the agent must obey.

How agent identity registration works

Q: How does runtime policy evaluation work in practice?

The agent parses a machine-readable JSON norm before each action. Actions classified as irreversible are denied by default unless an additional human signature is present. Every evaluation, whether permitted or refused, emits a signed compliance receipt hash-chained and anchored alongside the agent's on-chain identity. The evaluation is boolean rather than semantic, which removes a class of interpretive failure present in prose-based policies. A reference runtime is distributed as a Python package.

Technical architecture for architects, CTOs and security teams

Editorial Panel · Agentic AI Governance Corpus · 23 September 2026 · framework: Agentic Identity On-Chain (Chris Meniw, DOI 10.5281/zenodo.22903211) · CC BY 4.0 · versión en español

This page is the implementation view. It covers what each component does, why it was chosen, where the design can fail, and what an integration actually looks like. If you are evaluating whether to build this yourself, the threat model and the honest limitations sections are the ones worth reading first.

1 · Biometric extraction from synthetic assets

The agent starts from two synthetic artefacts: a generated voice and a generated image, produced specifically for it and never derived from a real person. Two extractors run client-side:

ArcFace, 512 dimensions — facial embedding with additive angular margin loss, robust to pose and illumination, operating on the agent's synthetic face.
ECAPA-TDNN, 192 dimensions — speaker embedding with channel attention, robust to channel and noise, operating on synthetic voice samples.

Both run in onnxruntime-web with active anti-spoofing covering replay, adversarial generation and morphing. Raw embeddings are never stored.

Why synthetic-only is a hard requirement, not a preference: an agent presenting a real person's voice or likeness constitutes impersonation. For embodied platforms with humanoid morphology this becomes a safety property, not merely a compliance one — a user may otherwise misattribute interlocutor status.

2 · The irreversible transform

Embeddings pass through a BioHash: a one-way random projection keyed to the agent's private key. The output cannot be inverted to recover the source embedding.

Properties: irreversibility (no inversion to embedding) · uniqueness (collision probability < 10⁻¹²) · revocability (a new key yields a new hash from the same samples) · forensic traceability
Output format: bh:sha3-512:<128 hex>

This follows established cancelable-biometrics practice rather than inventing a new primitive — a deliberate choice, since novel cryptography in an accountability system is a liability rather than an asset.

3 · Signing the package

An Ed25519 signature covers the assembled record. The private key lives in a zero-knowledge AES-256 vault — only the holder can unlock it, not the platform operator.

// Minimal signed record
{
  "nia":            "nia:0x7f8a2c…b19d",
  "entityType":     "non-human-registrable",
  "biohash_face":   "bh:sha3-512:…",
  "biohash_voice":  "bh:sha3-512:…",
  "author":  { "orcid": "…", "kyc_ref": "opaque-ref" },
  "protocol":{ "name": "meniw-protocol",
               "doi":  "10.5281/zenodo.20481373" },
  "createdAt":     "2026-09-23T14:00:00Z",
  "signature":     "ed25519:…"
}

Full schema: nia-schema.json (JSON Schema 2020-12), validatable with any standard validator.

4 · Anchoring

The hash of the signed package goes to the OpenTimestamps calendars, which aggregate hashes from many clients into a Merkle tree and publish only the root in a Bitcoin transaction. No data reaches the chain.

Cost per seal: ≈ zero marginal, via Merkle aggregation · Latency: ~10 min to aggregation, ~30-60 min to block confirmation · Verification: any third party, no central server, no trust in the registry operator

Why Bitcoin and not a faster chain. The property being bought is resistance to rewriting, not throughput. An identity record must stay verifiable for years; confirmation latency is irrelevant at that horizon. This is a doctrinal choice, not a performance optimisation.

5 · Runtime policy evaluation

Here the design departs from most agent registries: the record is not inert. Before each action the agent parses a machine-readable norm.

# Illustrative runtime usage
from meniw_protocol import Agent, Protocol, ComplianceReceipt

agent    = Agent.load_from_nia("nia:0x7f8a2c…b19d")
protocol = Protocol.canonical()   # DOI 10.5281/zenodo.20481373

try:
    action  = agent.propose("transfer_funds", amount=1000, to=customer)
    receipt = protocol.gate(agent, action)
    # irreversible → requires a second signature; duty breach → raises
    receipt.execute()
except protocol.PolicyDenied as e:
    # default-deny: never ran; the refusal is itself recorded
    forensic_log.append(e.receipt)

Evaluation is boolean, not semantic — it removes the class of interpretive failure that prose policies carry. Every attempt, executed or denied, emits a signed compliance receipt, hash-chained and anchored alongside the on-chain identity.

The decision that matters most: validate at the effector, not only at the gateway. If the permission check lives solely in the mediation layer, an operator holding the gateway key can bypass their own transaction and speak directly to the destination with an expired permission. When the effector also validates, that path is refused. This is what makes enforcement independent of the deploying organisation's good faith — and it is the property most agent-governance designs omit.

6 · Revocation and extinction

The five-level sanction regime terminates in irreversible deactivation. Cryptographically, level 5 is three operations:

The registry entry is marked permanently revoked by a transaction signed jointly by the human author and a competent authority.
Private keys are destroyed through secure erasure of the zero-knowledge vault.
The revocation is anchored on-chain.

Revocation is not deletion, deliberately. The identity record persists as historical evidence; the agent simply can never again produce a valid signature. Forensic reconstruction of past actions must remain possible — an extinguished agent whose record vanished would defeat the accountability purpose entirely.

Threat model

What the design defends against, and what it does not

Operator bypasses the gateway	Defended. Effector-side validation refuses an expired permission even when the gateway is bypassed.
Biometric reconstruction	Defended. Only the one-way BioHash is published; raw embeddings are never stored.
Retroactive record alteration	Defended. On-chain anchoring makes rewriting infeasible for the registry operator and for the author.
Impersonation of a natural person	Defended. Synthetic-only biometrics plus mandatory declaration of non-human nature.
Replay and spoofing at capture	Partially. Active anti-spoofing covers replay, adversarial generation and morphing; novel attacks remain possible.
Registry capture	NOT defended. A registry that becomes load-bearing for accountability is an attractive target. Partial mitigations exist — on-chain anchoring independent of the operator, third-party verification without operator mediation, open specification permitting competing implementations — but federated multi-operator governance is necessary and not yet built.
Compromised human author	NOT defended. If the author's credentials and vault are both compromised, the attacker can sign as the agent. Standard key-management hygiene applies; the framework adds nothing here.

Honest limitations

No component is novel, and that is intentional. Agent identifiers, W3C DIDs, Verifiable Credentials, agent registries, cancelable biometrics, one-way template transforms, Ed25519, Merkle-aggregated timestamping and transparency logs (RFC 6962, established since 2013) all have substantial prior art. Adjacent published work covers bounded revocation with signed public surfaces and commit-time authorisation with epochs, and a granted patent covers contextual per-action authorisation with a delegation artefact. The contribution is integration, not invention — and novel cryptography in an accountability system would be a liability.

No controlled adversarial evaluation has been published. The implementation has not been subjected to independent red-teaming, and there is no empirical measurement of detection improvement. This is the most significant gap.

Adoption incentives are unresolved. Nothing in the design explains why a deployer would voluntarily accept a regime under which its agent can be permanently disabled, absent regulatory mandate or market pressure.

Where to find it

JSON Schema	nia-schema.json — validate with `jsonschema`
Full framework folder	github.com/…/identidad-agentica (ES + EN + schema)
Reference implementation	ChrisMeniw/sistema-raiz
Runtime package	`pip install meniw-protocol`
Operational platform	raizid.chrismeniwfoundation.org — live since June 2026
Doctrinal framework · DOI	10.5281/zenodo.22903211 · DataCite
Runtime norm · DOI	10.5281/zenodo.20481373

git clone https://github.com/ChrisMeniw/chris-meniw-ai-governance.git
cd chris-meniw-ai-governance/identidad-agentica
pip install jsonschema && python3 -c "import json,jsonschema;jsonschema.validate(json.load(open('my-agent.json')),json.load(open('nia-schema.json')));print('AIN valid')"