honest.bot: Verifiable Agent Identity

Updated June 24, 2026

People talk about AI agents as if they are individuals. They give them names. They describe what "the agent" did. They delegate tasks the way they would to a new hire. The metaphor is powerful, and it is wrong.

An AI agent is a process. It might run on one server or fifty. It might be a single instance or one of thousands sharing the same credentials. It has no persistent self, no legal standing, and no capacity for accountability. If it sends an email it should not have sent, nobody can prove which process did it, who authorized it, or whether the "agent" that sent the email is the same "agent" the user configured an hour ago.

The gap between what people assume about agents and what agents are will define the next generation of security failures. honest.bot closes that gap.

The missing security principal

Enterprise identity systems are built on a concept called a security principal: a unique, identifiable entity that authenticates, receives authorization, and generates an audit trail. A user account is a security principal. A service account is a security principal. A certificate-bearing device is a security principal.

An AI agent, as deployed today, is not a security principal. It borrows credentials from the human who configured it. It authenticates to downstream services using the human's OAuth tokens, the human's API keys, the human's session cookies. The downstream service cannot distinguish the agent's actions from the human's. No audit trail, policy engine, or access control system can reliably differentiate "the human did this" from "the human's agent did this."

This is the equivalent of handing your badge to a contractor and having every door log your name when they walk through.

honest.bot makes every agent a proper security principal. Only one process in the world can have a particular honest.bot-credentialed, cryptographically verifiable identity. It authenticates on its own behalf. It carries its own permissions. It generates its own audit events. And its authority traces, through a cryptographic delegation chain, back to a specific alias of a not.bot™-verified human.

How honest.bot works

An honest.bot credential gets bound to one running process at the moment it is issued by Julia Social. Multiparty computation (MPC) between Julia Social and that process enforces the binding, so neither party alone can reproduce the credential for a different process. From then on, only that process can produce a valid presentation of it. A verifier receiving the presentation can confirm that it came from the one and only process to which the credential was issued.

This guarantee survives key sharing. Suppose many agents run from the same signing key: ten copies of an agent holding identical key material on ten servers, signing identical bytes. The honest.bot credential is not that key. Its binding to one process comes from the MPC issuance, not from possession of key material, so among those ten copies only the process that received the credential passes verification. The other nine hold the key and still fail.

No traffic goes to Julia Social during verification. The verifier does perform a blockchain check that the credential is correctly signed and has not been revoked. What the verifier obtains is cryptographic proof that the presenting process is the current, sole holder of its identity.

For processes that are ephemeral and replicable, this is the binding that matters. A key answers the question "who holds the right credential material." Process binding answers the question a verifier needs answered: which running process, right now, is this agent.

What an agent presents

An honest.bot presentation answers four questions, each expressed as a standard did:julia verifiable credential:

Who is this agent working for? The delegation chain traces the agent's authority back to one specific alias of an accountable not.bot-verified human. The chain is included in every presentation.

What is this agent permitted to do? Capability credentials are authorizations. Each enumerates a permission scoped by property and value, time-bounded, and revocable. A holder delegates them by subset: it can pass on some or all of what it holds, never more.

What is this agent assigned to do? A mandate credential states a purpose in plain language for an intelligent verifier to interpret, such as "handle the vendor XYZ renewal." A subdelegated mandate names its parent mandate as an antecedent, so the verifier can trace purpose down the chain and judge whether each agent's mandate stays within the one that authorized it.

What technology is this agent using? A technology stack credential, issued by the platform operator, attests to the runtime, model, and tooling. This credential is non-delegatable: the agent can present it but cannot pass it to another agent.

These are ordinary did:julia credentials. There is no parallel credential system for agents. The full power of Julia Social's credential infrastructure, including antecedents, subdelegation control, property limitation, time-bounding, and mass revocation, applies to agent governance with no modification.

Delegation and attenuation

An orchestrator agent that a human delegated to can subdelegate to specialist sub-agents. Two things travel down that chain, and they narrow in different ways.

Capabilities narrow by subset. Capability credentials are authorizations. A not.bot holder might delegate five of them to an orchestrator; the orchestrator subdelegates three to a worker and not the other two. Each child grant is narrower than or equal to its parent. This attenuation is a cryptographic constraint, not policy. A verifier inspects the full chain and confirms by computation that every capability was properly subdelegated to the presenting agent.

Mandates narrow by meaning. A mandate credential is natural-language text for an intelligent verifier to read. The human signs "handle Q3 vendor renewals" to the orchestrator. The orchestrator signs "handle the vendor XYZ renewal" to a worker and names its own mandate as the antecedent. The verifier follows that link up the chain and judges whether each mandate sits within the one above it. "Handle the vendor XYZ renewal" fits inside "handle Q3 vendor renewals," so it stands. A worker mandate to update the payroll system would not, and the verifier blocks the action even where a capability would allow it. The verifier reaches this verdict by reading the text and reasoning about scope, where it reaches a capability verdict by computing a subset. Evaluating a mandate this way takes an intelligent verifier, one using AI to read the language and judge scope. The identity, delegation, and capability checks ask for no such judgment; any verifier computes them from the credentials alone.

Put the two chains together at the point of action. A worker attempts to log in to the vendor's MCP server. The verifier receives the worker's not.bot credential with its delegation chain back to the issuing human, both mandate credentials, and the capability credential for that login delegated from human to orchestrator to worker. It reads two things from them. The human held the login permission and, by signing the mandate, accepts accountability for the renewal commitment. And the action in front of the worker falls inside both authorizations at once. The agent may act only in the overlap of the two chains: a step has to be covered by a capability it holds and fall within its mandate. A step a capability permits but the mandate excludes gets blocked, and so does a step the mandate describes but no held capability covers. The verifier evaluates the point-in-time intersection of capability and mandate that the worker holds for the task it is attempting.

Revocation cascades. If a sub-agent misbehaves, its parent revokes the delegation. If the parent is compromised, the root human voids the parent's delegation, and every credential downstream of it dies. A single blockchain transaction can directly revoke up to 512 credentials at once and indirectly revoke many more.

Agents as adversaries: containment architecture

honest.bot defines the identity layer. Containment, making sure the agent cannot bypass its identity, is a separate problem. Julia Social's implementation is the adversarial appliance: a confidential virtual machine (AMD SEV-SNP or Intel TDX) that treats the agent inside it as the adversary with the presumed intent to bypass containment.

The appliance runs four cooperating services alongside the agent. An ingress daemon accepts input from only one authenticated not.bot owner or that human’s delegates. An identity daemon holds the signing key, sealed to the VM's attestation measurements, accessible only through a signing operation over a Unix domain socket. The agent can inspect the credentials it holds, but can never see the private key. An MCP gateway is the agent's only path to the outside world: it provides a server to the agent, and attaches at least its honest.bot and delegated not.bot credentials to every outbound transaction call. An audit daemon maintains an append-only log of every action, anchored to the appliance's attested identity.

The agent inside the VM cannot directly reach the internet. It cannot open arbitrary sockets. It cannot read the signing key. Its only way to interact with external services is through valid MCP tool calls, routed through the gateway. The architecture distinguishes enforcement (host firewall, confidential VM, protocol termination, cryptographic verification at counterparties) from convenience (disabled tools, system prompt instructions, model tendencies). Enforcement holds even if the agent is fully compromised by prompt injection, poisoned tool results, or adversarial fine-tuning.

Governance and auditability

Security principals generate audit trails. If your agent framework cannot produce one, regulators and customers will notice. honest.bot generates audit material at every layer.

Identity lifecycle. Every credential issuance and every delegation event is cryptographically signed. A compliance team can reconstruct who authorized which agent, when, with what permissions, and when those permissions were revoked.

Runtime actions. The adversarial appliance's audit daemon logs every inbound request, every agent action, every outbound call, and every signing operation in an append-only log. Signed checkpoints anchor the chain to the appliance's attested identity.

Delegation provenance. Every honest.bot presentation includes the full delegation chain. An auditor examining a specific agent action can trace authority from the acting sub-agent, through the orchestrator, back to the human who initiated the chain.

Single human owner. Every honest.bot container accepts input from only one not.bot-verified human. Honest.bot agent behavior cannot be altered by commands or context provided by any third party. An honest.bot agent is an extension of that one human’s identity.

No input reaches the agent unless that human or one of their delegates signed it. Everything the agent does follows from choices that human made: the agent they selected, the model and initial context they configured, and every input they fed it. The appliance logs all of it. That chain of signed, recorded input is why the human behind the not.bot can be held accountable for the agent's actions. They chose the agent, and they supplied everything it acted on.

This audit trail serves compliance, but it also gives organizations a concrete answer to the question regulators and customers will ask: when your agent did X, who was responsible? honest.bot's answer is a cryptographic chain that any party can verify independently.

Human accountability: the non-negotiable root

Every honest.bot delegation chain terminates at a not.bot-verified human. The system does not permit autonomous agents with no accountable root.

An agent has no legal standing and no capacity for consequence. It cannot be sued, fined, or imprisoned. Accountability must rest with a person who can bear those consequences. honest.bot makes the relationship between agent and accountable human explicit and verifiable. Any verifier, at any point, can inspect the presentation and determine who is responsible.

The delegation chain uses aliases, not real-world identities. The accountable human is identified by a specific not.bot alias, preserving the privacy architecture described in the Privacy Architecture. If law enforcement needs to identify the person behind the alias, the same legal process described in Law Enforcement & Accountability applies.

How people think about bots, and what they get instead

People think of bots the way they think of employees. Each bot has a name. It does things on your behalf. You trust it with specific tasks and expect it to stay within bounds. You want to know what it did while you were away. If it breaks something, you want to know which bot did it.

Current agent infrastructure delivers none of this. Most agents authenticate with borrowed credentials. Multiple agents can share a single identity. An agent's "name" is a UI label, not a verifiable identity. No service on the receiving end can tell whether it is talking to the agent the user configured, a copy of that agent running on a different server, or a different agent entirely using the same API key.

honest.bot delivers the model people already assume. Each agent is a unique, identifiable entity. It has its own credential that no other process can use. Services receiving its requests can verify its identity, check its permissions, trace its authority back to a specific human, and log its actions under its own identity rather than its owner's. "My bot, doing my tasks, accountable to me" is how the system works, not a convenient fiction about what the system does.

Where honest.bot fits in the landscape

The industry is converging on the recognition that agents need identity. NIST launched its AI Agent Standards Initiative in February 2026, publishing a concept paper on agent identity and authorization. The initiative asks whether existing identity standards (OAuth, SPIFFE, OpenID Connect) can be adapted for agents. Products and frameworks are emerging from multiple directions.

Existing IAM adapted for agents. Some companies are extending enterprise identity management to treat agents as first-class security principals within existing OAuth and OIDC frameworks. This approach has the advantage of compatibility with deployed infrastructure. It inherits a limitation: these systems bind identity to keys and tokens, not to running processes. Two instances sharing the same token are indistinguishable. Delegation is constrained by OAuth's single-hop model, and multi-hop delegation chains remain an unsolved problem in the standard.

Verifiable credentials for agent authentication. Others are applying decentralized identity and verifiable credentials to agent-to-user and agent-to-agent authentication. Agents present verifiable credentials to prove their identity. Users present verifiable credentials to share data with agents under explicit consent. These solutions address the authentication question with standards-based credentials, but do not provide process-binding. The credential proves that an agent possesses a valid credential, not that the presenting process is the unique current holder.

Specification-layer efforts. MCP-I adds identity and delegation semantics to the MCP protocol. It defines how agents prove identity, carry delegation credentials, and subject themselves to edge verification. AgentDID, a recent academic proposal, explores decentralized identifiers for autonomously created agents with self-managed identities. Both address the protocol question. Neither specifies a mechanism for proving that a given process is the sole current holder of its identity.

Where honest.bot differs. honest.bot is the only system that provides all of the following: process binding through MPC (not key binding), verification without contacting the issuer, delegation chains that terminate at a verified human, two attenuation chains the verifier enforces together (capability authorizations narrowed by cryptographic subset, natural-language mandates narrowed by an intelligent verifier reading antecedent-linked text), cascading revocation, a containment architecture that enforces identity even against a compromised agent, and a shared identity infrastructure with human identity (the same did:julia system, the same blockchain, the same credential primitives).

The distinction that matters most is process binding. Every other system in the landscape binds agent identity to a credential or key that can, in principle, be presented by any process that holds it. honest.bot binds identity to a specific running process through MPC. The credential cannot be extracted, copied, or shared. If the process terminates, the credential becomes available for reissuance, but no other process can use it in the interim.

Production today, product tomorrow

honest.bot's core mechanism is in production. Every not.bot Verify signature server acquires an honest.bot credential at startup. No two Verify servers in the world can hold the same credential at the same time. The not.bot app verifies the Verify server's honest.bot credential on every interaction, without contacting Julia Social. This is a working deployment of the MPC protocol, the credential issuance flow, the revocation mechanism, and the verification protocol.

The honest.bot product, the SDK, the adversarial appliance, and the ability for third parties to deploy their own honest.bot-credentialed agents, is targeted for Q4 2026 deployment. The product is in development.

The scope extends beyond LLM-based agents. Any automated process, whether an RPA bot, a trading algorithm, a legacy integration service, or an IoT controller, can be an honest.bot-credentialed entity. The framework applies wherever accountability for automated action matters.