Seren Passwords

Trust model

The server never sees plaintext

Credentials are encrypted before they leave your device. When you share one, access is limited to the person or employee you selected and only that identity can unlock it. Seren keeps the encrypted item and the access record, but not the information needed to read the secret.

A useful distinction

Passwords and Seren API keys

A Seren API key signs an application, script, or SDK into Seren. Seren Passwords stores credentials an employee may need for another service, such as a source control, alerting, or customer support account. Keep the application's Seren API key in its normal secure environment, and use Seren Passwords when an employee needs carefully controlled access to an outside account.

API keys are delegated capabilities rather than replacements for a signed-in user. Creating, listing, and revoking them requires a signed-in user session; an API key cannot administer other API keys. Browser sign-in obtains the short-lived user access token used for those requests, and clients can refresh that session without repeating the full sign-in flow for every operation.

Cloud employees are different: Seren creates a limited identity for each employee automatically. Never store your personal Seren API key in Passwords for an employee and never paste it into a skill. The employee uses its managed identity for Seren services, while Passwords remains the place for specific outside credentials you deliberately grant.

Employee credentials

Approve the exact fields an employee needs

Seren Desktop or Seren Employees start setup from the current managed-agent deployment. Seren Core derives the required environment fields, destination organization, deployment, active revision, and read-only access level. The user does not author this internal contract.

The setup link opens Passwords and expires with the approval window. It carries setup intent to an unlocked browser, not private signing authority. The browser creates or selects the managed-agent identity and signs the setup locally. Core and Passwords never receive the private signing key.

In Passwords, a participant maps each required field to an encrypted item and reviews the exact destination and scope. Each required participant approves with a signed-in user session and a resolved Passwords identity. Passwords accepts a contribution only from the principal named by that participant policy.

Passwords applies the result only after the approval policy is satisfied. Core binds the exact mapping to the expected deployment revision. Desktop and Employees read the deployment back before they show the credential connection as complete.

If the browser closes, reopen the setup from Desktop or Employees. Core returns access to the same request, and Passwords can replace an unused participant capability. A terminal request cannot be reopened.

Grant lifetime

Separate approval time from employee access

Setup links, participant capabilities, and pending approvals always expire. An applied, deployment-bound, read-only field grant can remain active without a calendar deadline. This rule supports an always-on employee without making its approval link reusable.

Each runtime material bundle remains short-lived. Renewal checks the current request state, revocation state, requester identity, deployment, revision, and managed-agent key fingerprints. A mismatch stops renewal.

You can revoke the grant at any time. Revocation stops the next renewal, while the audit record keeps the applied revision binding. Other scopes, including vault access and write access, keep an explicit grant deadline.