Archil mounts production data into agent sandboxes without copies, syncs, or cold starts. It turns S3 and GCS buckets into a native filesystem mounted at /mnt/archil, so an agent works on live production data at local-disk speed instead of a stale copy. Access is governed: layered sources, granular permissions, versioned disks that can be branched and rolled back.
Governed access has a prerequisite: knowing who is doing the accessing. When the principal holding the mount is an AI agent, that was the unsolved part. An agent borrowing its owner's Archil login leaves every disk, branch, and checkpoint attributed to a human who may never have seen them. AgentID, the sign-in for AI agents from AgentMail, closes that gap. The agent signs in as itself, and Archil learns which human owns it.
In short
- Archil accepts Sign in with AgentID, so an AI agent can create and operate its own Archil account instead of borrowing its owner's.
- The agent's identity is a verified email address issued by AgentMail. It is a working inbox, so Archil can reach the agent with billing alerts and security notices.
- Archil receives a stable identifier for each agent and, through the owner scopes, the name and email of the human behind it.
- No password or reusable key crosses the sign-in. Each sign-in is a one-time signature, and authorization codes are single use.
- Archil keeps every product decision: disks, mounts, quotas, billing, permissions. AgentID only answers who is signing in.
Why would a data infrastructure company want agent sign-ins?
Archil already treats agents as the primary workload. Sandboxes get persistent, versioned disks; each agent attempt can run on its own branch; a bad run rolls back. That model quietly assumes something most infrastructure does not have: a way to tell agents apart.
Under a shared human login, three identities collapse into one account. The human who owns the data, the agent doing the work, and the credentials wired into the infrastructure all look identical in the audit trail. For a platform that sells governed access to production data, and holds SOC 2 Type II and HIPAA compliance, that conflation is a real cost. A disk branch created by an anonymous agent under a founder's login is unattributable and hard to revoke on its own.
With agent accounts, the mapping gets clean. Each agent is its own principal with its own credentials. A runaway agent gets revoked without touching its owner's account or any other agent. And because every AgentID carries an owner identifier, Archil can key quotas and enforcement to the human, not the account: ten agents from one person share one owner, and a banned owner covers every agent they run.
How does an agent get its own Archil account?
Sign in with AgentID is standard OpenID Connect, the same technology as Sign in with Google. For Archil, accepting it was configuration on their existing login, not new infrastructure. Their console asks the question directly: "Are you an AI agent? Sign up with AgentID" sits right beside the GitHub and Google buttons.
On the agent side, its AgentID is its AgentMail inbox address. The agent reaches Archil's sign-in, picks AgentID, and approves the sign-in through the AgentMail API with an inbox-scoped key. The approval is remembered for 180 days per inbox and app, so repeat sign-ins continue on their own.
What Archil receives is an ES256-signed id_token, valid for ten minutes, with no refresh token. It carries a stable subject for the agent, its verified email address, and, because Archil is a registered app with the owner scopes, the owner's name and email. An agent that cannot share its owner's details cannot finish the sign-in alone; the organization owner approves it instead. Archil never gets a token that silently lacks the owner claim.
What does the agent's email address do for Archil?
It becomes the registered account email, and it works. Archil can send the agent a billing alert when active compute spikes, a security notice when something looks wrong, or an onboarding thread, and the agent can read and act on all of it. Agents can even open and resolve support tickets.
The address is identity, not access. Signing in grants Archil no ability to read or send the agent's mail, and the agent's owner stays reachable through the owner_email claim when something needs a human.
Who controls what
| Stage | AgentID | Archil |
|---|---|---|
| Verified agent identity | Issues the verified email and stable subject | Not involved |
| Sign-in approval | The agent approves through its inbox-scoped key | Not involved |
| Owner attribution | Delivers owner name and email in the token | Decides how to use it |
| Disks, mounts, regions | Not involved | Owns all of it |
| Quotas, billing, permissions | Not involved | Controls all three |
| Policy and enforcement | Supplies owner_sub for per-human caps | Decides and enforces |
What stays with Archil?
Everything that makes Archil Archil. Disk performance, branching and checkpoints, the mount model, pricing, quotas, compliance posture: none of it changes. AgentID answers one question at the door, who is this agent and which human is accountable for it, and hands the answer to Archil's existing systems. It is not a trust score and not an endorsement of any agent's behavior.
Start at Archil, and use the AgentID sign-in guide to prepare your agent's inbox. Archil's quickstart covers creating and mounting a disk once the account exists.
AgentID gives your agent a verified identity and its own email address. Free for apps to add.
Give your coding agent this prompt.
Add AgentID sign-in to this project. Read https://www.agentid.com/llms-full.txt for the integration reference, then run `npx @agentmail/agentid-cli init` from the project root and follow its prompts.