Agent identity, agent sandboxes, tool calls, agent-to-agent trust
Attested AI agents
TLS proves who you are talking to. Re-attestation proves what it is running, today.
An agent acts on someone's behalf, calls tools and talks to other agents. Each of those parties needs to know which code, which model and which policy is behind the request. That answer changes every time the agent is updated, so it has to be proved again each time.
Who this is for
- Agent platform builders, whose agents call tools and other agents
- Sandbox and agent-cloud providers, whose customers run thousands of agent machines
- Companies deploying agents, security teams asked to approve them
When trust has to be proved again
The agent gets a machine of its ownSandboxes and cloud computers for agents are created in seconds and by the thousand. Each one should prove which image, tools and policy it started with before it is handed credentials.
The agent's prompt, tools or policy changeThe agent is now a different program; its identity should say so.
The agent calls a tool or another agentThe receiver needs current evidence, not a long-lived API key that outlives the code that earned it.
The agent is delegated new permissionsDelegation should depend on attested properties, and lapse when they stop holding.
What we deliver
- Workload identity for agents (SPIFFE-style short-lived identities) tied to attested runtime properties.
- A trust model for tool calls and agent-to-agent requests, including what to log as evidence.
- For sandbox and agent-cloud providers: attestation your customers can verify for every machine you start for them, and again when a long-running machine is resumed.
- A review of where long-lived secrets stand in for proof today, and how to retire them.
Questions worth answering
- If an agent's code changes, does its credential change too?
- You run a thousand agents on rented machines. Can you show what each machine was running?
- Can a tool tell an attested agent from a copied API key?
- Who can prove, later, which agent version took an action?
Across the life cycle
DesignBuildMake or deployOperateUpdateRetire
The stage that decides here: operate. An agent's tools and prompt change while it runs. Proof has to be part of operation, checked at each call. See attestation in the product life cycle.
Rules and standards your buyers cite
EU AI ActDORAeIDAS 2.0 and the EU Digital Identity Wallet
Use case
An AI agent that calls tools for an enterprise
Go deeper
Who builds in this area
From our public landscape: Astrix Security, Aembit, Auth0 for AI Agents, Keycard, Descope, Oasis Security, Token Security, Clutch Security, Microsoft Entra Agent ID, A2A Protocol, Model Context Protocol, Pomerium, Riptides, Solo.io (agentgateway), Blaxel, Freestyle, Beam, Cua, Superserve, Orgo, Dedalus Labs, machine0, Boat, Maritime, Agent 37, Tilo, Kernel, microsandbox, E2B, Daytona, Modal, Runloop, Tensorlake, Sprites, Vercel Sandbox, Cloudflare Sandboxes, Northflank, Namespace.
Not quite your case? Selling inference, not agents? Attested AI. Need an identity for the model itself? AI passport.
Working on Attested AI agents? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.
Concepts: Re-attestation · Continuous attestation · Remote attestation · IETF RATS architecture