Going live

Sign-in is generally available, with automatic admission for host-consistent metadata-document clients. The contract changes only with notice on the changelog. The review packet is for deep integrations, partner entitlements, and clients that need manual admission. Send a complete packet to support@ego.ist. Host-consistent CIMD clients can connect without submitting a packet.

Admission and standing

CIMD admission is automatic for host-consistent clients, and it is revocable at any time. AI Passport can suspend or revoke a client when its metadata document changes materially, when its document or host stops validating, or by operator decision. Suspension and revocation end new sign-ins immediately and invalidate the client's existing tokens. Users must sign in and consent again after a client returns to good standing.

Admission confirms domain control only. It is not a review of the app and not an endorsement. Automatic admission carries no service commitment for admission or standing. Ask for the reason behind a suspension or revocation at support@ego.ist.

What we review for managed access

We review these areas:

• The product use case and requested scopes
• Redirect, popup, completion, and sign-out behavior
• Button copy and prominence
• Token storage, rotation, revocation, and incident contacts
• User consent, denial, deletion, and reconnect paths
• Memory attribution, pass handling, and workspace readability
• Connector selection and special-category disclosures
• Quotas, expected volume, retries, and outage behavior

What to send

Send one packet with these items:

1. Legal organization name, product name, website, and primary contact.
2. A short use-case description and the exact scopes you request.
3. Your client_id and every exact redirect URI.
4. Every Passport Link or hosted-key completion URI.
5. Your privacy policy and terms URLs.
6. Screenshots or recordings of each AI Passport entry and return path.
7. A test URL and a test account with no production user data.
8. Your security contact and operational escalation contact.
9. Your refresh-token storage and revoke-on-sign-out design.
10. Your expected daily users, source items, and workspace items.

Deep integration partners shall also send the proposed source slug, connector list, workspace readability posture, and creation-notice posture.

Turnaround

For managed access requests, expect an initial response within 5 business days after we receive a complete packet. Fixes or missing evidence can require another review pass.

For integrations that need review, the initial response is not launch approval. Approval names the admitted redirect hosts, active credentials, quota dials, and launch date. Partner entitlements remain operator-provisioned.

Client readiness checklist

Before launch, verify each item:

• Treat access_denied as a completed user choice, not a retryable outage.
• Read the returned scope and support narrower grants.
• Send users to approval_url for a missing pass.
• Keep dependency outage distinct from a successful empty result.
• Replace each refresh token pair atomically after rotation.
• Revoke the refresh token when the user signs out.
• Verify state, iss, nonce, signature, audience, expiry, and at_hash.
• Before using a connector:reads or booking:actions token from your backend, prove it belongs to your exact client through at_hash or POST /oauth/token-info, and repeat the token-info check after every refresh.
• For CIMD, keep every non-loopback redirect host equal to the metadata document host or a strict subdomain. Admission is automatic for this shape; loopback redirects are exempt. Non-host-consistent clients and deprecated DCR clients need manual admission. Wildcards, non-loopback IP literals, HTTP on non-loopback hosts, and mixed host trees never auto-admit. Declare each purpose scope in the document's scope before requesting it.
• If you receive directed disclosures, verify the signed Passport-Disclosure-Attestation header and consume its jti once before reading the body.
• Enforce strict popup origin checks.
• Use stable ids for every retryable write.
• Tolerate new endpoints, optional fields, errors, and item statuses.
• Preserve Garmin device attribution in data, derived results, displays, exports, and downstream transfers, following the Garmin attribution requirements.

See Brand guidelines for the sign-in control. See the Changelog for additive contract changes.