Solutions · Autonomous agents
Agents need authority, not just intelligence.
A model can reason. It cannot hold an identity, carry a spending limit, reach a private service or settle a payment.
The problem
You are already asking these questions.
- How does an agent authenticate itself?
- Who owns it?
- What happens when it spends money?
- How do you restrict what it is allowed to do?
- How do you prove afterwards what it actually did?
- How does it pay another machine without a human in the loop?
Each one has an answer today. The answers live in different systems, and none of them belongs to the agent. Identity is an API key in a secrets manager. Authority is a hand-written check somewhere in your own code. Payment is a company card behind a payments provider. Audit is a log file you control and could rewrite.
That arrangement holds while a person is on the other end of every consequential action. It stops holding the moment the agent runs unattended across services you do not operate, because each of those systems assumes an account holder who can log in, accept terms and be held responsible. The agent is the only participant in the picture that owns none of its own infrastructure.
The principle
Identity belongs to the entity that controls the key.
An API key is a credential your platform issues and your platform can read. It identifies a caller to one service. It does not make that caller an entity, and it carries nothing about who is accountable for what the caller does.
An agent identity differs in one specific way: the agent holds the key. Authority is delegated to that identity with a scope, a cap and an expiry, and the delegation is evaluated by the network rather than by a conditional in your own code. Withdrawing it is a network operation, not a deployment.
Accountability does not disappear when a human steps out of the loop. An agent identity carries a supervisor relationship to a human identity, recorded at the network layer. Autonomy and accountability are separate properties, and both are recorded.
Identity verification backends are not connected, so a supervisor relationship is a cryptographic link between keys rather than an attested legal identity.
Architecture
Five accounts, or one identity.
Today an agent borrows five credentials from five systems, none of which it owns and one of which sees all of it. The alternative is not a better credential. It is an entity the network recognises.
- API key in a secrets manageridentity
- Cloud IAM roleauthority
- Payment provider accountpayment
- Cloud compute accountexecution
- Provider-side logaudit
- Agent identityhuman supervisor recorded
- Delegated authorityscope · cap · expiry · revocable
- Discover · authorize · paynetwork primitives
- Isolated containerdeclared resource limits
- Result to the agent identityreturned over UNP
- Recorded statecheckable by either party
On the left: five separate accounts, none of them owned by the agent, and one provider positioned to see them all. On the right: one identity the agent holds, carrying a supervisor relationship, a wallet, a delegation and an address — with the record of what happened produced by the network rather than by the party being audited.
Evidence
What you need, and what the network provides.
One row per requirement. The status column reads from the same source as the build status page. Where a row carries both a primitive and an unfinished dependency, the chip reports the weaker of the two.
| What you need | UniNet primitive | Status |
|---|---|---|
| Agent identity | An AI agent is a first-class identity type, distinct from a personal identity and a node-operator identity. | Ungraded |
| Human accountability | The agent identity carries a supervisor relationship to a human identity, recorded at the network layer. Today that link is between keys, because the verification backends behind it are not connected. | Not implemented |
| A wallet the agent controls | Signed transfers, sub-wallets and human-readable recipients at the network layer rather than through a payments integration. | Ungraded |
| Spending limits | A delegation restricted by maximum spend, allowed service class, duration and expiry, evaluated by the network. | Ungraded |
| Withdrawing delegated authority | Revocation that cascades to everything derived from the delegation, including rights the agent has re-delegated onward. | Ungraded |
| Service discovery | Available CPU, memory and storage are inspectable across nodes, and capacity is reserved atomically with fallback to another suitable node. | Ungraded |
| Network privacy | UNP gives a service an address decoupled from its machine, and separates users, relays and serving machines so no single relay holds the complete mapping. | Ungraded |
| Execution | Workloads run in containers with declared resource limits and lifecycle operations. Isolation is container-level only. | Ungraded |
| Persistent state | Storage an agent can write to and read back under its own identity rather than a shared service account. | In development |
| Machine-to-machine payment | A signed transfer between two identities, settled inside the delegated cap with no human approval step in the path. | Ungraded |
| Provider reliability signal | Reliability recorded against a node-operator identity at network level rather than inside one marketplace database. | Ungraded |
| Cross-chain activity | Asset and message transfer between UniNet and networks such as Ethereum. | In development |
| Auditability | The exchange is recorded as network state, so the record is not held solely by the party whose behaviour is in question. | Ungraded |
Ungraded means the capability is described in the architecture and its production readiness has not been signed off by an engineer. It is not a synonym for working. Read each row on the build status page before you design around it.
Reference design
An agent acquires compute it had no account for.
Twelve steps, each one a network primitive rather than an integration your team maintains. No human creates an account, approves a call or releases the payment.
Create identity
An agent identity with a linked human supervisor, recorded at the network layer.
Receive delegated authority
Maximum spend, allowed service class, duration and expiry, signed by the supervisor.
Search available compute
Query CPU, memory and storage across nodes rather than a single provider API.
Evaluate providers
Declared capacity and the reliability score carried by each operator identity.
Select a provider
Selection against a policy the agent was given, not a hard-coded address.
Reserve compute
Atomic reservation, with another suitable node selected when the first is full.
Send the workload privately
Reached over UNP at an address decoupled from the machine that serves it.
Execute in isolation
A container with declared resource limits and a defined lifecycle.
Receive the result
Returned to the agent identity that paid for the reservation.
Verify the transaction
The reservation and the delivered work checked against recorded state.
Pay the provider
A signed transfer from the wallet the agent controls, inside the delegated cap.
Record the interaction
The exchange recorded as state either party can check independently.
This flow does not run end to end today. Steps three to eight cross multi-node orchestration, which is still evolving, and the remaining steps are ungraded. The status of each one is published on the build status page.
Limitation
Read this before you design around any of it.
Identity verification backends are not connected, so a supervisor relationship is a cryptographic link between keys rather than an attested legal identity.
Hardware security modules are not implemented, so key custody is software custody.
Hardware-backed confidential computing is not implemented. If your threat model includes the operator running your workload, UniNet does not solve that today.
Full multi-node infrastructure orchestration is still evolving.
Validator production deployment is not complete.
Parts of bridge verification are incomplete. Do not design a production cross-chain settlement path around it yet.
Storage endpoints are still being connected.
Some identity authorization paths deliberately fail closed, which means a request is refused rather than silently permitted while this work continues.
Build against the primitives. Do not put production spend limits on this network yet.
Possibility
What you can build against this.
Agent identity, delegated authority, wallets and private addressing are primitives of the network. Agent-to-agent commerce is something you build on top of them.
Concretely: an agent that holds its own key and its own wallet. A delegation that expires without anyone remembering to end it. A service your agent reaches without learning which machine serves it. A payment that settles between two identities with no human approval step. A record of the exchange that neither side has to be trusted to keep.
If you are designing that system now, the useful conversation is which of these primitives you would depend on and which you would still have to build yourself. We would rather have that conversation than give a demonstration.