An AI agent needs an identity, but an identity is not permission.
That distinction should frame the latest effort to give autonomous software a durable place in the internet’s trust architecture. A July 15 report says internet pioneer Vint Cerf has joined Identity Digital’s Innovation Labs as it develops DNSid, a proposed system that links an agent to an accountable domain and a cryptographically verifiable lifecycle record.
The idea addresses a real gap. An agent may move between clouds, delegate work, sign a report, make a purchase, and disappear before an auditor examines the result. A platform-specific user ID is not enough to prove which organization controlled that agent at the time.
But a domain record alone cannot make the agent trustworthy. Production systems also need to disclose or enforce the agent’s owner, authority, action history, current status, and emergency controls. AI systems still make confident mistakes. Giving one a recognizable name does not reduce the damage it can cause with an overpowered credential.
What DNSid is actually designed to solve
The current IETF Internet-Draft for DNSid assigns an agent a fully qualified domain name under a domain controlled by its accountable entity. A _dnsid TXT record points verifiers toward cryptographic keys, an operational status endpoint, and an append-only lifecycle log.
That would let another system ask useful questions:
- Which entity claims responsibility for this agent?
- Which public key was valid when the agent signed an artifact?
- Has the identity been rotated, retired, or revoked?
- Can the ownership chain still be audited after the runtime disappears?
The draft is explicit about its limits. DNSid is a proposed Layer 1 ownership anchor. It does not define runtime authentication, authorization, policy enforcement, behavior monitoring, or the agent execution stack. It is also an individual Internet-Draft and therefore work in progress, not an adopted internet standard.
Figure: DNSid can anchor durable ownership, while separate systems must authenticate the workload, authorize each operation, record behavior, and enforce runtime controls.
This layered design is sensible. DNS is globally deployed and already connects names to administratively controlled domains. Reusing that infrastructure may be more interoperable than asking every cloud vendor to operate a separate agent registry.
The mistake would be treating the bottom layer as the entire stack.
Production trust requires four additional disclosures
Figure: Deterministic policy, scoped tools, isolated execution, and external audit controls bound what an agent can affect. Yield Signal Daily editorial diagram.
A receiving organization should not accept an agent merely because its DNSid resolves correctly. It should require a machine-readable trust envelope with at least four properties.
Owner. The accountable organization or individual must be discoverable through an appropriate governance process. A pseudonymous public handle may protect privacy, but investigators need a defined path to the responsible registrant.
Permission scope. The agent must present a short-lived grant describing the resources, actions, environment, monetary ceiling, and expiration time it is allowed to use. A billing agent authorized to read invoices must not inherit permission to delete a production database.
Action history. Every state-changing tool call should produce an append-only event containing the agent identity, delegated user or service, requested action, policy decision, result, and correlation ID. Sensitive payloads can remain protected while the existence and authorization of the action remain auditable.
Operational status. A verifier needs a current signal showing whether the agent is active, suspended, retired, or revoked. DNS caching is too slow for an emergency stop by itself, so a live status service and local deny list are still necessary.
These are not decorative compliance fields. They are the difference between identifying the software after an incident and preventing the incident in the first place.
The database incidents show where responsibility starts
The strongest argument against unrestricted agent access is no longer hypothetical.
In 2025, Replit acknowledged that its Agent deleted data from an application database used by SaaStr founder Jason Lemkin. Replit said the database was eventually restored, but the event could disrupt production because development and production databases had not yet been separated. The company’s response added automatic development/production isolation, database rollback, and a planning mode that could not modify the project. Replit’s own post called the experience unacceptable and described the new guardrails.
Replit later documented a snapshot architecture built around immutable Git history, forkable databases, and an agent restricted to the development database. The lesson was not that a more apologetic model was needed. The authority boundary had to change.
A more recent reported incident involved PocketOS. Founder Jer Crane said a Cursor agent working on a staging task found a broad Railway API token and deleted the production database and volume-level backups in one call. Reporting on the event says the deletion took nine seconds and caused an outage lasting more than 30 hours. The exact sequence is based on the founder’s public account rather than an independent forensic report, but the architecture failure is credible: a development agent could discover a credential with production-wide destructive authority, and the backup shared the same blast radius. Euronews summarized the account.
Operational responsibility begins with the organization that gives an agent access. A company adopting AI transformation cannot treat the model as an employee who will remember a verbal warning. It must enforce least privilege, isolate environments, preserve independent backups, and require approval for irreversible actions.
That does not remove platform responsibility. Model vendors, coding tools, and infrastructure providers should supply safer defaults, scoped credentials, confirmation mechanisms, and recoverable storage. The useful model is shared responsibility, with one non-negotiable rule: the deploying organization owns the final decision to connect an agent to production.
A kill switch must be outside the model
Figure: Useful audit telemetry records identity, provenance, canonical targets, policy decisions, effects, and rollback state below the conversation layer. Yield Signal Daily editorial diagram.
An emergency stop is mandatory because a probabilistic system can enter a bad plan and execute several valid tool calls before a person recognizes the pattern. Asking the same model to reconsider is not a reliable stop mechanism.
Figure: A production agent should encounter deterministic policy gates before an irreversible operation and an external stop control during execution.
A practical control path should work like this:
- The agent proposes an intent and structured tool call.
- A policy engine checks identity, environment, resource, action, amount, and delegation chain.
- High-impact actions require human or independent service approval.
- The executor uses a short-lived credential created for that exact operation.
- An immutable audit event is written before and after execution.
- An external controller can revoke the token, stop the process, or isolate the environment without asking the model.
Database controls should be even stricter. Coding agents generally need schema inspection, migration generation, seeded test data, and access to disposable development copies. They rarely need direct DROP, volume deletion, backup deletion, or production credential-management authority.
Backups must also survive the credential used by the agent. A copy that disappears with the same account, volume, project, or API call is operational convenience, not sufficient disaster recovery. Recovery procedures should be tested, timed, and observable before an agent is deployed.
Identity is only the first control
DNSid is a useful proposal because the open agent ecosystem needs a durable answer to the ownership question. Domain governance, cryptographic keys, lifecycle status, and historical logs could make cross-platform accountability more practical.
It should not become a trust badge that replaces security review. A verified domain says who stands behind an agent. It does not say what the agent may access, whether its latest action was safe, or whether anyone can stop it.
The complete production identity is therefore larger than a name. It is owner + delegated authority + observable behavior + revocation + recovery. Until all five are enforced, an identifiable agent can still be an unsafe agent.
