The first wave of "AI assistants" borrowed the human’s session. The model logged in as you and used your OAuth token to read your inbox, draft replies, and book meetings. It worked, sort of, until it didn’t — until the audit log was a mess, the blast radius was your entire account, and the only way to revoke the assistant was to log out everywhere.
Agentic identity is the answer to that mess. It is the bundle of permissions, addresses, calendars, contacts, and approval rules that an AI agent needs to act on a user’s behalf — but as a first-class object, separate from the human.
What goes into an agentic identity?
An agent identity in Helix has five components, each of which is a deliberate design decision rather than an accident of session sharing:
- A sponsor — the human with a verified dashboard account who is responsible for the agent.
- A mailbox — either a real Gmail/Outlook account the sponsor connects, or a fresh dedicated agent inbox.
- A scope of authority — read-only, draft-only, send-with-approval, or send-autonomous (per-identity, never global).
- An approval policy — "always" by default, with a queue UI and an audit log.
- A driving surface — the MCP endpoint, the REST API, or both. Any client can drive the agent; only one identity is in play.
These five pieces are not optional add-ons. They are what make an agent revocable, auditable, and safe to point at a real customer relationship.
Why "borrow the session" fails
When an LLM uses your OAuth token, three things go wrong. First, the audit log treats the agent’s actions as your actions — you cannot tell which sends came from you and which came from the model. Second, scope is the user’s scope; the agent inherits everything you gave the OAuth grant. Third, revocation is binary: revoke the grant and the agent dies, but so does every other tool that shares the grant.
A dedicated agent identity solves all three. The audit log shows agent actions distinctly. The scope is set per-identity and enforced server-side. Revocation kills the agent without touching anything else.
Where Helix fits
Helix is built on top of Nylas v3 — the email, calendar, and contacts API that thousands of companies already use in production. Helix layers an identity model and a human-approval engine on top so that "an AI agent that sends email on someone’s behalf" stops being a footgun and starts being a product surface.
The MCP endpoint is the user-facing surface. Behind it sits the identity object, the approval queue, the audit log, and the policy engine. Whether the agent is driven from Claude on your laptop, Cursor on your phone, or n8n in the cloud, the same identity is doing the work.
What you get when identity is first-class
The day-to-day difference is small but compounds. Your real inbox stays untouched. The agent has its own address with its own context. The approval queue catches the bad sends before they ship. The audit log answers "who sent that?" in one second instead of one afternoon. And when you fire the agent, you fire only the agent.