British businesses need AI identities with limits

Estonia’s Aruait project is developing a framework for machines to act with limited, auditable and revocable authority. British companies should make that delegation model a condition of deploying autonomous agents. My position is straightforward: every agent needs an identifiable owner, enforceable boundaries and a tested way to stop its actions. Existing identity infrastructure can help, but a successful login should never substitute for permission to make a particular business decision.

Key pointers

• Require an agent’s records to identify both the software acting and the person or organisation authorising it.
• Separate permission to prepare a transaction from permission to commit it.
• Ask suppliers to demonstrate withdrawal of authority during an active task.
• Keep existing identity infrastructure where it can enforce the required controls.
• Include integration, monitoring, incident handling and exit work in the budget.
• Start with a reversible workflow whose results a named employee can check.

Estonia is investigating delegated authority

The significant part of Aruait is the proposed relationship between an agent and whoever authorises it. RIA intends to develop technical foundations and legal proposals through which citizens and businesses can grant machines limited authority, inspect its use and withdraw it. A planned central registry would verify public and private agents. These are project deliverables, not evidence that the complete system is operating.

That distinction matters when drawing lessons for Britain. The launch summary records unresolved questions about autonomy, accountability and participation by private companies. Estonia is investigating the problem rather than presenting a finished national template.

British businesses can nevertheless borrow the question driving that investigation. When software acts across organisational boundaries, how does the receiving system establish whose authority it carries and where that authority ends?

Consider a hypothetical British wholesaler using an agent to manage replenishment. The owner might authorise it to inspect stock, request quotations and prepare an order. Accepting changed payment terms or substituting an unapproved supplier could require separate approval.

A useful identity record should let the wholesaler distinguish those actions. Giving the agent a recognisable name is only the beginning.

A software employee needs a recorded mandate

“Software employee” is a metaphor for delegated work. For a British business adopting it, I would require separate records for the human sponsor, the agent and the underlying application credentials.

Those records should answer different questions. Who owns the business outcome? Which agent performed the action? Which technical identity opened the connection? Combining everything under a shared account would make that distinction harder to inspect.

For the hypothetical wholesaler, the proposed workflow is simple. A business owner approves a bounded task. The agent submits an action request. A control outside the agent checks that request against the recorded mandate before the business system executes it. Requests outside the mandate go to a human approver.

The activity record should connect the instruction, permission check, action and result. Withdrawing the mandate should block subsequent actions, and the business should test that behaviour while a task is running.

This is a proposed operating design, not a claim about Aruait’s implementation. Its purpose is to make authorisation enforceable at the point of action, rather than relying entirely on the agent to remember an instruction.

Budget for the work around the identity

Aruait’s 24 months and €1 million describe a public innovation programme. They are not an implementation timetable or cost estimate for a British company. RIA’s published scope combines technical development, governance work and a pilot.

For a business deployment, I would ask for separate costs covering identity configuration, connections to business systems, permission design, activity records, monitoring and incident response. Include staff training and the work needed to remove the agent or replace its supplier.

The acceptance test deserves its own budget. Someone must establish whether an agent can exceed its mandate, whether a withdrawn permission actually stops further actions and whether records remain available after the service ends.

A small business can keep this manageable by choosing a narrow workflow. Preparing replenishment orders for review offers a clearer starting point than authorising unrestricted purchasing. The owner can assess the value of the work before accepting greater autonomy.

The strongest counterargument is that identity platforms already do this

That objection has substance. Software identities are established infrastructure, and existing products are already developing agent-specific controls.

Microsoft’s workload identities overview describes applications, service principals and managed identities. It also describes Entra Agent ID features including enforced human sponsorship and governance from provisioning through deactivation. A claim that identity suppliers have simply ignored autonomous agents would therefore be wrong.

The same restraint should apply to supplier selection. Microsoft’s federation documentation covers workloads in AWS and Google Cloud, alongside the open-source SPIFFE/SPIRE approach, exchanging trusted identity evidence for access to Entra-protected resources. That provides evidence of connection options across several technology ecosystems. It does not establish which supplier offers the best complete agent-governance service.

For an AWS-centred business, a Google Cloud user or an organisation pursuing a portable open-source approach, the sensible comparison starts with existing infrastructure and required connections. Each should ask whether it can preserve the authorising party, permission boundaries and action records throughout the workflow. The supplied evidence does not support ranking those suppliers’ complete offerings.

My answer to the counterargument is to reuse controls that pass those tests. Buying a separate agent platform should require evidence that it closes a specific gap.

The harder test comes when the agent acts through another organisation’s service. Can that recipient inspect the relevant authority? Can permission changes reach the point where actions are accepted? Can both parties reconstruct what happened? Those are the capabilities I would require before increasing autonomy.

Editorial analysis

Britain’s opportunity is to make delegated authority a procurement requirement before agent deployments become difficult to unwind.

A supplier demonstration should show an agent receiving a permitted task, encountering a boundary and returning control to a human. It should then show the owner withdrawing authority while work remains outstanding. Finally, it should export records that the customer can inspect without depending on the supplier’s dashboard.

This places a concrete obligation on the buyer too. A British business owner must decide which actions the agent may take, who reviews exceptions and who answers when the result is wrong. An identity product cannot make those management decisions.

Estonia’s planned trust registry and interoperability work make this a useful subject to watch. My forecast is that an agent’s ability to present and respect a bounded mandate will become a stronger buying criterion as more workflows cross company boundaries. Businesses can test that capability now without assuming a national registry will arrive to supply it.

FAQ

Should a British small business replace its identity platform?

Start by testing the existing platform against the intended workflow. Microsoft’s documentation already describes agent-specific identity controls, so replacement is not automatically necessary. Buy additional capability when a demonstrated gap prevents the business from enforcing or inspecting its chosen limits.

Has Estonia launched a working national AI identity system?

The supplied primary evidence describes development objectives, a framework and a planned pilot. RIA’s launch summary says the project aims to produce an evidence-based blueprint rather than production-ready services within its duration. It should not be presented as a completed national deployment.

Is a workload identity enough for an autonomous agent?

A workload identity enables software to authenticate and access resources, according to Microsoft’s workload identities overview. For an autonomous workflow, I would also require a named sponsor, task boundaries, exception handling and an effective stop mechanism. Whether those controls need another product depends on what the existing system can demonstrate.

What should we ask an agent supplier to demonstrate first?

Ask it to withdraw an agent’s authority during a task and show what happens to pending actions. Then inspect the record connecting the original instruction, authorisation and completed work. Make successful completion of that test an acceptance condition for the deployment.

Sources

• RIA — Reason Reserve / Aruait, updated 28 August 2026.
• RIA — Reason Reserve / Aruait launch event summary, event held 12 June 2026; AI-assisted summary revised by the project manager.
• RIA — Artificial Intelligence, updated 19 June 2026.
• Microsoft Learn — What are workload identities?, updated 8 May 2026.
• Microsoft Learn — Workload identity federation concepts, publication or update date not established in the supplied extract.