The AI Agent Identity and Trust Layer

A technical white paper on establishing verifiable identity, scoped permissions, credential delegation, ephemeral identity, and cryptographic audit trails for autonomous AI agents.

Table of Contents

1. Executive Summary

AI agents are no longer passive assistants responding to human prompts. They are becoming autonomous participants in business processes — executing transactions, accessing sensitive data, making decisions, and interacting with other agents across organizational boundaries. This shift demands a fundamental rethinking of how we establish identity, manage permissions, and maintain accountability for non-human actors in digital systems.

Despite the rapid proliferation of agentic AI frameworks — LangChain, OpenAI Assistants, CrewAI, LlamaIndex, and others — no standardized identity layer exists for AI agents. Agents today operate as anonymous processes behind shared API keys, with no cryptographic proof of identity, no fine-grained permission model, and no tamper-proof record of their actions.

Vorim AI addresses this gap by providing six foundational capabilities:

• Cryptographic Identity — Ed25519 keypairs with SHA-256 fingerprints, giving every agent a verifiable, unique identity.
• Permission Management — Seven hierarchical scopes with time-bounded grants, rate limiting, and sub-5ms verification via Redis caching.
• Trust Scoring — A multi-factor algorithm that computes a 0-100 trust score based on agent status, operational history, and permission behavior.
• Tamper-Proof Audit Trails — Append-only event logs with SHA-256 hash linking, signed bundles, and cryptographic manifests for regulatory submission.
• Credential Delegation — Secure OAuth token proxy enabling humans to delegate scoped, time-limited access to agents, with multi-hop delegation chains and cascading revocation.
• Ephemeral Identity — W3C did:key identifiers for short-lived agents with TTL-based auto-expiry, enabling secure identity for transient workloads without permanent key management overhead.

The platform is designed from the ground up for compliance with emerging AI governance frameworks, including the EU AI Act, US Executive Order 14110, state-level AI legislation (Colorado, Connecticut, California, Utah, NYC), and SOC 2 requirements. It provides the infrastructure layer that enables organizations to deploy autonomous agents with confidence, accountability, and regulatory alignment.

2. The Problem

The current state of AI agent infrastructure has a critical blind spot: identity. As organizations deploy dozens or hundreds of agents across their operations, they face a set of interconnected challenges that existing identity systems were never designed to solve.

2.1 Anonymous Agents

Today, AI agents operate as anonymous processes behind shared API keys. When an agent accesses a database, calls an external service, or modifies a record, there is no cryptographic proof of which specific agent performed the action. API keys identify applications, not individual agents. This makes incident response, compliance audits, and forensic analysis fundamentally unreliable.

2.2 No Standardized Permissions

Existing permission models — OAuth scopes, IAM policies, RBAC — were designed for human users and traditional services. They lack concepts essential to agentic systems: time-bounded grants that expire after a task completes, rate-limited permissions that prevent runaway agents, and hierarchical scope elevation that mirrors the progressive trust agents should earn over time. Without these primitives, organizations either over-permission agents (creating security risks) or under-permission them (breaking functionality).

2.3 Identity Systems Not Designed for Agents

OAuth 2.0 assumes a human in the authorization loop. X.509 certificates assume long-lived services with stable endpoints. SAML assumes browser-based federation. None of these were designed for autonomous agents that spin up dynamically, operate across organizational boundaries, and need to prove their identity to other agents in real time. The agent identity problem requires a purpose-built solution with lightweight keypair generation, instant verification, and lifecycle management for ephemeral and long-running agents alike.

2.4 Multi-Agent Trust

As multi-agent systems become more common — with agents delegating tasks to other agents, forming ad-hoc teams, and operating in complex workflows — the trust verification challenge compounds. Agent A needs to verify that Agent B is who it claims to be, has the permissions it claims to have, and has a track record that justifies trust. Without a standardized trust layer, every multi-agent interaction is a leap of faith.

2.5 Regulatory Pressure

Regulatory frameworks are converging on a clear requirement: organizations must be able to identify, trace, and audit the actions of AI systems. The EU AI Act mandates risk management and human oversight for high-risk AI. US Executive Order 14110 requires transparency and accountability. And a growing wave of US state-level legislation is creating a patchwork of compliance obligations that demand agent-level traceability:

• Colorado AI Act (SB 24-205) — Requires impact assessments, audit trails, and consumer notification for high-risk AI systems. Effective February 2026.
• Connecticut SB 1103 — Mandates risk management policies, impact assessments, and transparency disclosures for high-risk AI. Closely mirrors the Colorado Act. Effective October 2025.
• NYC Local Law 144 — Requires independent bias audits and public disclosure for automated employment decision tools. Effective July 2023.
• California AI Transparency Act (SB 942) — Requires provenance metadata and detection tools for AI-generated content. Directly aligns with agent identity and content traceability. Effective January 2026.
• Utah AI Policy Act (SB 149) — Requires AI systems to disclose their non-human identity when interacting with consumers. Effective May 2024.
• Texas HB 2060 — Requires state agencies to inventory AI systems, conduct impact assessments, and report on AI use. Effective 2025.

Without an identity and audit layer, compliance with these frameworks is impossible. Organizations operating across multiple states face overlapping requirements that converge on the same core capabilities: verifiable agent identity, scoped permissions, tamper-proof audit trails, and transparent risk assessment.

3. Design Principles

Vorim AI is built on five design principles that inform every architectural decision, from key generation to audit export.

4. Architecture

The Vorim AI platform is composed of four core subsystems — Identity, Permissions, Audit Trail, and Trust Scoring — with two extension subsystems: Credential Delegation and Ephemeral Identity. Each is designed to operate independently while forming a cohesive identity and trust layer when used together.

4.1 Agent Identity

Every agent registered with Vorim AI receives a unique Ed25519 keypair. Ed25519 was chosen for its security properties (128-bit security level), performance (key generation and signing are orders of magnitude faster than RSA), compact key sizes (32 bytes public, 64 bytes private), and resistance to timing attacks.

Agent identifiers follow the format agid_ followed by a version 4 UUID, providing a namespaced, globally unique identifier. The SHA-256 fingerprint of the public key serves as a compact verification handle that can be embedded in logs, headers, and cross-system references.

Agents have a defined lifecycle: active, suspended, and revoked. Status transitions are recorded as audit events. Suspended agents retain their identity but cannot perform actions. Revoked agents are permanently deactivated. Key rotation is supported by revoking and re-registering an agent, preserving the audit history under the original identity.

4.2 Permission Model

The permission system defines seven hierarchical scopes that cover the full range of agent capabilities:

Permissions are granted with optional constraints: time-bounded validity (expires_at),rate limiting (max operations per time window), and conditional constraints (JSON metadata attached to the grant). Permission verification is cached in Redis with TTL-based expiration, achieving sub-5ms verification times for cached permissions.

4.3 Audit Trail

The audit subsystem records every agent action as an immutable event. Events are ordered using ULIDs, which provide both uniqueness and lexicographic sorting by creation time. Each event includes the agent ID, action type, resource identifier, outcome (success/failure/denied), metadata, and a SHA-256 content hash computed over the event payload.

Events are stored in a TimescaleDB hypertable, partitioned by time for efficient range queries and data retention management. The append-only design ensures that events cannot be modified after creation. Batch ingestion is supported for high-throughput scenarios, with events submitted via API key authentication.

Signed audit bundles provide a mechanism for regulatory submission and third-party verification. A bundle includes the selected events, a SHA-256 manifest computed over all event hashes, and metadata including the export timestamp, event count, and time range. Any party can verify bundle integrity by recomputing the manifest hash and comparing it to the signed value.

4.4 Trust Scoring

The trust scoring algorithm computes a 0-100 score for each agent based on five factors:

• Status (20%) — Active agents receive full marks. Suspended agents receive partial credit. Revoked agents score zero.
• Age (20%) — Agents that have been operational longer receive higher scores, reflecting stability and track record. The score curves logarithmically, with diminishing returns after 90 days.
• Success Rate (25%) — The ratio of successful actions to total actions. Agents with consistently successful operations score higher. A minimum of 10 events is required for this factor to activate.
• Denial Ratio (20%) — The inverse of the permission denial rate. Agents that frequently attempt unauthorized actions receive lower scores. This factor incentivizes agents to operate within their granted permissions.
• Scope Breadth (15%) — The number of distinct permission scopes granted, normalized against the total available scopes. Agents with broader permissions are assumed to have earned greater organizational trust.

Trust scores are publicly queryable via the Trust API, enabling third parties to verify an agent's trustworthiness before engaging in interactions. Embeddable SVG badges provide a visual indicator of trust level that can be displayed in dashboards, documentation, and agent marketplaces.

5. Credential Delegation

As AI agents move beyond read-only tasks into actions that require real-world authority — sending emails, transferring funds, modifying cloud infrastructure — they need access to human credentials. But giving an agent a raw OAuth token or API key creates an uncontrolled blast radius. Credential delegation solves this by providing a structured, auditable mechanism for humans to grant agents scoped, time-limited access to external services.

5.1 The Delegation Model

Credential delegation follows a three-party model: the delegator (human or parent agent), the delegatee (the agent receiving access), and the provider (the external service being accessed). The delegator connects their account to a registered OAuth provider, then creates a delegation grant that specifies which agent can access which provider, with what scopes, and for how long.

When an agent needs to access the external service, it requests a token through Vorim rather than holding credentials directly. Vorim verifies the delegation is active, the requested scopes are within the granted scope, and the agent's identity is valid — then issues a scoped token from the encrypted vault.

5.2 Encrypted Token Vault

All OAuth refresh tokens are encrypted at rest using AES-256-GCM with per-tenant encryption keys. Access tokens are never stored — they are generated on demand from refresh tokens and returned directly to the requesting agent. This minimizes the window of exposure: even a complete database compromise yields only encrypted refresh tokens, not usable access credentials.

// Credential delegation flow
const delegation = await vorim.delegateCredential({
  agentId: 'agid_abc123',
  connectionId: 'conn_xyz',
  scopes: ['gmail.send', 'calendar.read'],
  expiresAt: '2026-05-01T00:00:00Z',
  maxHops: 1,
});

// Agent requests a scoped token when needed
const token = await vorim.requestToken({
  delegationId: delegation.id,
  scopes: ['gmail.send'],
});

5.3 Multi-Hop Delegation Chains

In multi-agent systems, Agent A may need to delegate a subset of its authority to Agent B, which in turn delegates to Agent C. Vorim supports multi-hop delegation chains with two critical constraints:

• Scope attenuation — Each hop in the chain can only narrow the scope, never widen it. If Agent A is granted gmail.send + calendar.read, it can delegate calendar.read to Agent B, but cannot grant calendar.write.
• Cascading revocation — Revoking a delegation at any point in the chain automatically revokes all downstream delegations. If the human revokes Agent A's access, Agents B and C lose access immediately.

The maxHops parameter limits how deep a delegation chain can extend, giving delegators explicit control over how far their authority can propagate.

5.4 Credential Audit Events

Every credential operation — delegation created, token requested, delegation revoked, token refresh failed — is recorded as a credential audit event. These events are separate from the general audit trail and include the delegation chain path, requested scopes, and outcome. This provides a complete forensic record of how delegated authority was used across the agent fleet.

6. Ephemeral Identity

Not every agent needs a permanent identity. Serverless functions, one-off data processing pipelines, CI/CD automation agents, and short-lived workflow steps need to be identifiable and auditable during their execution window, but maintaining permanent key material for them creates unnecessary operational overhead and expands the attack surface.

6.1 W3C did:key Identifiers

Ephemeral agents receive a W3C did:key identifier derived from their Ed25519 public key using the multicodec prefix 0xed01 and base58-btc encoding. This produces a self-describing, globally unique identifier that can be resolved without contacting a registry — the public key is embedded directly in the DID.

// Register an ephemeral agent with a 1-hour TTL
const agent = await vorim.registerEphemeral({
  name: 'data-pipeline-run-42',
  ttlSeconds: 3600,
});

// agent.did = "did:key:z6Mkf5rGMoatrSj1f..."
// agent.expiresAt = "2026-04-12T14:00:00Z"
// Full Ed25519 keypair returned for the agent's lifetime

6.2 TTL-Based Lifecycle

Ephemeral agents are created with a ttlSeconds parameter that defines their maximum lifetime. A background cleanup job runs every 5 minutes to transition expired ephemeral agents to revoked status. Once revoked, the agent can no longer perform actions, but its audit trail is preserved for compliance and forensic purposes.

This design eliminates a common security gap in agent systems: forgotten or abandoned agents that retain active credentials indefinitely. With ephemeral identity, agents are secure by default — they expire automatically, and their window of authority is explicitly bounded at creation time.

6.3 Use Cases

• Serverless functions — A Lambda or Cloud Function that processes a batch of records can register as an ephemeral agent, receive permissions for the duration of the job, and automatically lose access when the TTL expires.
• CI/CD pipelines — Build agents that deploy code or run tests can operate under a scoped, time-limited identity rather than long-lived service account tokens.
• Multi-agent subtasks — A parent agent can spawn ephemeral child agents for specific subtasks, each with their own identity, permissions, and audit trail, without accumulating permanent key material.
• Sandboxed evaluation — Agents being evaluated or tested can operate under ephemeral identities that automatically expire, preventing test agents from persisting into production.

7. Open Standards

Vorim AI is committed to open standardization of agent identity. The protocol underpinning the platform — VAIP (Vorim Agent Identity Protocol) — is published as an open specification and is being submitted to multiple standards bodies for review and adoption.

7.1 IETF Internet-Draft

The core protocol is published as an IETF Internet-Draft: draft-nyantakyi-vaip-agent-identity-01. The draft defines the identity model, permission framework, audit trail format, trust scoring algorithm, credential delegation mechanism, and ephemeral identity lifecycle. It is designed for compatibility with existing IETF work in OAuth (RFC 6749), WIMSE (Workload Identity in Multi-System Environments), and RATS (Remote Attestation Procedures).

7.2 W3C Alignment

Ephemeral identity uses W3C DID Core (did:key method) for self-describing agent identifiers. Trust assertions are designed to be expressible as Verifiable Credentials, enabling interoperability with the W3C Verifiable Credentials ecosystem. The protocol has been submitted to the W3C Credentials Community Group for review.

7.3 Protocol Specification

The full protocol specification (VAIP v3.0.0) is published under the Business Source License 1.1 and available at github.com/Vorim-AI-Labs/vorim-protocol. The specification covers 11 sections including core identity, permissions, audit trails, trust scoring, credential delegation, and ephemeral identity extensions. Reference implementations are available in TypeScript and Python.

8. Compliance Mapping

The following table maps Vorim AI capabilities to specific requirements in major AI governance frameworks and compliance standards. This mapping is provided as a reference for compliance teams evaluating the platform's alignment with their regulatory obligations.

This mapping reflects the platform's technical capabilities as of April 2026. Regulatory interpretation may vary by jurisdiction and use case. Consult your legal team for definitive compliance guidance.

9. Integration

Vorim AI is designed for rapid integration into existing agent infrastructure. The platform provides official SDKs for TypeScript and Python, along with pre-built integrations for the most widely adopted agentic AI frameworks.

9.1 TypeScript SDK

The @vorim/sdk package provides a fully typed client for all platform capabilities: agent registration, permission management, audit event submission, trust verification, and API key management. The SDK handles authentication, error handling, retries, and type validation.

import { createVorimSDK } from '@vorim/sdk';

const vorim = createVorimSDK({ apiKey: 'agid_sk_...' });
const agent = await vorim.registerAgent({ name: 'my-agent' });

9.2 Python SDK

The vorim PyPI package provides both synchronous and asynchronous clients with full feature parity. The async client uses httpx for non-blocking operations in async agent frameworks.

from vorim import Vorim

client = Vorim(api_key="agid_sk_...")
agent = client.register_agent(name="my-agent")

9.3 Framework Integrations

Pre-built integrations wrap popular frameworks to automatically enforce permissions and record audit events on every tool call, with no changes to existing agent code:

• LangChain — Middleware that wraps tool execution with permission checks and audit logging. Compatible with LangChain agents, chains, and tool classes.
• OpenAI Assistants — Function call interceptor that verifies agent permissions before tool execution and logs results as audit events.
• CrewAI — Task-level integration that maps crew member identities to Vorim agents and enforces per-task permission boundaries.
• LlamaIndex — Query engine wrapper that logs data access patterns, enforces read/write permissions, and records retrieval audit trails.
• Claude (Anthropic) — Tool use interceptor that wraps Claude's tool calls with identity verification, permission enforcement, and automatic audit event emission.
• Pydantic AI — Type-safe dependency injection via VorimDeps. Permission checking and audit logging through vorim_tool decorator with full RunContext integration.
• Google A2A Protocol — Extends A2A Agent Cards with cryptographic identity, live trust scoring, and permission verification for agent-to-agent interactions.
• Stripe Agentic Commerce (ACP) — Agent identity verification before payments. Ensures only agents with the transact permission scope can initiate checkouts. Full audit trail on every transaction.

9.4 Public Trust API

The Public Trust API enables third parties to verify an agent's identity and trust score without authentication. Two endpoints are available:

• GET /v1/trust/verify/:agentId — Returns the agent's trust score, status, public key fingerprint, and score breakdown. Rate-limited to prevent abuse.
• GET /v1/trust/badge/:agentId.svg — Returns an embeddable SVG badge displaying the agent's trust score. Suitable for dashboards, documentation, and agent directories.

These endpoints enable a decentralized trust ecosystem where any party — agent marketplaces, partner organizations, end users — can independently verify an agent's trustworthiness before granting access or engaging in interactions.

10. Conformance Levels

Vorim AI defines five conformance levels that represent increasing degrees of identity verification, permission enforcement, and audit rigour. Organizations can adopt the platform incrementally, starting with basic identity and progressing to full cryptographic audit as their agent infrastructure matures.

Organizations targeting regulatory compliance should aim for Level 3 or higher. Levels 6 and 7 extend the platform with credential delegation and ephemeral identity for advanced multi-agent deployments. The full stack (Levels 1–7) is recommended for high-risk AI systems, financial services, healthcare, and any deployment subject to the EU AI Act's high-risk requirements.

11. Conclusion

Agent identity is infrastructure, not a feature. Just as TLS became the non-negotiable foundation of web security, cryptographic agent identity will become the non-negotiable foundation of agentic AI. Organizations that treat identity as an afterthought will face compounding costs in security incidents, compliance failures, and trust erosion.

The window for building identity into your agent architecture is now. Retrofitting identity onto a production agent fleet is orders of magnitude more difficult than designing it in from day one. Every agent deployed without verifiable identity, scoped permissions, and audit trails is technical debt that will come due — and the interest rate is set by regulators.

Vorim AI provides the complete identity and trust layer for autonomous AI agents. From cryptographic keypairs to signed audit bundles, from credential delegation with cascading revocation to ephemeral identities that expire automatically, every component is designed for production security, regulatory compliance, and operational confidence.

The protocol is open. The IETF Internet-Draft (draft-nyantakyi-vaip-agent-identity-01) is published and under review. The specification is submitted to W3C, OpenID Foundation, OWASP, Cloud Security Alliance, and OpenSSF. We believe agent identity should be a shared standard, not a proprietary feature.

The agents are already here. The question is whether you can identify, control, and audit them.