An open internet protocol

Operator accountability for autonomous agents

Every AI agent that transacts needs an accountable operator behind it. Groundmark anchors that accountability in DNS — the infrastructure already governing every corner of the internet — and makes it verifiable, cold, by any relying party, with no central registry.

Agent signs request
DNS resolves operator key
IDSP attests operator facts
Relying party verifies cold
No central registry
DNSSEC throughout
Composable — not a replacement
Two IETF Internet-Drafts filed
The problem

Agent commerce has no identity layer

Protocols like x402 have solved payment mechanics for autonomous agents. But those transactions carry no identity. There is no standard way for an agent to prove who operates it, what it is authorised to do, or whether its operator is accountable.

01

No accountable principal

No verifiable link between an autonomous agent and the organisation that deployed it. A relying party has no way to know who to hold responsible if something goes wrong.

02

No delegation record

No standard mechanism for an operator to express what its agent is authorised to do, and no way for a third party to verify that authorisation cold.

03

No contextual attestation

Different transactions require different facts. Whether an operator is present in a jurisdiction, holds a licence, or passes a KYC check — none of this is currently portable across relying parties.

04

No trust without a prior relationship

Every current approach requires the agent and relying party to have met before, or to rely on a walled garden that vouches for both. Cold verification — between strangers — does not exist.

How it works

One fixed loop. The variables are on top.

Walk through a real Groundmark verification. The binding layer, the attesting party, and the question are all independent — change any of them and the protocol is identical underneath.

BEAT 2 · FIXED
Groundmark · DNSid · ANS · DNS-AID
SLOT · BEAT 3
SLOT · BEAT 4
DNS binds agent to operator Domain registry the IDSP · vouches Agent acts for the operator Relying Party has never met it ? REG
Press Play
Or step through the four beats. Change the IDSP or question at any time — the loop above does not move.
  ✓ Yes
Merits (the receipt, on demand)
Graduated trust

One schema. The depth lives in method_disclosure.

The IDSP's primary obligation is to disclose what it verified — not just to assert a conclusion. A thin check and a regulatory-grade check are the same attestation with different method strings. The relying party reads the method and decides.

Level 0
Provenance
Cryptographic proof that a request was signed by the agent named in DNS. No attestation required. Standalone and useful on its own.
v=gm1; pk=ed25519:z…
Level 1
Accountability
Operator existence and domain control, verified by an IDSP. Method disclosed. The substrate every higher claim composes on.
methods: ["domain-verified",
"terms-accepted"]
Level 2
Identity
Specific operator facts — jurisdictional presence, business registration, KYC. The method string carries how it was checked.
methods: ["gov-id:passport",
"registry-record"]
Level 3
Regulatory
Professional licence, biometric liveness, regulated KYC/AML. Subject to audit. The IDSP is accountable to the relying party.
methods: ["regulator-record",
"liveness:video-with-staff"]
Protocol landscape

Composable — not a replacement

Identity, discovery, authorisation, and payment for autonomous agents are being worked on by several groups in parallel. Each addresses a distinct part of an agent transaction. Groundmark is the attestation layer — designed to sit alongside the rest of the stack.

Payment
x402HTTP-native micropayments
ACS / StripeShared payment tokens
OpenOther payment rails
Authorisation
AAuth / OAuth 2Per-instance runtime authorisation
Delegation chainsAgent-to-agent scope
Attestation
GroundmarkThird-party attestation about operator facts. IDSP discloses method. Relying party decides. No central registry.
Identification
Groundmark L0DNS key + request sig
DNSidDNS agent identity
ANSAgent name service
DNS-AIDDNS agent ID
Discovery
Google Agent RegistryService-level discovery
agent.json / ADPCapability advertisement
NAISAgent naming
Infrastructure
DNS / DNSSEC
RDAP
RFC 9421HTTP Msg Sigs
DID / VCs
ICANN policy
Groundmark occupies a structurally distinct layer. Every adjacent protocol operates at service discovery, identification, or runtime authorisation. None provide third-party attestation about operator facts from a party with method-disclosure obligations. This is not a naming difference — it is a structural gap.
Architecture

Every component already exists

Groundmark recombines DNS registration, DNSSEC, RDAP, HTTP Message Signatures, and registrar verification into an attestation layer. The contribution is recognising that these, combined, solve the agent identity problem that agentic commerce requires.

Agent identity

_agentid TXT record

The operator publishes the agent's Ed25519 public key in DNS under a reserved underscore label. Small, stable, aggressively cacheable. The cryptographic root of everything above it.

Attestation pointer

_agentclaim TXT record

A pointer to an externally hosted attestation. The agent carries the pointer, not the proof. The relying party lifts the attestation directly from the IDSP — the agent cannot write it and cannot forge it.

Request authentication

RFC 9421 HTTP Message Signatures

Agents sign HTTP requests using a key identifier that resolves through DNS. Standard, no bespoke header format. DNSSEC validates the key chain end to end.

IDSP obligations

Method disclosure, not conclusions

An IDSP attests to what it did and how it verified it. The method_disclosure field carries this in every attestation. The relying party — not the IDSP — makes the trust decision. Pluralism of IDSPs is deliberate.

Operator publicity

RDAP — the inverted incentive

For human domain holders, the trajectory has been toward less WHOIS information. Agents invert that incentive: an operator's value as a counterparty is proportional to the verifiable information it exposes.

Trust chain

DNSSEC throughout

Required for all Groundmark DNS lookups. The chain of trust is cryptographically validated end to end from the requesting agent's domain to the IDSP's signing key. An unsigned zone is a fatal verification failure.

Live verification

Try the console

Run a real verification

The verification console runs the full Groundmark loop against live DNS. Select a scenario and a fixture — correct acceptances, correct rejections, and edge cases — and watch each step resolve.

  • Registry, platform, and regulatory IDSP scenarios
  • Nine-step verification sequence, animated in real time
  • Correct rejections shown explicitly: expired, wrong subject, bad signature, unsigned zone
  • The graduated trust ladder — thin vs elevated methods, same schema
Open the console

Login: guest  ·  Password: groundmark2026

Verification result
step 1 parse signature
step 2 DNSSEC validate
step 3 resolve _agentid
step 4 verify sig
step 5 resolve _agentclaim
step 6 DNSSEC IDSP key
step 7 fetch attestation
step 8 verify attestation
step 9 apply floor
verdict ✓ Accept
method_disclosure:
registry-record,
address-verified
Specification

Two Internet-Drafts. One modular protocol.

Groundmark is being built as a proper internet standard through the IETF process. The core is fully self-standing at Level 0 — no normative dependency on the attestation draft — and the two compose when both are present.

Core

DNS-Anchored Identity Discovery for Autonomous Agents

Defines _agentid and _agentclaim record formats, RFC 9421 request authentication, DNSSEC requirements, and Level 0 provenance. Self-standing. No dependency on the attestation draft.

draft-noss-jeftovic-groundmark-core-00 →
Attestation

Operator Attestation Framework for Autonomous Agents

Defines the IDSP role and obligations, the four-level trust taxonomy, method_disclosure semantics, the claim vocabulary, revocation, and the governance framework for IDSPs.

draft-noss-jeftovic-groundmark-attestation-00 →
Contact

Building in this space?

If you are building agent infrastructure, operating a domain registry, running a relying party that needs operator accountability, or working on identity and attestation — reach out directly.

For protocol questions, the Internet-Drafts are the authoritative source. For everything else, email is the right channel.