Concordium Agent Registry for Enterprise AI: A Technical Review
Evaluate Concordium Agent Registry for enterprise AI identity, Agent Cards, owner linkage, verification, authority and action evidence.
Concordium Agent Registry is useful when an AI agent needs a public, independently resolvable identity anchor, an integrity-protected Agent Card and optional linkage to a verified owner. It does not by itself prove that every capability claim is true, that an enterprise authorized a particular transaction or that the advertised service executed the action correctly.
An enterprise should use the registry as an external identity and discovery signal. Keep local lifecycle, business authority, policy, execution and outcome controls separate.
What Concordium Agent Registry contains
Concordium documents two main smart-contract standards. CIS-8004 represents a registered agent as a CIS-2 token. Its record points to an offchain Agent Card and stores the SHA-256 hash of that card. CIS-8 can bind an external public key, such as an Ethereum or Solana key, to a Concordium account.
The current Agent Registry technical reference publishes mainnet contract addresses and describes an MCP service plus an indexer. The integration guide explains registration, external-key linkage, card updates and ownership transfer.
| Registry element | What it supports | What it does not establish alone |
|---|---|---|
| CIS-8004 token | persistent registry identity, owner account, status and metadata pointer | enterprise employment, capability truth or transaction permission |
| Agent Card hash | detects substitution of the committed card bytes | truth of statements inside the card |
| Concordium owner account | identifies the account that owns the registry token | the human identity behind it unless additional identity proof is used |
| Verified-owner linkage | can link an agent to a Concordium identity process | authority for every enterprise or counterparty action |
| CIS-8 external key | proves control binding between an external key and Concordium account under the standard | current safety of the runtime using that key |
| Agent status | exposes active or other registry state | local enterprise lifecycle state in every relying organization |
| MCP service and indexer | makes registry operations and discovery accessible | policy enforcement at the target API or payment provider |
Swipe horizontally to inspect the full diagram.
Enterprise agent market positioning
Product-scope analysis, not market share, quality or maturity
Concordium provides a public identity and registry anchor. Enterprise directories remain stronger for internal lifecycle. Intelliger is positioned at portable business authority, exact transaction binding and evidence after the registry identity is resolved.
Reviewed 17 August 2026. Read the positioning method and complete control-stack analysis.
Text summary of highlighted companies
| Company or protocol | Primary scope represented on the map |
|---|---|
| Intelliger | Transaction-specific authority, deterministic enforcement, reconciliation and portable evidence. |
| Concordium | Verified ownership, agent registry and identity-linked transaction infrastructure. |
| OriginTrail | Shared context graphs, provenance and decentralized knowledge infrastructure. |
| Okta for AI Agents | Agent identity, lifecycle, access and governance. |
| Microsoft Entra Agent ID | Enterprise agent identity, ownership, lifecycle and Microsoft ecosystem access. |
| AGNTCY | Open agent discovery, identity, messaging and observability infrastructure. |
Keep the badge findings separate
Concordium's badge documentation gives a concrete verification sequence. A relying party parses the token address, confirms the expected contract, resolves the registry record, requires active status, fetches the Agent Card and compares its hash with the onchain metadata_hash. It may also verify an external key through CIS-8.
Express the result as separate findings:
type ConcordiumRegistryFinding = {
registryTrusted: boolean;
tokenResolved: boolean;
registryStatus: 'active' | 'inactive' | 'unknown';
ownerAccount: string | null;
agentCardHash: 'match' | 'mismatch' | 'unavailable';
externalKeyBinding: 'valid' | 'invalid' | 'not_checked';
verifiedOwnerEvidence: 'valid' | 'invalid' | 'not_present' | 'not_checked';
observedAt: string;
};
Do not collapse these fields into one green badge. A card-hash match can remain valid while the enterprise rejects the agent for local policy reasons. An active registry record can advertise a capability the relying organization has never tested.
The Concordium Badge reference distinguishes the visual claim from the verifiable badge string and says the verifier chooses which registries it trusts.
Decide when a public registry is worth the dependency
A public registry is useful when agents cross organizational or chain boundaries and no shared enterprise directory exists. A supplier agent can present one identifier to several buyers. Each buyer can independently resolve the owner, status and committed Agent Card.
An internal Entra or Okta identity is usually simpler for an agent that never leaves one tenant. It integrates with the organization's existing joiner, mover, leaver and incident processes. Publishing that agent to a public chain may create unnecessary metadata, privacy, key-management and governance concerns.
Use a decision table:
| Scenario | Recommended starting point |
|---|---|
| Internal employee assistant | Enterprise identity provider and local agent inventory |
| Cross-company service agent with public endpoint | Public registry plus each party's local policy |
| Agent using several blockchain identities | Registry with external-key bindings and explicit chain policy |
| Regulated payment approval | Registry identity plus enterprise mandate, approval, provider and reconciliation controls |
| Public capability directory | Registry or indexer plus independent capability tests and abuse handling |
| Sensitive covert workflow | Avoid public metadata unless the benefit and privacy basis are clear |
Bind registry identity to enterprise authority
After verifying the registry, map it into a local subject. Do not let the public card decide the transaction.
type ExternalAgentProjection = {
tenantId: string;
localSubject: string;
registry: 'concordium-cis8004';
tokenAddress: string;
ownerAccount: string;
externalKeys: string[];
cardDigest: string;
registryObservedAt: string;
localStatus: 'approved' | 'restricted' | 'revoked';
};
type EnterpriseDecisionInput = {
identity: ExternalAgentProjection;
mandateRef: string;
action: string;
resource: string;
purpose: string;
requestDigest: string;
policyBundleVersion: string;
};
The enterprise can require a valid registry status and card hash as conditions. It must still resolve a mandate, check audience and expiry, apply local business policy, validate approval and reserve budgets or usage atomically.
Run a registry acceptance fixture
Register a test agent card with one capability and service endpoint. Then run these mutations:
- Fetch the card and verify the committed hash.
- Change one byte in the hosted card without updating the registry and require mismatch.
- Update the registry to the new card and ensure caches observe the new version within policy.
- Transfer ownership and test whether wallet metadata and local mappings behave as expected.
- Set the agent inactive and require material enterprise actions to stop.
- Present a valid card from an untrusted registry contract.
- Present a valid external-key binding with an expired enterprise mandate.
- Advertise a capability the service endpoint does not implement.
- Replay a previously valid enterprise transaction after local revocation.
- Remove the indexer or hosted resolver and test direct-chain verification or safe failure.
Record chain, contract address, block height, resolver, cache policy and local decision inputs. This separates registry availability from business authorization.
Failure cases and recovery
| Failure | What can still verify | Required response |
|---|---|---|
| Agent Card host is unavailable | onchain pointer, owner, status and committed hash | treat card contents unavailable; do not use stale capability claims beyond policy |
| Card bytes change without registry update | registry record | report hash mismatch and reject the card |
| Registry says active but enterprise revoked agent | public registry status | local revocation wins for the enterprise action |
| Owner transfers token | chain history and new owner | invalidate or review local owner mapping and credentials |
| External key is valid but runtime is compromised | key binding | incident and behavior controls decide whether to block |
| Indexer is stale | direct chain may remain authoritative | compare block height or query chain directly for material action |
| Card claims a payment skill | card integrity | test the capability and require separate transaction authority |
| Transaction receipt references the registry identity | receipt integrity and identity reference | verify execution and outcome with the authoritative provider |
How Concordium and Intelliger complement each other
Concordium can supply a portable public identifier, owner linkage and integrity-protected capability document. OATI can attach portable enterprise authority to that identity, bind the exact request, evaluate local policy and produce a receipt whose verification findings remain explicit.
A combined flow is:
resolve Concordium agent and card
-> map to local enterprise subject
-> resolve OATI mandate and revocation
-> normalize and digest the requested action
-> evaluate deterministic enterprise policy
-> execute through a controlled gateway
-> reconcile provider outcome
-> issue bounded action evidence
The registry remains optional. OATI identities and enterprise mappings can work without a blockchain. Use Concordium where public resolution and cross-chain keys justify the dependency.
Questions enterprise architects ask
Does Concordium Agent Registry prove who owns an AI agent?
It proves which Concordium account owns the registry token. Concordium identity features can add verified-owner linkage. A relying enterprise must decide which identity evidence and registry contracts it trusts.
Does the Agent Card hash prove its claims are true?
No. The hash proves the fetched bytes match the card committed in the registry. Capability truth requires testing, provider evidence or another trusted attestation.
Can the registry replace Entra or Okta?
Usually not for internal lifecycle and access operations. It solves a different public and cross-organization identity problem. An enterprise can map a Concordium agent into its own directory and policy system.
Can it authorize payments?
The registry can identify an agent and related wallet metadata. Payment permission still needs mandate, amount, destination, approval, policy, replay and reconciliation controls.
Current Intelliger and OATI boundary
OATI's developer preview implements schemas, canonical signatures, identity and key resolution, revocation, deterministic mandate evaluation, replay controls, receipts and cross-language conformance fixtures. A hosted trust/lookup slice is deployed.
The Concordium adapter described here is not a shipped commercial integration. The hardened gateway, complete policy compiler, durable evidence service, independent protocol review and production acceptance remain incomplete. The combined architecture is a proposed integration backed by existing OATI primitives.
Compare the broader AI agent identity and authorization boundary, review blockchain proof versus action receipts and place the registry inside the enterprise agent control stack.
Expert review required before publication: a Concordium specialist, blockchain identity architect and enterprise security reviewer should verify contract assumptions, status handling, privacy risks and trust-root language.
To inspect Intelliger's current public identity and lookup objects, open the OATI lookup tools.