Varwof.

Agent Identity & Authorization, Built on PKI

AIC binds every AI agent to the principal who authorizes it — identity, delegation, and capabilities in one cryptographically verifiable certificate. Open standard. Open source. Enterprise-ready.

draft-wei-aic-identity-cert-01 · draft-wei-aic-jwt-00 IANA PEN 66257 IPR 7553 · Royalty-Free Open Source

Who answers for what your agent does?

Autonomous agents act, sign, and transact on behalf of people and organizations. Today's IAM answers "who is the client" — not "who authorized this action, why, and under what limits." That missing layer is what AIC provides.

01

Identity

A standard X.509 certificate or JWT anchors the agent's cryptographic identity in a verifiable chain.

02

Accountability

principalUid binds the agent to the authorizing person via a key hash, so actions trace back to a human.

03

Authority

A principal-signed DelegationAuthorization records why, what capabilities, and under what constraints.

04

Enforcement

Gateways evaluate the effective authorization — principal grant ∩ agent capabilities ∩ runtime policy — at every request.

Why PKI Is the Answer

Agent identity is a certificate problem. AIC builds on the trust infrastructure you already run.

Already Universal

X.509 ships in every OS, TLS stack, and enterprise PKI — there is no new trust infrastructure to build.

Offline-Verifiable

Signatures and chains verify without network round-trips — authorization evidence travels with the agent.

Mature Lifecycle

Validity, renewal, revocation, and status are long-solved problems governed by standards and audits.

Bound to Transport

TLS/mTLS already carries certificates; AIC rides the handshake your infrastructure performs every day.

One Standard, Two Profiles, a Full Platform

AIC ships as an X.509 v3 extension for PKI-native deployments and as a JWT profile for the web — both backed by the same delegation model and a fully open-source reference stack.

AIC X.509

Certificate extension with agent identity, principal binding, capability container, delegation evidence, and offline-verifiable constraints. Ideal for regulated, PKI-native environments.

Financial · Government · Healthcare

AIC-JWT

JSON Web Token profile with double signing (principal + issuer), RFC 7638 thumbprint binding, and a browser WebCrypto pipeline. Works everywhere JWTs do.

Web · SaaS · Browser

Capability Registry

Open, machine-readable capability schemes with PKCS#7-signed rule files — a global vocabulary so different organizations can interoperate.

Open Ecosystem

Zero-Trust Gateway

TCP/HTTP/UDP unified gateway that enforces AIC verification, revocation, capability plugins, and per-route policy in pure Go.

TCP · HTTP · UDP

High-Speed PKI Engine

In-memory certificate status engine with async persistence — measured at 16,000+ certificates/second for regular issuance and 8,000+ AIC certificates/second on a single x86 machine.

16k+ cert/s regular · 8k+ AIC/s

Cross-Language SDKs

Reference implementation in Go plus ports to TypeScript, C/OpenSSL, Java, and .NET — verify AIC anywhere in your stack.

Go · TS · C · Java · .NET

Why AIC Is Different

Identity tells you who is calling. AIC tells you what that identity is allowed to do — and who is accountable when it acts.

Two Authorities, Separated

The CA certifies identity; only the principal's signature creates authority. Even a compromised CA cannot mint new principal grants.

Evidence, Not Just Claims

Capabilities, constraints, and delegation are signed into the artifact and verifiable offline; enforcement stays at the gateway.

One Model, Two Carriers

X.509 rides your existing PKI and TLS; JWT serves web and OAuth — the same authorization semantics in your current stack.

Open, Measured, Standards-Backed

IETF drafts under Royalty-Free IPR, 13/13 independent conformance, and public benchmarks on documented hardware.

Follow One Agent Action

01

Principal Signs

A DelegationAuthorization pins the agent, capabilities, constraints, and lifetime.

02

Issuer Binds

The authority evidence becomes an AIC extension in X.509, or an AIC-JWT.

03

Agent Presents

TLS/mTLS delivers the credential to the gateway.

04

Gateway Decides

P_principal ∩ C_agent ∩ P_gateway, then runtime constraints.

05

Audit Records

Every decision is preserved and attributable to the principal.

Scope stays explicit: AIC provides offline-verifiable authorization evidence, not zero external status input; it does not claim legal accountability, and the current interoperable profile limits delegation to one hop.

It Lands on the Gateway

The certificate carries the evidence. The gateway — your gateway — is where authorization becomes an execution decision.

01

Authenticate

TLS/mTLS establishes who is calling.

02

Validate

Issuer, chain, validity, and revocation status.

03

Verify Delegation

Principal-signed DelegationAuthorization and binding.

04

Intersect

P_principal ∩ C_agent ∩ P_gateway.

05

Constrain

Time, network, concurrency, and runtime policy.

06

Audit

Immutable record: identity, principal, capability, decision.

TCPHTTPUDP mTLSAIC-JWT
AIC never requires changing TLS or replacing your gateway — it makes the enforcement point explicit and auditable.

Open Standards, Real Interoperability

Two IETF Experimental drafts, a Royalty-Free IPR commitment, and an independent implementation already reproducing 13/13 conformance cases.

2
IETF Drafts
13/13
Independent Interop Cases
6
Implementation Languages
15+
Public Repositories

The Enforcement Trio

Three Go repositories carry one credential end to end: the agent mints and presents it, the verifier decides on it, and the executor gates what actually runs.

aic-agent

Consumer side. Obtains a fresh, short-lived AIC end to end (human approval → CA mint), carries it over mTLS or as a Bearer AIC-JWT, pre-checks capabilities locally, and drives MCP servers with the issued identity.

GitHub → Docs →

aic-verifier

Service side. Per-request pipeline: certificate validity → CRL/OCSP → role → AIC decision → capability ∩ principal grant → parameter bounds → allow / allow_unresolved / deny. mTLS and Bearer transports, middleware and reverse-proxy integrations, every decision preserved as DSSE-signed evidence.

GitHub → Docs →

aic-exec

Execution side. One decision core: admission, argv→CLC projection, CLC decision, shell-free execution, and per-call evidence. CLI and MCP entry points, local or remote authority, chained serve.

GitHub → Docs →

SDKs That Just Work

Five languages, one model, zero lock-in — verify AIC anywhere in your stack.

Go

Core, engine, gateway, and types — the reference implementation.

GitHub →

TypeScript

Browser / WebCrypto pipeline for the AIC-JWT profile.

GitHub →

C / OpenSSL

AIC extension support patched into OpenSSL 3.5.

GitHub →

Java

JVM verification library for AIC artifacts.

GitHub →

.NET

.NET verification library for AIC artifacts.

GitHub →

Standards Participation Welcome

AIC is an individual IETF submission. Implementers, reviewers, and interop partners are invited to test the public stack and join the conversation.