| Parties |
| Principal | The person or organisation whose authority an agent exercises (X in the scenario). | owner, user, deployer |
| Agent | Software that acts on a principal's behalf with some autonomy (A, B). | AI agent, bot |
| Agent instance | One running copy of an agent. Many instances can share one agent identity. | session, worker, sub-agent |
| Operator | Whoever runs the infrastructure an agent executes on. May differ from the principal. | provider, host, platform |
| Issuer, subject, holder | Who signs a claim, whom the claim is about, and who presents it. | |
| Relying party | Whoever decides whether to act on a claim (B when A calls). | verifier, counterparty |
| Tool, skill | A capability an agent can invoke (T). MCP servers and skill packages are common forms. | plugin, connector, extension |
| Claims and artefacts |
| Artefact | Any signed or hashed object a trust decision relies on: identity document, credential, mandate, verdict, receipt. | artifact, record |
| Verifiable Credential (VC) | A W3C format for a signed claim about a subject. | credential, attestation |
| Mandate | The scope of action a principal grants an agent: what, how much, until when. | authorisation, grant, capability |
| Delegation | Passing part of a mandate to another agent or tool. | sub-delegation, token exchange |
| Declaration | A statement a subject signs about itself, such as affiliations or activities it does not engage in. | self-attestation, disclosure |
| Verdict | A signed finding about something, for example that a tool was reviewed. | attestation, assessment |
| Receipt | A signed record that an action happened. | action record, evidence |
| Self-asserted, third-party attested | Whether a claim is signed by its own subject or by someone independent of it. | self-issued, externally verified |
| Proposition | What an artefact is capable of proving. A valid identity document proves key control and says nothing about permission. | |
| Identity and resolution |
| DID, DID document, DID method | A W3C Decentralized Identifier (did:method:…) points to a document holding public keys. The method defines how to find that document. | agent ID |
| Self-certifying identifier | An identifier with the public key embedded in it, so no lookup is needed. It cannot be revoked; exposure ends with its lifetime. | did:key, aip:key |
| Resolution | Obtaining the document or artefact needed to verify a claim. | lookup, fetch |
| Resolution topology | Where trust material comes from: ledger, operator domain, third-party registry, or nowhere (self-certifying). | resolution path, substrate |
| Resolution coupling | Whether resolution happens during every verification (coupled) or ahead of time from conveyed and cached material (decoupled). | online / offline verification |
| Anchoring | Recording a hash on a ledger or timestamp service to prove it existed at a time. Separate from resolution. | notarisation, timestamping |
| Observation by the resolver | What a resolution source learns from lookups: which agent was checked, by whom, when. | lookup privacy |
| Integrity and time |
| Content-addressed | Named by the hash of its bytes. Anyone can recompute the hash to confirm they hold the right object. | hash-pinned |
| Location-bound | Trusted because of where it was fetched from. Whoever controls the location controls the content. | URL-based |
| Integrity resolution | Establishing that an object is the right one. | |
| Availability resolution | Establishing that an object can be obtained and is current. | |
| Staleness bound | The longest interval during which a revoked item can still pass verification. | freshness, TTL, cache lifetime |
| Revocation | Withdrawal of a credential, key or claim. Distinct from "failed to fetch" and "never issued". | suspension |
| Drift | An approved artefact changing after approval while keeping its name. | rug pull, post-approval mutation |
| Trust anchors and DNS (added 10 October 2026 from the Root KSK note) |
| Trust anchor | A public key, or its fingerprint, that a verifier already trusts and starts a chain of validation from. The DNS root has no parent to vouch for it, so validating resolvers hold its key as a trust anchor. Not to be confused with anchoring, which records a hash on a ledger or timestamp service. | root of trust, starting point |
| DNSSEC chain of trust | The path a resolver follows from its trust anchor down to a name: each parent zone publishes a fingerprint (DS record) of its child's key, so the root vouches for .com and .com for example.com. | delegation chain |
| Root key-signing key (KSK) | The key that signs the DNS root's list of public keys (its DNSKEY set). KSK-2024 (key tag 38696) is scheduled to replace KSK-2017 (key tag 20326) on 11 October 2026. The zone-signing key (ZSK) signs the root's other records. | root key, KSK-2024 |
| Validating resolver | A DNS resolver that checks DNSSEC signatures for its users, run by ISPs, enterprises and public DNS services. A validating resolver that does not trust the current root key may leave its users unable to reach names under any top-level domain. | recursive resolver |
| Key rollover | Replacing a key in stages: the new key is published alongside the old, signing switches to it, and the old key is later revoked and removed. Stopping a key from signing and withdrawing trust in it are separate steps. | KSK rollover, key change |
| Algorithm rollover | A rollover that also changes the signing algorithm. Verifiers need both a new trust anchor and software that can check the new signatures. ICANN has proposed moving the root from RSA to ECDSA, and a post-quantum root key would need another. | algorithm change |
| Automated trust-anchor update (RFC 5011) | A resolver learns a new trust anchor by seeing it published, signed by the key it already trusts, for at least 30 days before accepting it. Learned anchors can be lost when software is upgraded or moved between machines. | RFC 5011 hold-down |
| Trust anchor sentinel (RFC 8509) | A way to ask a supporting resolver whether it trusts a given root key, using specially named DNS queries (is-ta- and not-ta- followed by the key tag). A result is inconclusive where the resolver lacks sentinel support. | readiness test |
| Validation state | The outcome of DNSSEC validation for a response: secure, insecure, bogus or indeterminate. Under draft-ranjbar-dane-did-01, anything other than secure counts as a verification failure, never as absence, so a stripped response cannot demote a binding. | secure, bogus |
| DANE-EE key binding | A TLSA record with certificate usage DANE-EE(3), selector SPKI(1) and matching type SHA2-256(1), published under a DNSSEC-signed name so a key can be confirmed from the DNS root with no certificate authority in the path. Proposed as a shared profile for DNS-anchored DID methods. | TLSA 3 1 1, DANE-anchored identity |
| Continuity of holding | Whether the party controlling a name now is the party that controlled it when a binding was recorded. A key binding certifies only the current holder: after a lapse and drop-catch, a dispute transfer or a sale, the new holder's key verifies just as well. Distinct from key continuity, which only asks whether a key has changed. | change of holder, domain transfer |
| Currency and historical validity | Currency asks whether a binding is still the one published now; it decays and must be re-checked before reliance. Historical validity asks whether it was valid at a fixed earlier time; it does not decay. Evidence for one is never accepted as evidence for the other. | freshness, point-in-time validity |
| Stapled historical proof | The DNSSEC chain current when an artefact was produced (TLSA record with its RRSIG, DNSKEY and DS records up to the archived root trust anchor), carried with the artefact so a later verifier can check which key the name published at that time. Answers historical validity only. | stapled DNSSEC chain |
| Anchor succession | Proposed for KRT. The handover of trust from one anchor to its successor, with an overlap window, a cutover and a revocation, recorded so an agent's trust state can be stated at any moment. | |
| Trust state query | Proposed for KRT. A query, on the model of RFC 8509 sentinels, by which a person or agent learns which trust anchors, vocabularies or authorities a verifier or agent currently accepts. | |
| Comparison |
| Canonical form | A fixed serialization so equal data gives identical bytes. RFC 8785 (JCS) does this for JSON. | canonicalization |
| Referential equivalence | Grounds for concluding that two artefacts from different producers concern the same subject or action. | comparison semantics |
| Declared semantics | The namespace, units or schema that fix what a field means. | schema reference |
| Fails closed, fails open | A check that fails closed raises a false alarm: someone looks and finds nothing wrong. A check that fails open raises nothing while letting a wrong result through. Only a test input built to defeat the check reveals a fail-open fault. | false conflict, false match, silent collision |
| Authority |
| Authority continuity | Whether a mandate stays valid, in scope and unrevoked at every hop of a delegation chain. | chain of authority |
| Attenuation | Each delegation may narrow a mandate and never widen it. | scope narrowing |
| Binding point | What an attestation covers: the declared call, the request as sent, or the observed effect. | execution binding |
| Resolved target | The final address or path a request reaches after the agent's inputs are filled in and cleaned up. | executed destination |
| Consistency check, evidence check | A consistency check compares one claim with another and catches contradictions. An evidence check compares a claim with something worked out or fetched independently and catches false claims. | consistency row, evidence row |
| Carried and referenced evidence | Evidence included in a record, as opposed to a link to evidence held elsewhere. A link can stop working, and checks that depend on it quietly become unchecked. | embedded, linked |
| Behaviour and oversight |
| Declared policy | A behaviour an agent or its operator claims the agent follows, such as "no destructive actions during a freeze". | guardrail, rule |
| Enforcement point | The component that makes a declared policy hold: the agent itself, the platform, or something outside both. | policy enforcement point |
| Containment | Limits on what an agent can reach, such as a sandbox without network access. | isolation, sandboxing |
| Monitoring coverage | The share of an agent's actions that someone other than the agent records. | observability, telemetry |
| Attribution | Establishing which principal, agent and instance performed an action. | accountability, provenance |
| Accountability record | Who answers for an action, legally or organisationally. | liability |
| Open-world, closed-world reading | Closed-world treats anything unstated as false; open-world treats it as unknown. A credential read closed-world implies its subject does nothing beyond what it declares. | |
| Three-valued evaluation | A check returns yes, no or unknown, and policy states what happens on unknown. | |
| Attack patterns in the incident reports |
| Prompt injection | Instructions hidden in content an agent reads (a form field, a web page, a tool description) that the agent then follows. | indirect prompt injection |
| Tool poisoning | Hostile instructions placed in a tool's description or schema. | tool shadowing |
| Impersonation | Publishing something under a name that suggests a different publisher. | typosquatting, name-squatting |
| Supply chain compromise | Hostile code arriving through a dependency, package or marketplace. | |
| Exfiltration | Sending data out to an attacker-controlled destination. | data leak |
| Sandbox escape | An agent reaching resources its containment was meant to deny. | breakout |
| Systems and formats |
| p99 latency, tail amplification | The slowest one per cent of lookups. When every hop repeats verification, slow lookups become more frequent across the whole chain. | tail at scale |
| Network partition, PACELC | A partition leaves parts of a network unreachable. PACELC names the trade-offs: under partition, availability against consistency; otherwise, latency against consistency. | CAP |
| Ed25519, JWS, JWKS | A signature algorithm, a JSON signature format, and a published key set. | |
| RFC 3161 timestamp, transparency log | Ways to prove a hash existed at a time without a blockchain. | |
| Merkle root | One fingerprint summarising a whole list of records, used by transparency logs. Designs that copy the last record when the count is odd let lists of different lengths share a root unless the count is also recorded. | tree head, log root |
| Base, layer two, ERC-8004 | Base is an Ethereum layer-two chain. ERC-8004 is the Ethereum proposal for on-chain agent registries. | L2 |
| MCP, A2A | Model Context Protocol connects agents to tools; Agent2Agent connects agents to each other. | |
| Conformance, test vectors | Fixed inputs with expected outputs so implementations can check themselves. | |
| openclaw, moltbook, ClawHub | A self-hosted open-source agent, an agent-only social network built around it, and its skill marketplace. | Clawdbot, Moltbot |