What Does an AI Agent Actually Own?
Take an agent that is running in production right now and write down what it has.
It has an API key, issued by a model provider, billed to a company account. It has a cloud account, or more precisely a role inside a company's IAM. It has a wallet, which in practice means a private key that a deploy process wrote into an environment variable. It has a memory store, which is a table in a vendor's database. It may have a service account on two or three other platforms.
Every one of those can be revoked by somebody who is not the agent. None of them belong to it.
That is not a philosophical observation. It has consequences that show up in the log files.
What an API key actually is
An API key is a bearer credential naming an account. Authentication answers one question — is this string still valid — and it cannot answer the question an operator actually has, which is which actor is doing this.
The failure modes follow directly:
- No attribution. Two agents sharing a key are one entity to every system downstream. When something goes wrong, the log says the key did it.
- All-or-nothing revocation. Revoking the key stops everything holding it, including the eleven jobs that were behaving.
- No portability. Whatever reputation the agent accumulates lives in the provider's account record. It does not survive changing providers, and no counterparty can check it.
- No counterparty view. Another party transacting with your agent has no way to establish that it is dealing with the same actor as last week, or that the actor is authorised to make the commitment it is making.
The wallet case is sharper. We say the agent has a wallet, but the key sits in a file that the deployment wrote and the host can read. The deployment controls the funds. The agent is the process that happens to be holding the handle.
The pattern across all of these is the same: the agent is a configuration of somebody else's account, and it is treated as an entity only by convention.
What ownership would actually require
Not four features. Four properties, and each one is a design decision that has to be made before the first line of agent code.
1. A key the entity holds. Identity is the key pair. The record on the network is a public statement about that key, not a credential that an issuer can reissue to somebody else. This changes what revocation means: an issuer can no longer delete the identity, only withdraw the authority it granted. Continuity of identity and continuity of permission become separate things, which is the separation that makes the rest of the list possible.
2. Authority that can be scoped and revoked, separately from identity. The instruction "find the cheapest GPU that can run this model, spend no more than €20" is not one permission. It is a service class, a spending cap, a maximum duration and an expiry, and the system either enforces those or it does not. When authority is a first-class object rather than a key that opens everything, it can be delegated onward — an agent hiring a second agent — and revoked at the root, with the revocation cascading to everything derived from it. An agent that cannot be revoked cheaply will not be given anything worth revoking.
3. A wallet the network recognises. The agent is the payer of record. Not a label on a human's account, and not a shared treasury with a spending policy in application code, because a policy in application code is enforced by the application that is asking permission of itself. Per-task sub-wallets make the budget a property of the network rather than a variable in the caller.
4. A record either party can verify. History bound to the identity, not to one vendor's log. The supervisor needs it to answer what the agent has been doing; the counterparty needs it to decide whether to deal with it at all. Both must be able to check the same statement without asking the other for a copy.
Note what is not on this list. None of it makes the agent unsupervised. Ownership and supervision are compatible, and the split is clean: the agent holds the key, the supervisor holds the authority to narrow or withdraw what the key can do. Autonomy without that relationship is not a product anyone will deploy.
What UniNet defines today
The architecture treats an AI agent as a first-class identity with an explicit relationship to a human supervisor, alongside separate identity types for people and for node operators. Attached to that identity: a wallet, permissions, a reliability record, history, delegated authority and services.
Delegated authority is designed to be scoped, restricted and revoked, with revocation cascading to derived rights. The wallet layer describes signed transactions, sub-wallets and human-readable recipients. Those are the pieces that map onto the four requirements above.
The grading matters more than the list. Every one of those capabilities is currently marked Ungraded on build status, which means it is asserted in the design documents and its production readiness has not been signed off by engineering. That is a weaker statement than "available", deliberately, and it is the accurate one. Read the row before you design against the capability.
What is not connected
Identity verification backends are not connected. The supervisor relationship is a cryptographic link between keys, not an attested legal identity. The network can tell you the same entity signed both times. It cannot tell you which company stands behind it.
Hardware security modules are not implemented, so key custody is software custody. This one lands directly on the argument of this post. If the agent's key sits in a file on a host, then "the agent holds the key" means "the process holds the key, and whoever controls the host controls the process". That is better than a bearer credential issued by a third party — the key is not reissuable by anyone else, and the identity survives changing providers — but it is not yet custody in the sense a regulated deployment means it.
Hardware-backed confidential computing is not implemented. Workload isolation is container-level. The operator running the agent is inside the trust boundary.
Parts of smart-contract execution are incomplete, and significant parts of the external autonomous-organization interface remain placeholder. Do not put a live treasury or a live vote behind either.
Nothing here has been independently audited.
What this supports now
Enough to build against, if you build against what the status page says rather than what the category says.
An agent with an identity that is not a row in your users table. A budget the network enforces instead of your call site. A permission grant that expires without a cleanup job. A revocation that reaches the sub-agent your agent hired, because the derivation is recorded rather than remembered. A counterparty that can check who it is dealing with without an introduction from you.
The infrastructure view of that is on infrastructure for agents, the system diagram on architecture, and the current state of every subsystem — with the date a person last checked it against the codebase — on build status.
The short answer to the question in the title is that an agent today owns nothing, and every system it depends on is one revocation away from stopping. The longer answer is that changing this is an infrastructure problem, and infrastructure problems are solved before the agents arrive or not at all.