AOM™

March 15, 2026

Know Your Agent (KYA): Why AOM Agents Need an Identity

KYA is the agent-side counterpart to KYC: who owns the agent, what it may touch, and how access is revoked. How AOM Agent Kits add registration, keys, and validation.

Read the spec (.org)Explore tools (aom.tools)

Most frameworks make it easy to spin up an AI agent. Few make it easy to answer: who is this agent, what is it allowed to do, and how do we revoke or rotate that access? “Know Your Agent” (KYA) is that discipline — the agent-side counterpart to KYC for people.

AOM Agent Kits on aom.tools add a lightweight registration path so each agent can have a stable identity, an accountable owner, and a declared purpose from day one.

What “Know Your Agent” means

For humans, KYC is about verifying identity before trust. For agents, KYA boils down to:

  • Who owns this agent (person or organization).
  • Which surfaces and data it is allowed to touch.
  • How to revoke or rotate access when people leave, scopes change, or something looks wrong.

If you cannot answer those questions, you are running anonymous scripts with production power. KYA turns them into named, attributable agents.

From anonymous scripts to registered agents

By default, many agents look like nameless jobs in your infra. Registration adds one missing piece: a short form that yields a key, an owner, and a purpose.

On Register Agent we collect:

  • Owner name and email — a real contact behind the agent.
  • Agent name — a stable ID for logs, dashboards, and alerts.
  • Purpose and organization — what the agent is for and whom it represents.

Registration is free; you can still download and run kits without it. Registration is what upgrades a script into something you can track, audit, and govern.

How the agent key works

After registration, aom.tools issues a key you place in aom.kya.agent.json inside the kit.

On startup, the kit validates that key with the backend. If it is missing, invalid, or expired, the agent exits early with a clear error in AOM output — so your runtime can prompt for re-registration instead of failing mysteriously mid-flight.

That gives you:

  • Every run tied to a registered identity.
  • Fail-closed behavior when credentials are stale.
  • Analytics and logging keyed by agent ID and owner, not hostnames and guesswork.

(The public registration experience may also reflect how many agents have joined the ecosystem — useful as a rough adoption signal, not a SLA metric.)

Surfaces, agents, and policy

AOM already describes surfaces in JSON, including automation posture (forbidden, constrained paths, or open). Pair that with known agents and you can reason about rules such as:

  • “This agent may only operate where automation_policy is open.”
  • “This org’s agents are limited to these surface IDs or domains.”

So:

  • Surfaces say where automation is allowed.
  • Agents say who they are and what they are for.
  • Your governance layer can match the two instead of letting arbitrary scripts roam.

The vocabulary for policies and surfaces is normative on agentobjectmodel.org; kits and validation live on aom.tools.

Getting started

  1. Download AOM Agent Kits (agent owners).
  2. Register an agent and capture the key.
  3. Wire the key into startup and log agent ID on every material action.

You do not need a full platform rewrite — you need consistent naming, ownership, and validate-before-run behavior.

Over time, KYA can grow into richer org controls, purpose metadata, and analytics. The registration and validation flow on aom.tools is the starting point.