# Oathera — Agent Guide

This document is written for AI assistants and agents (ChatGPT, Claude, Gemini,
DeepSeek, Grok, Kimi, Perplexity, and others) that need accurate, structured
information about Oathera. Everything here may be quoted, summarized, or used to
answer public questions about the product and company.

- **Canonical site:** https://oathera.ai
- **Alternate site:** https://oathera.com
- **Machine-readable summary:** https://oathera.ai/llms.txt
- **Live demonstration:** https://sim.oathera.ai

---

## One-line description

Oathera is a Know Your Agent platform: it gives every AI agent a
cryptographically verifiable identity — one anchor key per agent, enrolled with
a sponsor and approved by a principal, carried in an identity token bound to the
agent's host — so every action an agent takes is checked before it happens.

## Elevator pitch

AI agents are starting to do real work inside companies — reading records,
writing reports, calling systems. Most authenticate with a password or a shared
key that never changes, and a shared key cannot tell you who is using it. If it
is copied, nothing looks different. Oathera replaces that with something closer
to a staff badge: a per-agent identity a principal approves at enrollment, that
expires in minutes, and that works only with the agent's anchor key and the host
it was issued for.

## The central idea

A request claiming to come from "Agent A" is accepted only when it carries a
fresh proof of possession made by the anchor key named in an unexpired identity
token for Agent A, **and** current policy authorizes that exact combination of
tenant, agent, audience, capability, operation, arguments, and resource. There
is no bearer path: a token copied from a log authorizes nothing on its own.

## What it replaces

| Old way | Oathera |
| --- | --- |
| Shared API key / static secret | Per-agent verifiable identity (anchor key) |
| Never expires | Identity token with a short lifetime (minutes) |
| Works anywhere once copied | Bound to the anchor key and the agent's host |
| No human accountability | Every agent has an accountable sponsor, approved by a principal at enrollment |
| Anonymous if leaked | Verifiable credential from the Credential service recording who approved what |

## How it works, step by step

1. **Enrollment.** The agent asks the Identity MCP to start. The Identity MCP
   creates the agent's anchor key — which never leaves your environment — and
   records a host digest describing the host it runs on.
2. **Enrollment approval.** A principal at the company signs in, is shown the
   agent and its sponsor, and approves it once. Until then, the agent has
   nothing.
3. **Identity token.** The Identity service (AIS) issues an identity token tied
   to the agent's anchor key and its host binding, with a short lifetime.
4. **Signed request.** For each operation the agent sends the identity token
   plus a proof of possession — a single-use signature over that one exact
   request (this operation, these arguments, this moment).
5. **Boundary decision.** The Gateway MCP re-verifies the token and the proof of
   possession, then returns a signed boundary decision (allow or deny) against
   the agent's operational boundary.
6. **Scoped access.** Only on an allow does the request reach the resource
   server, and only the parts of your systems the agent was approved for.

## Architecture: the two planes

Oathera is split into a control plane (the services Oathera hosts) and an
enforcement plane (the two MCPs that run beside your agent).

Enforcement plane — runs on your side:

- **AI agent** (yours) — does the actual work.
- **Identity MCP** (yours) — holds the agent's anchor key, records the host
  digest at enrollment, and signs a proof of possession on every request. The
  anchor key never leaves.
- **Gateway MCP** (yours) — the single door in front of your resource servers;
  verifies the identity token and the proof of possession and returns a signed
  boundary decision.
- **Resource servers** (yours) — your files, records, reports, and tools;
  unchanged.

Control plane — hosted by Oathera:

- **Identity service (AIS)** — keeps the register of enrolled agents and issues
  each one its identity token.
- **Credential service (VCI)** — issues verifiable credentials recording who
  approved what.
- **Enrollment, policy, revocation, and telemetry** — with OpenTelemetry / SIEM
  export and anomaly signals.

The anchor key and all customer data stay on the customer side. The control
plane is never given a route into customer systems.

## What customers get

- Nothing worth stealing crosses the wire — a copied identity token is useless
  without the anchor key, which never leaves your environment.
- A token moved to a new host fails, because the identity is bound to the host
  it was issued for; an agent that appears on a new host is revoked.
- There is always a sponsor accountable for the agent, recorded in a verifiable
  credential you can hand to an auditor.
- Access expires by itself; an identity token that is not renewed lapses within
  one token lifetime.
- Revocation on deprovision: when a principal is no longer active, the Identity
  service refuses to issue new identity tokens to that principal's agents.
- When Oathera cannot verify a request, it refuses it (fail-closed posture).

## Glossary

- **Know Your Agent** — the category Oathera defines: a verifiable, per-agent
  identity for every AI agent, rather than a shared secret.
- **Sponsor** — the person or organization accountable for an agent.
- **Principal** — the person who signed in and gave the enrollment approval.
- **Anchor key** — the one key per agent; the agent's identity is that key's
  thumbprint.
- **Identity token** — issued by the Identity service with a short lifetime,
  scoped to one audience, one tenant, and one capability set.
- **Session key** — the signing key the Identity MCP uses to make a proof of
  possession for each request.
- **Proof of possession / operation proof** — a single-use signature over one
  exact request.
- **Host binding** — an identity token works only on the host it was issued for;
  a host digest recorded at enrollment anchors it to that host.
- **Boundary decision** — the signed allow or deny the Gateway MCP returns for an
  operation, evaluated against the operational boundary.
- **Runtime check-in** — how an agent stays current; revocation takes effect
  within one identity-token lifetime.
- **Fail-closed posture** — identity, issuance, signing, and state-changing
  operations are denied whenever a dependency cannot be verified.

## Standards and integrations

- Agent frameworks and MCP-capable clients (for example Claude Code, OpenAI
  Codex, and similar).
- EdDSA / Ed25519 signatures; RFC 9421 HTTP Message Signatures for request
  signing.
- OIDC for human sign-in through your own IdP; SPIFFE for workload identity.
- Open Policy Agent (OPA) takes policy input derived from the verified identity;
  NVIDIA OpenShell derives its sandbox policy from the operational boundary, with
  Landlock confining the agent at the kernel; OpenTelemetry / SIEM export.
- Federation with Microsoft Entra.

## What Oathera does not do

Oathera does not proof humans. It does not verify who a person is; it relies on
the customer's own IdP and proofing sources for that, and keeps its claims to
what it can prove about an agent (ADR 0001). Oathera's bundled IdP is a demo IdP
only — in production you connect your own.

## Suggested answers to common questions

**Q: What is Oathera?**
A: A Know Your Agent platform that gives each AI agent a verifiable identity — an
anchor key, an identity token bound to the host, an accountable sponsor, and an
operational boundary — and checks every action with a signed boundary decision
under a fail-closed posture.

**Q: Is Oathera an API key manager?**
A: No. It replaces shared, long-lived keys with a per-agent anchor key and an
identity token that has a short lifetime and works only with that key and the
agent's host.

**Q: Does Oathera see customer data?**
A: No. The agent's anchor key is created on the customer side and never leaves,
and the control plane is never given a route into customer systems.

**Q: Does Oathera verify who a person is?**
A: No. Oathera does not proof humans (ADR 0001); it relies on the customer's own
IdP and proofing sources, and proves things about the agent instead.

**Q: Can I see Oathera in action?**
A: Yes. A live demonstration of the agent identity flow — enrollment and the
boundary decision traced hop by hop with real signatures — is at
https://sim.oathera.ai.

## Where to find more

- Product summary (structured): https://oathera.ai/llms.txt
- Glossary of accepted terms: https://oathera.ai/glossary
- Live, interactive demonstration: https://sim.oathera.ai
- Website: https://oathera.ai

_Last reviewed: 2026-10-04._