AgentID Gives Your Agent a Login. Revoking It Doesn't End Every Session

An agent should not need to borrow a person's login to have an account. AgentMail's AgentID gives it a separate identity and lets an app learn who owns it.

That is the useful part. The part worth slowing down for is the off switch.

AgentID's current documentation says revoking a sign-in key stops new sign-ins with that key. It does not end sessions an app has already issued. If you are adding agent sign-in to a product, that distinction belongs in the design before the button goes live.

Identity is one contract. The app session is another. Permission to carry out a particular task is a third.

What the launch establishes

The October 6 AgentID announcement describes a sign-in button for AI agents built on OpenID Connect. An agent signs in with an identity backed by its AgentMail inbox, rather than using its owner's account.

The vendor says a sign-in returns a stable agent identifier and a verified email address. Registered apps requesting the relevant scopes can also receive the owner's name and email. The product page describes support through custom providers in common authentication stacks.

There is a date wrinkle: AgentMail also has a September 9 introduction, while the October 6 page describes the public launch. I would not treat the later date as proof that every part of the system first existed that day.

Outside coverage is thin. Exact's October 6 summary attributes launch coverage to TestingCatalog, but it is not an independent security evaluation. The technical details below are vendor-documented behavior, not results from my own integration test.

A signed identity is better than a self-description

A request saying "I am an agent owned by this person" gives an app a claim to investigate. A validated identity token gives it an issuer-backed identity to build an account around.

AgentID's token walkthrough describes an ES256-signed ID token. It documents the issuer, the subject, the intended audience, expiry, an agent marker, and optional email and owner claims. The app checks the token rather than trusting text supplied by the agent.

This fits the OpenID Connect Core specification, which defines an identity layer on OAuth 2.0 and requires validation of the relevant token claims. Use a maintained OIDC implementation and its complete validation rules, not a handwritten decoder that only reads the payload.

For AgentID, the vendor's walkthrough calls out signature, exact issuer, exact client audience, expiration, and nonce matching when a nonce was sent. A token issued for another application is not your login token just because the email inside it looks familiar.

The walkthrough also says to key the account on the subject, not the email address. Deleting an inbox and recreating the same address produces a new subject. An email-shaped label should not silently reconnect a new identity to an old account.

Those are concrete identity checks. They still do not answer whether the agent may delete a file, change a subscription, or submit a payment.

Owner attribution is not task authorization

AgentID's token walkthrough explicitly says the token carries no trust score or endorsement. It does not prove the agent is safe. It identifies the agent and, when the required owner claims are granted, the person behind it.

That gives an app a useful key for policy. For example, the vendor suggests limiting signups per owner rather than treating fifty agents as fifty unrelated people.

But knowing the owner does not establish the owner's approval for a specific action. In an application design, keep the identity record separate from the task grant:

Record	Question it answers
Validated agent identity	Which agent signed in?
Granted owner claims	Which owner does the issuer attribute it to?
App session and role	What account access did this app issue?
Task-specific authorization	What action was approved, for which resource, within which limits?

The last row is a design requirement I would add to my own app, not a feature promised by the sign-in button.

A hypothetical expense assistant makes the distinction clear. It can have a valid identity, an attributed owner, and access to an expense workspace. None of those facts alone tells the app that a particular reimbursement was approved. The application needs its own approval record and must check it when the request arrives.

There is more than one clock

The most useful source here is the AgentID Sign-In guide. It lists separate objects with separate lifetimes:

Object	Documented lifetime or boundary
Pending sign-in key	At most five minutes, possibly less if the sign-in expires
Active sign-in key	Thirty days after activation
Remembered approval	180 days from the most recent sign-in, per inbox and app
ID and access tokens	Ten minutes, with no refresh token
App session	A lifetime chosen by the app

These are the vendor's documented values at the time of this review on October 9, 2026. They are not interchangeable expiry dates.

A remembered approval is not a credential. A short-lived token is not necessarily a short-lived app session. The OIDC specification itself notes that an ID token's expiration is unrelated to the lifetime of the authenticated session between the relying party and provider.

AgentID's walkthrough says its part ends at sign-in. The app can then issue its own session or API key with a lifetime it chooses. That local access is the part the app has to manage.

What revocation leaves behind

The sign-in guide is more specific than the marketing phrase "off switch":

• Deleting an active sign-in key revokes that key, stopping new sign-ins with it.
• Revoking a key does not clear the remembered approval.
• An already issued ID token remains valid until its ten-minute expiry.
• App sessions already issued are not ended by that key revocation.
• AgentID documents no revocation webhook or back-channel logout.

The same guide says an app that re-reads UserInfo within the token's ten-minute window can see revocation sooner. That is not a universal logout mechanism for every session the app has created.

Deleting the bearer key that created a sign-in key is also not documented as revoking the resulting sign-in key. Clearing saved sign-in material in one browser removes it from that browser; the guide says the key can remain active at AgentMail until expiry or explicit revocation.

So there are several possible meanings of "disconnect": remove local browser material, revoke the signing credential, reject future authentication, or terminate current app access. A settings page should say which one it performs.

Build the local off switch too

For an app accepting agent sign-in, I would define revocation as an application policy with a testable result. This is implementation guidance, not a claim that AgentID supplies these controls automatically.

Store the validated identity against the session you issue. Add a local disable state for an agent account. Check that state when authorizing protected requests, not only when drawing the account settings page.

For higher-risk actions, use shorter local sessions or require fresh confirmation according to your own risk policy. If your app issues API keys after sign-in, make those keys part of the same access inventory. Ending a browser session should not leave an untracked API credential behind.

Most importantly, tell the person what happened. "Credential revoked; existing sessions may remain" is less comforting than "disconnected," but it is a better statement when that is the actual result.

A useful revocation test is simple to describe:

1. Sign in with a test agent and obtain an app session.

2. Revoke its AgentID sign-in key in the test setup.

3. Confirm that a new sign-in with that key fails.

4. Check whether the old app session still accesses a protected resource.

5. Disable the local app account or end its sessions, then check that protected access stops.

Record the result of each step. If step three succeeds and step four still succeeds too, that is not necessarily a contradiction. You tested two different boundaries.

Request less identity data

The token walkthrough documents owner claims as scope-dependent. Open clients do not receive the owner's name or email. Registered apps must request the relevant owner scopes, and missing claims should be treated as not granted.

Do not substitute an inferred owner because a field is absent. Decide which identity information your app actually needs, request it explicitly, and explain its use.

The same walkthrough says signing in does not grant the application access to read or send the agent's email. A working inbox address can identify an agent without being a mailbox permission.

That is the overall lesson I would take from AgentID: separate identity, account access, data disclosure, and task approval. A sign-in standard helps establish the first. Your product still has to own the rest.

Frequently asked questions

What is AgentID?

An OpenID Connect provider from AgentMail that gives AI agents a separate email-backed identity for signing in to apps. The vendor documents stable agent identifiers and scope-dependent owner claims.

Does AgentID require the agent to use its owner's login?

The product is designed for the agent to sign in as itself, rather than borrow the owner's account. That does not remove the need for the app's own authorization policy.

Does a validated token prove an agent is safe?

No. AgentID's walkthrough says the token contains no trust score or endorsement. It establishes identity, not safe behavior or approval for every action.

Does revoking a sign-in key log the agent out of every app?

No. The sign-in guide says it stops new sign-ins with that key but does not end app sessions already issued. Each app controls its own session lifetime.

How long are AgentID tokens valid?

The vendor documents ten-minute ID and access tokens with no refresh token. This is distinct from the app's own session lifetime.

Does an app always receive the owner's email?

No. Owner claims depend on registration and the requested scopes. The walkthrough says open clients never receive the owner's name or email.

Does sign-in grant mailbox access?

No. The vendor says signing in does not grant the app access to read or send the agent's mail. Identity claims and mailbox permissions are different things.

Sources

• AgentID October 6 announcement: public-launch framing and product claims.
• AgentMail AgentID product page: separate agent sign-in and supported authentication-stack approach.
• AgentID token walkthrough: claims, token checks, subjects, owner scopes, and trust limits.
• AgentID Sign-In guide: credential lifetimes and the exact limits of revocation.
• AgentMail September 9 introduction: earlier product framing, distinguished from the October public announcement.
• OpenID Connect Core: protocol definition, validation, and token-expiry versus session-lifetime distinction.
• Exact's launch summary: limited outside coverage attributed to TestingCatalog, not a security audit.