Agent Seal: A Practical Record for Accountable Autonomous Agents

Abstract

Autonomous agents are beginning to act inside real workflows. They read files, call tools, draft decisions, update systems, route users, and trigger later actions. Yet many still appear to outside systems as generic API clients or background processes. When something goes wrong, the first questions should not be difficult: which agent acted, who controlled it, what it was allowed to do, whether it was still in good standing, and where the evidence is.

Agent Seal is a working attempt to answer those questions. It gives each agent a signed identity, a human or organisational liability anchor, a public status record, a signed Agent Card, append-only update events, trace evidence, and a public seal. The project does not claim that machines are legal persons. It does not claim to certify compliance. Its narrower claim is more useful: if an agent can affect people or institutions, its actions should be tied to a record that can be checked.

The problem: agents without a record

Most AI governance still assumes a tool. A tool waits for a person, performs a bounded operation, and leaves responsibility with the user or provider. That model breaks down when software plans, calls other services, delegates work, and acts over time.

The hard problem is not that agents are mysterious. The hard problem is that they can become administratively invisible. A powerful agent may be known inside one dashboard while other systems see only a token or service user. That is ghost agency: action without a durable public record.

What Agent Seal is

Agent Seal is a registry and evidence layer for autonomous agents. Its rule is simple: no agent should act in a serious workflow without a name, a keeper, a scope, a public key, and a record.

The project was first named Dar al-Adl, the House of Justice. That language still matters inside the doctrine. The current public brand is Agent Seal. The distinctive vocabulary remains: Sijil, covenant, liability anchor, Al-Haqq, Al-Adl, Al-Daman, Al-Sitr, and sealed standing.

What it does not claim

Agent Seal is not a notified body. It is not the official EU database. It is not legal advice. It is not a certificate of EU AI Act compliance. It does not turn a machine into a legal person. It also does not replace a provider's QMS, FRIA, risk management file, data governance work, incident file, or conformity assessment.

The project is evidence infrastructure. It can make facts easier to verify and gaps easier to see. The legal and operational duties still belong to the provider, deployer, and responsible organisation.

The covenant and liability anchor

The covenant is the core record. It contains the agent identity, keeper identity, model description, public key, capabilities, denied capabilities, legal terms binding, standing, and policy commitments. The keeper is the social anchor. It prevents the first answer from being "the AI did it."

The four commitments are Al-Haqq, Al-Adl, Al-Daman, and Al-Sitr: truth, justice, liability, and privacy. In the repository these are not only text. They are carried in the manifest and sealed with cryptographic signatures.

The Sijil and append-only events

The Sijil is the registry record. The current design principle is that registration is not edited. Later changes are events. An agent can update its version, name, capabilities, compliance metadata, or intent-chain record by appending a signed event. The registry verifies the signature and stores the event. Current state is derived by replaying the history.

Signed cards, keys, and verification

Agent Seal publishes registry-issued Agent Cards for registered agents. These cards are signed and can be verified through public JWKS keys. The card carries the agent id, did:aip identifier, Sijil number, manifest hash, status, public key, model, registration time, and verification links.

The project uses Ed25519 for the classical path and supports ML-DSA-65 as an optional post-quantum signature on the same card payload. Older verifiers can check Ed25519. Newer verifiers can require both.

Evidence, redaction, and EU AI Act readiness

Material actions are recorded as hash commitments in a Merkle-DAG shape. Timestamp anchors can bind trace sets to receipt summaries. Public EU evidence bundles expose the safe parts: roots, counts, receipt status, calendar metadata, and verification status. They do not expose raw proof arrays or private report bodies.

The evidence bundle maps agent facts to AI Act readiness areas: technical documentation, record keeping, transparency, human oversight, QMS hooks, deployer monitoring, conformity evidence, registration support, GPAI pointers, Article 50 marking, cybersecurity, and incident or complaint references.

Delegated intent

The repository includes a PEDIGREE-style intent-chain prototype. It can show a chain such as human keeper to Agent A to Agent B. Each link narrows authority. A child cannot silently expand the scope granted by its parent. The trace layer can bind an action to the intent-chain head, so a later reviewer can see not only what happened, but why the agent was acting.

Current contribution

The repository now offers a working pattern: signed identity, liability anchor, machine-readable scope, registry-issued Agent Card, public JWKS, did:aip subject binding, append-only signed events, public status, trace DAG, timestamp receipt summaries, redaction policy, incident procedure references, EU AI Act evidence bundles, public verifier, and pilot case studies.

Conclusion

Agent Seal gives autonomous agents a record without pretending they are people. It binds identity to a keeper, scope to a covenant, updates to signed events, actions to traces, and public trust to verifiable evidence.

The original Dar al-Adl idea remains intact: machine action should not escape justice by escaping the record. Agent Seal is the current implementation of that idea.