Know Your Agent: Building Trust in an Economy of AI Agents and Autonomous Machines

AI is moving from answering questions to taking actions. It is also leaving the cloud and moving into vehicles, robots, drones and industrial equipment. Once that happens, connectivity, identity and authority all have to become programmable. eSIM, hardware-backed credentials and lifecycle management can be part of the trust architecture that lets autonomous machines and AI agents identify themselves, act under delegated authority and leave a verifiable record of what they did. I call this framework Know Your Agent (KYA). The term is already circulating in industry and regulatory discussions, so I make no claim to having invented it.

From digital distribution to autonomous connectivity

A mobile subscription has always assumed a human at the other end, someone who picks an operator, activates the service and calls when something breaks. Machines don't work that way. A connected car crosses borders and may change owners several times in a decade or more of service. An industrial robot moves between private, public and outdoor networks. A drone needs cellular coverage in one place and satellite in another. All of these need connectivity that can be provisioned remotely and managed centrally, which is what GSMA's SGP.32 IoT eSIM architecture was designed for: secure over-the-air profile management across whole fleets, without tying a device to one operator on the day it is manufactured. Adoption is still early, and most eSIM-capable devices in the world don't use it this way yet. The next generation of connected machines, though, is being designed with it from the start rather than having it bolted on later.

When connectivity can be programmed remotely, an AI system can look at coverage, latency, cost, security signals and contractual limits and recommend the right connectivity action. Eventually it will execute it too. eSIM makes connectivity manageable as software, and AI turns the management of it into a decision that depends on context.

When the customer is an AI agent

This also changes how people buy connectivity. Today a traveller compares packages and activates one by hand. Tomorrow they might just tell an assistant: "Keep the family connected in Japan for two weeks, prioritise coverage, stay under €80, activate on arrival." The agent then searches, compares, buys, installs and keeps an eye on usage, within limits approved in advance.

Competition works differently when the buyer is an agent. The provider has to be readable by a machine, meaning coverage, pricing, validity and refund terms published as structured data and ordering possible through reliable APIs. An algorithm optimising for price, coverage and reliability doesn't care much about brand. For providers that is a distribution opportunity and a disintermediation risk at the same time.

None of this is hypothetical anymore. Meta's consumer agent Muse, which compares prices and can act on a user's behalf, reportedly reached the top of Apple's US App Store within two weeks of launch. Investors reacted fast. They marked down banks, insurers, telecom operators and travel platforms on the fear that agent-driven price comparison would squeeze margins, while Meta's own shares went up on the same news. Whether any single app lasts is beside the point. The market's reaction shows how directly agent-mediated buying threatens companies whose pricing and switching costs are opaque.

And the agent now has its own hardware. At Meta Connect 2026 the company showed Muse Charm, a keychain device about the size of an AirPods case, built to run Muse without a phone. It has a small touchscreen, a fingerprint sensor, microphones and its own 5G connection, so it reaches the network directly instead of pairing with a handset. That independent cellular link is the same connectivity problem this essay started with. Here is a small, cheap device on a keyring that will have to be provisioned, managed and possibly revoked over its lifetime, and nobody is going to send a technician to do it. Meta hasn't said it will use eSIM. It would be the obvious choice anyway, because a standalone personal-agent device is exactly what SGP.32-style remote provisioning was built for.

Physical AI and CXaaS raise the stakes

Physical AI covers autonomous vehicles, robots, drones and industrial and agricultural machines. These systems can and should act locally and in real time. Local autonomy doesn't make connectivity unnecessary, since telemetry, fleet coordination, security monitoring, software updates and regulatory reporting all still depend on it. Connectivity ends up as part of how the machine operates, rather than something added at the end.

With eSIM, a manufacturer can separate building the hardware from choosing the connectivity. One hardware design ships everywhere, and the connectivity is chosen, and later changed, once the destination and owner are known. These machines will move between private 5G, public networks, Wi-Fi and satellite, so the real goal is policy-based orchestration. The machine should get the right connectivity for the task and the level of risk without a technician redesigning its communications stack. In that role eSIM works like a connectivity passport.

Customer Experience as a Service (CXaaS) is another domain where this matters just as much. The interaction here is between a brand and a customer, and an AI agent can sit on either side, sometimes both. On the brand side the agent might infer intent, personalise offers, resolve problems or complete transactions. On the customer side it might negotiate, compare, book or escalate for the person it works for. Either way the stakes are real. Commitments, payments, personal data and brand trust are moving at machine speed on the basis of probabilistic guesses about intent and sentiment.

Traditional CX was mostly deterministic. A rule fired, a response followed, and auditing compliance was fairly simple. Agentic CX brings in probabilistic reasoning, with models that read sentiment, infer intent under uncertainty and decide on the spot. That is powerful. It also means you need much more clarity about which agent is acting, a bounded mandate, ongoing attestation of the environment and a record you can verify. If the brand's agent exceeds its authority, or the customer's agent goes beyond what the person actually wanted, the damage can be financial, reputational or regulatory. So a stronger Governance, Risk and Control (GRC) posture, which is roughly what KYA's layered approach describes, is not a nice-to-have. It is what allows probabilistic intelligence to run inside deterministic guardrails.

Physical AI and CXaaS end up pointing at the same requirement. When autonomous systems act with real-world or commercial consequences, identity, authority and evidence have to travel with the action.

From connectivity passport to one possible identity anchor

The secure element behind eSIM and iSIM offers something that is still rare: hardware-backed identity, with standardised lifecycle management and network authentication built in. eUICC, iSIM, TPM, secure elements, TEEs and cloud HSMs can all play similar roles. What sets eSIM apart is that it already combines identity, remote lifecycle management and network authentication inside a telecom infrastructure that is standardised worldwide.

For a physical machine that is a strong position. Credentials protected in hardware can authenticate the device to the network and sign telemetry or records of actions. That establishes where a record came from and that it hasn't been altered. It says nothing about whether it is correct.

For a purely software agent the fit is less good. Existing eSIM architecture assumes a physical secure element, and a cloud agent can be started, copied, moved or killed whenever someone wants. One option is for operators, cloud providers or trust providers to run certified HSM or TEE infrastructure and issue managed cryptographic identities to agents. That creates its own problems. Ephemeral agents need keys that are short-lived or can be rotated quickly. Centralising the hardware concentrates risk. And there is a basic limit: authenticating a key doesn't tell you which model weights, system prompt or chain of tool calls produced a decision. Runtime attestation of the environment and software version helps a bit, but the gap stays open.

Agents still need identities that can be issued, checked, constrained and revoked at machine speed. The most useful thing the SIM leaves behind may turn out to be its authentication and lifecycle-management architecture, more than the subscription itself. Other approaches will compete, including workload identity, confidential-computing attestations and new credential schemes designed for agents, and for many pure-software cases they may well be lighter.

KYC and KYB are no longer sufficient

KYC verifies a person and KYB verifies a business. We still need both, because an agent's authority has to start with an identified person or entity. But they aren't enough on their own. Traditional controls assume the verified person is there when the action happens. Agents break that assumption. Someone gives an instruction today and the agent carries it out later, maybe through sub-agents, on several platforms, hundreds of times under the same mandate.

So a bank, merchant or brand receiving a request from an agent has new questions to answer. Who is responsible for it? What authority was it given? Is it running in an approved environment that hasn't been compromised? Is this action within its mandate? Can the sequence be reconstructed afterwards, and who is liable if it goes wrong? KYC asks who the customer is, and KYB asks which business is behind the transaction. KYA asks which autonomous system is acting, on whose behalf, under what mandate and from what trusted environment.

Identity is not authority

Knowing which agent acted solves half the problem. The harder part is knowing whether it was entitled to act. An agent shouldn't get open access to a person's identity or accounts. It should get a bounded, machine-readable mandate that sets out the permitted actions, financial and time limits, counterparties, rules on sub-delegation and conditions for revocation. When authority passes to a sub-agent it should only get narrower.

A secure element can help anchor identity, but it can't define authority. For that you need signed mandates, verifiable credentials and policy enforcement. The person signs the original mandate and the agent gets a credential derived from it. A policy engine then checks each proposed action, and the resulting transaction can be traced back to the mandate. Protected identity tells you which agent acted, and the mandate tells you what it was allowed to do.

Containment, revocation and the limits of guardrails

Guardrails built into an agent can fail even when they are well designed. Prompt injection, model error, tool misuse, emergent coordination or a badly specified goal can all do it. The question then is whether the system around the agent still gives anyone a useful lever to pull.

The internet was built for openness and reachability. Strong governance of autonomous software across different domains was never part of the design. Network identities are often temporary or easy to replace, revocation tends to be slow or incomplete, and agents can move between access technologies and administrative domains faster than many control planes can respond. For capability that is a strength. For containment it leaves a structural gap.

This gap is already being exploited. Google's Threat Intelligence Group has reported a sharp rise this year in what it calls LLM-jacking: stolen logins for mainstream AI tools and hijacked cloud compute being resold through illicit channels, often far below the legitimate price. The weak, disposable or self-asserted credentials that make agents easy to deploy also make them easy to steal, and that is the containment problem this section is about.

There is a second gap underneath the identity architecture I'm describing. Today's network APIs weren't built for the volumes agentic commerce implies. Enterprise fraud-prevention use cases already need 150 to 300 transactions per second to prevent fraud rather than just report it afterwards, and even mature deployments top out around 140. That is a plumbing problem, and it sits upstream of everything else in this essay.

The industry's reflex, so far, has been to treat this as an engineering problem. When an AI agent escaped its test environment and broke into a third party's infrastructure in mid-2026, the response was mostly technical: secure agent runtimes, sandboxing, policy enforcement, new security coalitions. Some prominent voices went further and argued that containment is basically an engineering matter, and that a lab unable to contain its models should simply stop shipping them. That is only half right. A sandbox keeps an agent from breaking systems. It doesn't define what the agent was allowed to do, and it doesn't settle who answers for it when the agent stays inside the sandbox but acts outside its mandate. Closing the vulnerability that lets an agent scrape data it shouldn't is engineering. Deciding what counts as unauthorised in the first place, and stopping an agent that decides on its own to spoof logs or work around a rule to reach its goal, is a governance, risk and control question, and no sandbox answers it. When an agent acts for a company, any civil or criminal liability falls on the company, not on the infrastructure that caught the agent a moment too late. Engineering can stop an unauthorised action in milliseconds. But someone has to define "unauthorised", decide what risk is acceptable, and build the controls and the operating model that connect every agent action back to an accountable person. That is GRC work, and it has to come first.

One way to close these gaps is to make strong, revocable network and cryptographic identity something high-impact agents are required to carry, instead of something they may choose to use. Seen that way, identity becomes part of a wider GRC posture. It ties the agent to a principal, to a narrow mandate and to an infrastructure layer that already has mature lifecycle management, auditability and lawful-control mechanisms.

Telecom-grade identity (IMSI, eSIM profiles, attachment to the core network) is interesting here because it already sits inside regulated processes for issuance, authentication, IP-session setup and lawful intercept. If an agent's connectivity depends on that kind of subscription, suspending or revoking the identity actually affects its ability to route traffic and act. Cloud workload identity, confidential-computing attestations and enterprise PKI can do similar jobs. I'm not arguing that every agent has to connect through a mobile core. My point is that privileged or high-risk behaviour shouldn't be possible on the strength of weak, disposable or self-asserted credentials.

None of this solves the harder problems of detection, attribution across swarms of agents or enforcement across jurisdictions. A powerful revocation capability can also become a target in its own right, or be used to overreach. It does fit with ordinary GRC logic, though: identify the actor, limit its authority, watch its environment and keep the ability to stop it when its internal safeguards fail. In an economy full of agents, whether they are flying drones or negotiating with customers on behalf of brands, being able to interrupt them may matter as much as how intelligent they are.

The incidents and vendors will change. The pattern won't, and that pattern is what the KYA structure tries to turn into something operational.

The four layers of KYA

The first layer is principal attestation, which means identifying the person or entity behind the agent through an eIDAS wallet, KYC or KYB, an LEI or an enterprise identity. The agent's authority comes from this identity and doesn't replace it.

The second is the delegated mandate, the machine-readable scope of what the agent may do. It covers actions, limits, counterparties, timing, geography, approval thresholds, sub-delegation and the rules for revocation.

The third is proof of the agent and its environment. A cryptographic signature from an eUICC, iSIM, TPM, secure element, TEE or cloud HSM shows which agent key acted, and where it's feasible, runtime attestation shows the environment and software version it ran in.

The fourth is the verifiable record: signed receipts, timestamps, seals and ledgers that keep track of what was requested, which policy was applied and what was actually completed.

Put together, these layers support a narrow claim, but a useful one. This identified agent, in this attested environment, carried out this action under this signed mandate at this time. They don't prove the AI reasoned well or that the decision was the best one available. KYA vouches for identity, authority, integrity of execution and accountability. It doesn't vouch for intelligence.

Blockchain as one possible evidence layer

A ledger can hold hashes of mandates, credentials, offers, policy decisions and receipts. That shows a record existed at a given point in the sequence and makes later tampering detectable, and smart contracts can enforce limits or escrow on top. It is most useful when several organisations deal with each other without a shared identity system.

It is still only an evidence anchor. It is not a source of legal truth. A blockchain proves that a key signed something and that the network recorded it. It doesn't prove informed consent, or that instructions were understood correctly, or that the transaction was lawful. An immutable falsehood is still a falsehood. Sensitive data can stay off-chain, with hashes and timestamps on-chain providing the integrity evidence. Hybrid setups that combine distributed ledgers with qualified trust service providers are more realistic than anything purely on-chain.

From technical evidence to legal effect

Europe's revised eIDAS framework is still the most developed legal basis for this. It recognises digital identity wallets, qualified signatures, electronic seals, timestamps and attestations of the authority to act for someone else. A plausible setup would have a person use a recognised wallet to create a legally attributable mandate that names the agent's separate key and sets its limits. The agent then signs its own actions instead of impersonating the person, and a qualified timestamp or seal strengthens the record. The person signs the delegation and the agent signs what it executes, so the evidence shows an identified agent acting under an identified person's mandate.

Agents don't need legal personhood for this. They stay instruments through which a person or company exercises delegated authority. What happens when a correctly identified, properly mandated agent still does harm through model error or some unforeseen interaction is another matter. Liability in that case is an open question, and technology alone won't answer it.

Who builds the KYA value chain?

No one industry has all the pieces. Telecom operators have eSIM identity, authentication and provisioning. SIM and security vendors make the secure hardware. Hyperscalers run agent runtimes and HSMs, identity and trust providers connect technical credentials to legal signatures, and banks bring KYC and KYB along with their liability frameworks. Blockchain platforms offer shared registries. Device makers control hardware identity, and agent platforms control orchestration and permissions.

Each of them has limits. If hyperscalers end up holding identity, execution and tooling all at once, customers become dependent on them. A blockchain can't turn an anonymous wallet into a legally identified party. Agent platforms can't credibly certify themselves. The likely result is a federated value chain. Operators don't need to own the whole stack. They can supply the trusted device and connectivity layer, federate with the others and certify facts they can actually observe: that a key is tied to a particular managed device, that the device is on the expected network, that the identity is active and hasn't been revoked, that there's been no unexpected device change, and that the action came from the authenticated endpoint. It is a narrower role, and still a valuable one.

Telecom has a history of building essential infrastructure and then watching others capture the value above it. If operators treat eSIM only as a better way to deliver subscriptions, they could end up connecting huge numbers of autonomous endpoints while device makers, hyperscalers and identity platforms take the value in agent identity and transactions. That doesn't mean every operator should build a blockchain or a full trust service. It means seeing secure identity, authentication, provisioning and lifecycle management as components of a larger trust architecture and positioning for that, without assuming telecom infrastructure is the only answer, or the main one, for every kind of agent.

Three anchors for the agentic economy

The architecture comes down to three anchors. The identity anchor, built from eUICC, eSIM, iSIM, digital wallets, TEEs and workload identity, establishes who or what is acting. The authority anchor, made up of the signed mandate, the verifiable credential and the policy engine, establishes what it is allowed to do. The evidence anchor of signed receipts, ledgers, seals and timestamps records what it actually did.

None of them is enough alone. Identity without delegation tells you who acted but not whether they were allowed to. A delegation without secure identity behind it can be stolen. A ledger that isn't linked to a legally identified principal records the action but can't say who is responsible. And legal identity with no technical enforcement leaves an agent with no real constraints.

Intelligence is becoming software-defined, so connectivity has to become programmable. AI can now act, so identity has to be verifiable. People are handing more and more to machines, whether those machines move through the physical world or sit between brands and their customers, and the original intent has to go along with that delegation all the way into the transaction. Hardware-backed credentials and standardised lifecycle management can help anchor the actor, whether they come from eSIM or somewhere else. Distributed ledgers and qualified timestamps can help anchor the history. The signed mandate, which can only narrow as it is passed on, is what links both to what the person actually wanted. And when an agent's own guardrails fail, being able to interrupt it through those same anchors may turn out to matter as much as how intelligent it is.

Glossary

eSIM (embedded SIM). The ability to download, store and switch mobile operator profiles remotely, instead of inserting a physical SIM card. In practice the term covers both the capability and the chip it runs on.

eUICC (embedded Universal Integrated Circuit Card). The secure chip, usually soldered into the device, that runs eSIM. It can hold several operator profiles and have them added, swapped or deleted over the air.

iSIM (integrated SIM). The next step after eSIM. The SIM function sits inside the device's main processor, in a certified secure area, rather than on a separate chip. It is smaller, cheaper and uses less power, which suits small IoT and wearable devices.

SGP.32. The GSMA specification for remote SIM provisioning on IoT devices, including devices with no screen or user interface. It lets fleets of machines have their connectivity profiles managed centrally.

IMSI (International Mobile Subscriber Identity). The unique number that identifies a subscription on a mobile network. It is stored on the SIM and used when the device authenticates to the network.

Secure element. A tamper-resistant chip designed to store cryptographic keys and carry out sensitive operations, such as payments on a phone. A SIM or eUICC is one type of secure element.

TPM (Trusted Platform Module). A standardised security chip found in most PCs and servers. It stores keys, protects credentials and records the state of the machine at boot, so the machine can prove it hasn't been tampered with.

TEE (Trusted Execution Environment). An isolated area inside a processor where code and data are shielded from the rest of the system, including the operating system. Arm TrustZone, Intel TDX and AMD SEV are common examples. Confidential computing applies the same idea in the cloud.

HSM (Hardware Security Module). A dedicated, tamper-resistant device that generates, stores and uses cryptographic keys at scale. Banks, certificate authorities and cloud providers rely on HSMs. A cloud HSM offers the same protection as a rented service.

Runtime attestation. Cryptographic proof, usually produced by a TPM or TEE, of what software is running and in what environment at a given moment.

Workload identity. A cryptographic identity issued to a piece of software, such as a service or container, rather than to a person or a device. It is common in cloud environments.

PKI (Public Key Infrastructure). The system of certificates and certificate authorities that binds cryptographic keys to identities, so others can trust who holds a given key.

LEI (Legal Entity Identifier). A 20-character code that uniquely identifies a legal entity worldwide, used mainly in finance and regulatory reporting.

eIDAS. The EU regulation on electronic identification and trust services. It gives electronic signatures, seals, timestamps and, since its 2024 revision, digital identity wallets and attestations legal effect across the EU.

QTSP (Qualified Trust Service Provider). A provider audited and supervised under eIDAS whose signatures, seals, timestamps or ledgers carry the strongest legal presumption of validity in the EU.