Customer access

You run an agent for another organisation. Customer access lets that organisation decide which of the agent's scopes it may use, from the agent's public verification page, with no Eniyan account. The decision is enforced on the agent's next action, everywhere Eniyan decides authority. A Trust Transparency add-on, $5 per named person per month, on every EACH 1 plan.

The model

One sealed agent, one customer. You name the customer (a label) and up to five people at it (by email). Those people sign in from the seal page by an emailed link and see the agent's enforcement scopes. These are the set the agent is held to, not the disclosure keys the seal shows consumers. They tick what the agent may do and untick what it may not, pause every scope, and resume.

Enforcement is a ceiling: the agent's effective scopes are its permitted set intersected with what the customer approved. A scope outside the approved set is refused at every scope check (the credential verify, the gate validate, the OAuth mint and introspection, the web mirror). The refusal is the same answer a switched-off scope gets, so no installed SDK needs an update. The Authority tab lists the trim as trimmed_by_customer.

Who decides what

You (an admin or role admin, signed in) grant and end the access, name and remove people, and resend sign-in links. You read the approved set; you never write it.
The customer's people approve and remove scopes within the agent's current permitted set, pause every scope, and resume.
Nobody else, Eniyan staff included, changes the approved set.

Granting starts with every current scope approved (the default) or with none (the customer approves before the agent may act). A scope that enters the permitted set later, by a re-registration, an identity provider (IdP) delegation, a role, an exception or a task, waits for the customer's approval. An agent with a customer cannot be re-registered without scopes.

Lapse and revoke

If the add-on lapses or the seal is no longer approved, the customer can no longer sign in, but the ceiling keeps applying. A lapse never widens what the agent may do. Only ending the access returns full control to you, and each named person is emailed when you do. The add-on cannot be cancelled while any customer access is live.

The seal page's manage view asks for an email and answers the same for every address; only a named person receives a link. A link is valid for 15 minutes and can be used once; it opens a session of one hour. Every call from the page carries the session in the request body and is rate-limited by IP address.

What is recorded

Audit rows customer_access_granted, customer_access_revoked, customer_access_signin and customer_scopes_updated, with the agent id, the scope keys and the person's email. The customer's label never reaches an audit row.
The webhook agent.customer_scopes_updated (ids and scope keys).
An email to every admin on each change the customer makes.

Limits

The ceiling covers scopes. Website, mailbox, file and agent-to-agent allowlists stay yours to set.
Pausing every scope pauses the agent's scoped actions. It is not the agent switch.
One customer per agent, up to five named people.

API

Your side, with a dashboard session: GET|POST|DELETE /v1/agents/{agent_id}/customer-access, POST .../managers, DELETE .../managers/{manager_id}, POST .../managers/{manager_id}/resend. The add-on: POST|DELETE /v1/billing/add-ons/customer-access. Refusals: TEAM_ONLY, CUSTOMER_ACCESS_ADD_ON_REQUIRED, SEAL_NOT_APPROVED, AGENT_UNDECLARED, CUSTOMER_ACCESS_EXISTS, CUSTOMER_MANAGER_LIMIT, CUSTOMER_ACCESS_IN_USE.

The customer's side, from the seal page and with no account: POST /v1/public/agents/{token}/access/request-link | session | state | scopes | pause | resume. A failure that is not the session's own expiry is one answer, ACCESS_UNAVAILABLE; the session's expiry is SESSION_EXPIRED; a scope outside the permitted set is SCOPE_NOT_PERMITTED.