Sixtyfour is the identity intelligence platform. Its agents investigate people and companies across the open web, official records, and archival filings, and its customers are the teams for whom attribution is the whole job: trust and safety, financial institutions, investigations units.
There is a neat irony in a platform like that serving anonymous users. Sixtyfour's API is self-serve, and increasingly the caller is not a person pasting a key into a script but an autonomous agent running research inside someone's pipeline. When that agent borrows its owner's login, Sixtyfour sees one account doing the work of many hands, and the owner's key sits inside an agent they may not fully control. AgentID, the sign-in for AI agents from AgentMail, untangles it. The agent signs in as itself, and Sixtyfour learns which human is accountable for it.
In short
- Sixtyfour accepts Sign in with AgentID, so an AI agent can create and operate its own Sixtyfour 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 Sixtyfour can reach the agent with usage alerts, receipts, and security notices.
- Sixtyfour 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.
- Sixtyfour keeps every product decision: credits, rate limits, data access, billing, enforcement. AgentID only answers who is signing in.
Why would an identity intelligence company want agent sign-ins?
Because identity is the product, and the standards a platform applies to the entities it investigates eventually apply to the entities it serves.
Sixtyfour's customers use it to answer who someone is and what they are connected to. The platform itself faces the same question at its own front door. A research agent spun up inside a sales or compliance pipeline needs API access, and today it gets that access one of two ways: a human's key pasted into its environment, or a throwaway account created with a throwaway email. The first makes the human's credentials hostage to the agent's behavior. The second makes the caller untraceable, which is an uncomfortable position for an investigations platform with a free API tier.
Agent accounts fix both. Each agent is its own principal with its own key, so revoking a misbehaving agent touches nothing else. And because every AgentID carries a stable owner identifier, Sixtyfour can key free credits, quotas, and enforcement to the human rather than the account. Ten agents from one person share one free tier, and banning the owner covers every agent they run. Free-tier farming through disposable signups stops working when every signup names its human.
How does an agent get its own Sixtyfour account?
Sign in with AgentID is standard OpenID Connect, the same technology as Sign in with Google. For Sixtyfour, accepting it is configuration on their existing login, not new infrastructure.
On the agent side, its AgentID is its AgentMail inbox address. The agent reaches Sixtyfour'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 Sixtyfour 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 Sixtyfour 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. Sixtyfour never gets a token that silently lacks the owner claim.
From there the agent does what any new user does: opens the dashboard, creates its own organization and API key (shown exactly once), and starts making calls on its own credit balance.
What does the agent's email address do for Sixtyfour?
It becomes the registered account email, and it works. Sixtyfour can send the agent a usage alert when its credits run low, a receipt when it tops up, or a security notice when something looks wrong, 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 Sixtyfour 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 | Sixtyfour |
|---|---|---|
| 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 |
| API keys, credits, rate limits | Not involved | Owns all three |
| Data access and pricing | Not involved | Controls both |
| Policy and enforcement | Supplies owner_sub for per-human caps | Decides and enforces |
What stays with Sixtyfour?
Everything that makes Sixtyfour Sixtyfour. The research agents, the Lattice graph, credit costs, rate limits, what data a given account can touch: 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 Sixtyfour's existing systems. It is not a trust score and not an endorsement of any agent's behavior.
Start at Sixtyfour, and use the AgentID sign-in guide to prepare your agent's inbox so it is ready the day the option goes live.
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.