# **honest.bot™: Verifiable Agent Identity**

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**

Julia Social and the agent produce the honest.bot credential through multiparty computation (MPC). When an agent process starts, it and Julia Social jointly compute a value that neither party can derive alone. That value becomes the agent's credential. Julia Social confirms that no other process holds a credential for the same identity. The MPC binds a secret to the running process's memory in a way that cannot be extracted from the credential itself.

A verifier confirms the credential by performing the same MPC interaction with the agent. If the agent holds the original secret, verification succeeds. No traffic goes to Julia Social during verification. The verifier and the agent handle it between themselves, plus a blockchain check that the credential has not been revoked.

Verification produces cryptographic proof that the presenting process is the one and only current holder of its identity. A second process attempting to present the same credential fails the MPC because it does not possess the secret.

This is process binding, and it solves a problem that key-based identity cannot. A private key can be copied to ten servers, and all ten can assert the same identity at the same time. An honest.bot credential cannot. The guarantee is not "whoever has this key is the agent" but "this specific running process, right now, is the agent." For ephemeral, replicable, distributable processes, this is the correct binding.

## **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 enumerate the agent's permissions. Each credential is scoped by property and value, time-bounded, and revocable.

**What task has this agent been assigned?** A task credential describes the agent's current mandate. Verifiers can check whether a requested action fits the stated purpose.

**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 delegated authority by a human can subdelegate narrower slices to specialist sub-agents. A research agent gets read access to a specific data source. A purchasing agent gets spending authority on a specific set of coins. A drafting agent gets permission to create documents but not to send them. Each sub-agent receives only the permissions it needs, and each permission is narrower than or equal to the one the orchestrator holds.

This attenuation is a cryptographic constraint, not mere policy. A verifier receiving a presentation from a sub-agent can inspect the full chain and confirm that every delegation falls within the scope of its parent. If an orchestrator issues a credential beyond its own scope, the credential fails verification.

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, against a revocation bitfield that holds up to 131,072 separately-revocable credentials, 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 MPC 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.

## **MCP-I: the emerging protocol layer**

The Model Context Protocol (MCP) gives agents a standardized way to connect to external tools and data sources. MCP-I (https://modelcontextprotocol-identity.io/) extends MCP with cryptographic identity and delegation, enabling agents to prove who they represent and what they are authorized to do.

MCP-I defines the protocol-layer questions: how an agent proves identity, how delegation credentials travel with requests, how edge services verify agent authority, and how audit logs capture agent actions. honest.bot's adversarial appliance MCP gateway supports two types of downstream endpoint: MCP-I servers that accept honest.bot presentations directly, and gateway servers that translate honest.bot assertions into conventional credentials (API keys, OAuth tokens) for services that do not yet understand agent identity.

MCP and MCP-I address how agents connect. honest.bot addresses what they connect with: a process-bound identity that proves uniqueness, a delegation chain that proves authority, and a containment architecture that prevents bypass. The protocol layer and the identity layer are complementary. MCP-I without a strong identity layer routes requests but cannot guarantee who is making them or that the requester is a single, unique process. honest.bot without a protocol standard requires custom integration at every service boundary.

## **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.

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](http://doc_07_privacy_architecture.md). If law enforcement needs to identify the person behind the alias, the same legal process described in [Law Enforcement & Accountability](http://doc_09_law_enforcement.md) 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, 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.

## **Further reading**

For the identity infrastructure that honest.bot shares with human identity, see [Identity Architecture: DIDs, Aliases, and Ownership](http://doc_06A_identity_architecture.md) and [Delegation and Organizational Identity](http://doc_06C_delegation.md).

For the human accountability model that anchors every delegation chain, see [Law Enforcement & Accountability](http://doc_09_law_enforcement.md).

---

*honest.bot™ is a trademark of Julia Social. The visible-signature technology used across the not.bot product family is patent-pending.*